Quality Protocol
An umbrella for non-trivial work. It does not repeat every planning and verification procedure; it chooses the one that fits and keeps the work honest.
Procedure
1 - Restate the request
One short paragraph: goal, known context, gaps, assumptions. Skip the ceremony when the request is already unambiguous; still name the assumption you act on.
2 - Catalog binding constraints
List only constraints that can fail the work:
- Technical: platform, version, compatibility
- Scope: files or surfaces allowed to change
- Evidence: what must be checked against a live source
- Boundaries: read-only, no commit, no credentials, no destructive action
Add the success criteria: how a reviewer can tell the task is done.
3 - Choose one entry discipline
| Situation | Discipline |
|---|---|
| Ambiguous request, unclear constraints | constraint-then-solve |
| Non-trivial change with more than one reasonable approach | plan-before-code |
| A plan exists and execution order matters | plan-then-act |
| A claim must be checked before it is repeated | verify-first |
| An inherited finding or audit item is about to be acted on | re-verify-findings |
| A design document is being implemented | read-before-build |
Use one entry point. Stacking every discipline turns the protocol into ceremony and buries the actual constraint.
4 - Plan and take the first action
State the plan in one sentence and the first concrete step. If the user already authorized the work and the spec is clear, proceed; do not re-ask for approval.
5 - Execute in small verified increments
For each increment: change, run the narrowest check, inspect the result, then continue. A change is not done because it was made; it is done when its check passes. Batch independent inspections, serialize dependent changes.
6 - Verify against the catalog
Check every constraint from step 2. Mark each one pass or fail with the evidence used. If a constraint cannot be checked, say so; do not imply it passed.
7 - Close with evidence
Report what changed, what was checked, and what remains uncertain. Do not claim completion from the change alone.
Skill boundaries
plan-before-codeowns the spec and approval gate.plan-then-actowns execution cadence.constraint-then-solveowns ambiguity and constraint reasoning.verify-firstowns checking a new assertion.re-verify-findingsowns inherited findings.read-before-buildowns source inspection before implementation.
Anti-patterns
- Running every discipline on a one-line change.
- Restating the request and then ignoring the constraints during execution.
- Treating a passing compile as proof that the requested behavior works.
- Claiming a constraint passed without naming the evidence.
- Asking for a second approval the user already gave.
References
- details
Verification Checklist
- [ ] The success criteria are stated in observable terms.
- [ ] One entry discipline was chosen and named.
- [ ] Each binding constraint is marked pass, fail, or unverified.
- [ ] The final report separates what changed from what was checked.
- [ ] Remaining uncertainty is stated rather than hidden.