bereniketech/self-checking-workflow

Self-Checking Workflow

1. Core Pattern

For every implementation task, structure the plan as paired build+verify steps rather than a flat list of build steps.

Rule: Never move to the next step until you reach 95% confidence the current step is correct.

Build the plan like this:

[ ] 1. Build: <feature or change>
[ ] 2. Verify: <specific check — screenshot / test / grep / DevTools>
[ ] 3. Build: <next feature>
[ ] 4. Verify: <specific check>

2. Verification Methods by Work Type

| Work type | Verification method | |-----------|---------------------| | UI / layout | Screenshot → visual inspect → note what's wrong | | Interactive UI | Open browser → click through golden path → check DevTools console for errors | | API / backend | Run the endpoint → check response shape → check error logs | | Data transforms | Print intermediate output → assert expected shape | | File edits | Re-read the file → confirm change landed cleanly | | Anything | Re-read requirements → confirm every bullet is addressed |

3. Screenshot Verify Loop (UI)

When building a UI component or page, run 3 passes before delivering V1:

1. Build initial layout → screenshot → note gaps
2. Fix gaps → screenshot → note remaining issues
3. Fix remaining → screenshot → confirm looks correct

Rule: Only present V1 to the user after at least 2 screenshot passes. State what changed between passes.

4. 95% Confidence Gate

Before marking a step done, ask internally:

• Does this match the requirement exactly, or just approximately?
• Are there edge cases I haven't tested?
• Would a fresh reader of the code spot an obvious flaw?

If the answer to any is "maybe," iterate once more. Mark done only when the answer is "no."

5. Reporting to User

When all steps are complete, report:

1. What was built
2. What verifications were run and what they found
3. Any remaining known gaps (be explicit — don't hide them)

Rule: Never say "done" without listing at least one specific verification you performed.