mrclrchtr Execute implementation plan
The Iron Law
EVERY TASK GETS FRESH VERIFICATION BEFORE MARKING DONE
If you haven't run the verification command for this task, you cannot check it off. Previous runs do not count. "Should pass" is not evidence.
Step 1: Load the plan
Call supi_flow_apply { ticket_id: "<ID>" }. Read the returned overview.
If a task has a linked detail_path, note it — read that doc only when the task becomes active.
If the tool reports an error (missing overview, empty manifest, invalid lifecycle, blocked), stop and resolve it before editing. If no plan is available, ask which change to implement.
Step 2: Execute tasks
For each unchecked task, in order:
- Announce which task you are working on.
- Read the task detail doc first. Every task has a
detail_path(e.g.tasks/task-01.md). Read that file before touching any code. The detail doc is the authoritative task specification — do not rely on memory or the plan overview alone. If the doc is vague or ambiguous or if anything is unclear, pause and get clarification before editing code. - Follow the task as written. Treat the detail doc as part of the task definition.
- Run the verification for that task and read the result carefully.
- If verification passes: call
supi_flow_complete_task { ticket_id: "<ID>", task_number: <N> }to check the task off in the ticket. - If verification fails: stop, diagnose, fix, and re-verify before moving on.
- Record what actually passed.
Do not skip failed checks. Do not collapse several tasks into one vague batch.
TDD by default, not always
For testable code, write the test first:
- Write a failing test for the right reason.
- Write the minimal code to make it pass.
- Re-run and confirm it passes.
- Run any broader regression checks the plan calls for.
No production code without a failing test first.
Test-exempt work
For docs-only, config-only, trivial changes, or integration work with no reasonable harness:
- Run the manual verification from the plan. If the plan omitted one, add the smallest concrete verification you can justify.
- Confirm the actual output matches the claim and note the exemption when reporting completion.
If uncertain whether TDD is practical, ask instead of guessing.
The hard rule is not "TDD in every case." The hard rule is: no unverified changes.
Step 3: When blocked or stuck
If verification fails, and you don't understand why, load /skill:supi-flow-debug
before attempting random fixes.
Stop and ask the user when:
- A verification fails repeatedly, and you still don't understand the cause
- You've tried 3 fixes and none worked
- A dependency is missing
- The plan has a gap, is unclear, or scope changed
- A task is missing verification
- You're unsure whether to use TDD or a test exemption
Do not guess. Do not force through blockers.
Rationalization prevention
| Excuse | Reality |
|---|---|
| "Should pass now" | Run the verification again. Fresh. |
| "I'm confident" | Confidence is not evidence. |
| "Just this once" | Verification still applies. |
| "Previous run passed" | Code changed. Run it again. |
| "This task is too simple to need TDD" | TDD is preferred for testable code. If it is not practical, verify it manually and say why. |
| "I know what the task says" | Task detail docs evolve between plan and apply. Read them fresh. |
When all tasks are done
- If a ticket exists: summarize what passed in conversation, but do not mark it done yet —
/skill:supi-flow-archivehandles durable verification evidence inarchive.mdand final closeout. - Announce:
Implementation complete. Run /skill:supi-flow-archive TNDM-XXXXXX to verify, update docs, and close out.