quality-plan

name	quality-plan
description	Produce a concise quality plan defining quality objectives, measurable metrics, assurance activities, and control checkpoints for a project. Invoke when the team needs an explicit, agreed-upon quality standard before entering execution.

Originally authored for Agentic PM Kit (MIT).

When to use

Use this skill during the planning phase, after the project charter and WBS are stable, and before the first execution sprint begins. A quality plan makes quality criteria explicit and measurable rather than assumed. Typical triggers include:

• The project sponsor or PMO requires a written quality standard as a gate before execution approval.
• The team has no shared definition of what "done" or "acceptable" means for the project's deliverables.
• A prior project failed acceptance testing because quality criteria were not established upfront.
• The project is subject to external standards (ISO, WCAG, industry regulations) that must be declared and tracked.

Do not invoke as a substitute for the acceptance checklist embedded in each artifact skill — this skill produces a project-level quality plan, not an artifact-level checklist.

Summon the SME

Before drafting, load the canonical quality-management reference to ground the plan in established practice.

Reading the config. Check .pm-kit.config.json for the sourcesMode field:

• If sourcesMode is "online" (opt-in): fetch the URL stored at the key sources.qualityPlan in vendor/pm-kit/sources-index.json using your available web-fetch capability. Do not name a specific tool — use whatever your runtime provides. Ground the facilitation in what you read. Do not fabricate quotations or page numbers from any version of that page.
• If sourcesMode is "offline" or the field is absent (the default): rely on your general knowledge of quality management principles as described by ISO 9001 and the Project Management Institute. Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.qualityPlan in the output. Do not fabricate quotations or page numbers.

In both cases, the URL to cite is https://en.wikipedia.org/wiki/Quality_management.

Facilitation script

Walk the user through these steps in sequence. Do not skip steps or combine them.

Step 1 — Define quality dimensions. Ask the user: what does quality mean for this project across three dimensions — (a) user-visible output quality (e.g., defect rate, usability), (b) internal process quality (e.g., code review coverage, test pass rate), and (c) documentation quality (e.g., completeness, accuracy). Record at least one objective per dimension.

Step 2 — Set measurable targets. For each quality objective, establish a measurable metric and a minimum acceptable target. Examples: "Defect escape rate: fewer than 2 critical defects reaching production per release," "Code review: 100% of pull requests reviewed by a peer before merge," "Test coverage: no module below 70% statement coverage." Confirm the targets with the user.

Step 3 — Define assurance activities. Ask the user which activities will be used to prevent defects before they occur: code reviews, pair programming, design walkthroughs, automated linting, sprint retrospectives, UAT dry runs. Record the activity, frequency, and responsible role.

Step 4 — Define control activities. Ask the user which activities will be used to detect and correct defects after they occur: inspection gates, audit reviews, validation before release, regression test runs. Distinguish control (detection) from assurance (prevention).

Step 5 — Identify applicable standards. Ask the user whether the project must comply with any external standards: ISO specifications, accessibility standards (e.g., WCAG 2.1 AA), company style guides, regulatory requirements. Record each standard and the relevant deliverable it governs.

Step 6 — Save the artifact. Save the filled artifact to docs/pm-kit/outputs/quality-plan/<short-slug>.md. <short-slug> is a kebab-case ASCII slug (max 40 chars) derived from the project name (e.g., bookswap-campus-quality-plan). Confirm the final path with the user before writing. If the file exists, ask: overwrite, append a date suffix (e.g., -2026-04-20), or pick a new slug. The artifact begins with the three-line provenance header below (HTML comments, do not render):

<!-- Generated by agentic-pm-kit:quality-plan on YYYY-MM-DD -->
<!-- Languages: communication=<value>, output=<value> -->
<!-- Source mode: offline | online -->

Languages

The kit separates the language used for live agent–user dialogue from the language used in the saved artifact. Both values live in .pm-kit.config.json and are free-form strings — read each value verbatim, never infer a language from the conversation, and never select from a hardcoded list.

Facilitation dialogue. Speak to the user during facilitation in the language at language.communication. Use the string verbatim.

Filled artifact (saved TEMPLATE.md output). Produce the written artifact in the language at language.output. If language.output is absent or empty, fall back to language.communication.

Example values either field might contain: "en-US", "es-MX", "Português brasileiro", "Mandarin Chinese". Accept any string as given. This bifurcation is the normative pattern for every skill in the kit.

Acceptance gate

When the plan is complete, point the user to CHECKLIST.md (sibling file) and ask them to verify each item. Remind them that the output must be marked PASS or FAIL. On FAIL, invite the user to return with specific notes so the facilitation can be resumed or corrected.