tollens-ai/quality-strategy

Write the quality strategy up as one document from the records, straight after the release priorities - an opening, then a section for each priority ending in its open questions and their next actions - then check it against its sources and give it to the user. Use after the priorities, again when the strategy owner wants the whole document reread and checked, or when a step is waiting on the user and they want what exists written up.

Draft steps of a quality strategy without the user, for them to review later. Use when the user asks to skip ahead to a later step, or asks the agent to draft steps or stakeholders itself. Asks for the project context to be done with the user first.

Find out or update the background that quality work needs, including the project's purpose, scope, how work gets done, releases, stakeholders, and how each stakeholder relates to the products, tools or other things involved. Use before other quality work needs that background, or when the purpose, releases or stakeholders change.

Read one or more software project repositories, without changing them, and write a digest with sources of what the files show - the major issues obvious from the code and architecture, what the tests cover and do not, a first reading of how friendly the codebase is to agents working on it, and what the project says about itself, how it is built and where sources disagree. Use before a quality strategy, planning, onboarding, due diligence or a handoff, when someone needs to understand a project as it is today.

Combine every stakeholder's view into one set of quality priorities for a release, with how much each matters and what is not a priority for it. Use once each stakeholder who matters has had their deepdive, or to revise or re-order the release's priorities.

Work one release priority further with the strategy owner, once the strategy is written up, so that someone can act on its section. Use for any priority they name or choose.

Hear what matters to someone about a software project's quality, and what worries them, in their own words before any structured strategy work, so the strategy does not miss it. Keeps their account in a transcript, topic records and a summary that later steps check the strategy against. Use when someone has something on their mind about a project's quality, or to resume an unfinished sitting.

Make something to show from quality strategy records, such as a striking, faithful visual to share, a page a reader can explore, a report for a particular reader, or an operational summary. It is the last step of a strategy, and can also be used on a focused or partial one whenever someone wants to understand, share, present or work from it.

Agree once, for a project, where its quality documents are kept and who they are for, and save that so every later session finds it. Use before the first step of a quality strategy or interview on a project, or to change where its documents live.

Find where a quality strategy stands and what to do next. Explains what a strategy is for, the steps and why they come in that order, and names the one step to run next. Use to start a strategy or to find your place in one.

Review whether a quality strategy, or one context, stakeholder, priorities or priority-section document, supports the understanding, question or decision it is meant for. Use to review existing quality work on paper, at the scope it states.

Record the user's understanding of one stakeholder or group for a release - who they are, what matters to them, how good it must be, what comes first for them - and the questions the user still has about them, saved as their profile. Use once for each stakeholder before the release priorities, or to revise a stakeholder's view.