outcomeengineering - Load methodology (Phase 1 — once per session)
- Load work item context (Phase 2 — every node)
- Architect → audit until APPROVED (Phases 3–4)
- Test → audit until APPROVED (Phases 5–6)
- Implement → audit until APPROVED (Phases 7–8)
Before starting Phase 3, determine the project language:
tsconfig.jsonexists → TypeScriptpyproject.tomlorsetup.pyexists → Python- Both exist → check the spec node for language indicators, or ask the user
Use the detected language for ALL Phases 3–8. Do not switch mid-flow.
Phases 1–2 are language-independent. Phases 3–8 use the detected language.
| Phase | Purpose | TypeScript | Python |
|---|---|---|---|
| 1 | Load methodology | Skill("spec-tree:understanding") |
same |
| 2 | Load context | Skill("spec-tree:contextualizing", args: "{node-path}") |
same |
| 3 | Architect | Skill("architecting-typescript") |
Skill("architecting-python") |
| 4 | Architecture audit | Skill("auditing-typescript-architecture") |
Skill("auditing-python-architecture") |
| 5 | Write tests | Skill("testing-typescript") |
Skill("testing-python") |
| 6 | Test audit | Skill("auditing-typescript-tests") |
Skill("auditing-python-tests") |
| 7 | Implement | Skill("coding-typescript") |
Skill("coding-python") |
| 8 | Code audit | Skill("auditing-typescript") |
Skill("auditing-python") |
You MUST invoke the exact Skill tool call shown. Do not substitute, skip, or reorder.
Invoke /understanding.
This loads the spec-tree methodology — node types, assertion formats, durable map rules. Skip if SPEC_TREE_FOUNDATION marker is already present in this session.
Do not proceed until complete.
Invoke /contextualizing with the node path.
Load the full context hierarchy for the specific node — parent chain, sibling nodes, applicable decisions, assertions.
Repeat for every new node. Do not reuse context from a previous node.
Do not proceed until complete.
Invoke the architecting skill for the detected language.
Produce the ADR(s) for the work item. The architecture must be complete before audit.
Invoke the architecture audit skill for the detected language.
REJECT → fix → re-invoke this phase. Loop until APPROVED.
Invoke the testing skill for the detected language.
Write tests for all assertions in the spec. Tests come before implementation — no exceptions.
Invoke the test audit skill for the detected language.
REJECT → fix → re-invoke this phase. Loop until APPROVED.
Invoke the coding skill for the detected language.
Write implementation code. All tests from Phase 5 must pass.
Invoke the code audit skill for the detected language.
REJECT → fix → re-invoke this phase. Loop until APPROVED.
Phases 4, 6, and 8 are blocking review gates. Each audit skill emits APPROVED or REJECT.
- Before starting Phase 5: scan the conversation for the Phase 4 verdict. If
APPROVEDis not present, stop — invoke Phase 4. - Before starting Phase 7: scan the conversation for the Phase 6 verdict. If
APPROVEDis not present, stop — invoke Phase 6. - Before declaring success: scan the conversation for the Phase 8 verdict. If
APPROVEDis not present, stop — invoke Phase 8.
On REJECT: fix the findings, re-invoke the same audit skill, and scan again.
3 consecutive REJECTs on the same gate → STOP. Report which gate failed and why, and ask the user for guidance.
- Do not write ad hoc code to "see what's happening."
- Do write a test that reproduces the problem. The fact that you hit this issue proves your test coverage has a gap.
- Then fix the implementation until the test passes.
This is not slower. The ad hoc script you were about to write takes the same effort as a test, but the script gets deleted and the test stays.
Scan the conversation for these markers before declaring done:
-
SPEC_TREE_FOUNDATIONmarker present (Phase 1) -
SPEC_TREE_CONTEXTmarker present (Phase 2) - Phase 4 audit skill emitted
APPROVED - Phase 6 audit skill emitted
APPROVED - Phase 8 audit skill emitted
APPROVED - All tests pass