[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FW2CVBB9KP6TH8X246GA8":3,"skill-same:01M71FW2CVBB9KP6TH8X246GA8":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M71FW2CVBB9KP6TH8X246GA8","apply",null,"ALWAYS invoke this skill before implementing any product-tree work item. NEVER write code, tests, or architecture for a product-tree node without this skill.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Fapply\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"never","parse","invoke","implementing","proposal","run typecheck","run lint","typecheck","uv","architecture","spawn","read","ask","work","plan","Bash","product","code","run","2026-11-10 10:12:30",false,"---\nname: apply\ndescription: >-\n  ALWAYS invoke this skill before implementing any product-tree work item.\n  NEVER write code, tests, or architecture for a product-tree node without this skill.\nargument-hint: \"[full-spx-node-path | plan-or-proposal]\"\nallowed-tools: Read, Edit, {{! tool('use_skill') !}},{!% if target == 'claude' %!} Agent,{!% else %!} {{! tool('spawn_agent') !}}, {{! tool('wait_agent') !}},{!% endif %!} {{! tool('ask_user') !}}, Bash(git status:*), Bash(git rev-parse:*), Bash(git diff:*), Bash(spx validation:*), Bash(spx spec status:*), Bash(spx test:*), Bash(just test:*), Bash(just check:*), Bash(just check-full:*), Bash(just verify:*), Bash(just validate:*), Bash(pnpm test:*), Bash(pnpm run test:*), Bash(pnpm run check:*), Bash(pnpm run lint:*), Bash(pnpm run typecheck:*), Bash(pnpm run validate:*), Bash(pnpm run verify:*), Bash(npm test:*), Bash(npm run test:*), Bash(npm run check:*), Bash(npm run lint:*), Bash(npm run typecheck:*), Bash(npm run validate:*), Bash(npm run verify:*), Bash(yarn test:*), Bash(yarn run test:*), Bash(yarn run check:*), Bash(yarn run lint:*), Bash(yarn run typecheck:*), Bash(yarn run validate:*), Bash(yarn run verify:*), Bash(bun test:*), Bash(bun run test:*), Bash(bun run check:*), Bash(bun run lint:*), Bash(bun run typecheck:*), Bash(bun run validate:*), Bash(bun run verify:*), Bash(uv run pytest:*), Bash(pytest:*), Bash(cargo test:*), Bash(cargo check:*), Bash(cargo clippy:*), Bash(cargo fmt --check:*), Bash(go test:*), Bash(go vet:*), Bash(make test:*), Bash(make check:*), Bash(make verify:*), Bash(make validate:*)\n---\n\n\u003Cobjective>\nA product-tree work item implemented, verified, and delivered to the boundary the user requested — the default branch on origin unless the request names a narrower one.\n\n\u003C\u002Fobjective>\n\n\u003Cinvocation_modes>\n\nThe raw invocation string `$ARGUMENTS` controls what runs before the per-node flow below. Parse it exactly once before Step 0:\n\n- `$ARGUMENTS` containing a canonical full `spx\u002F...` node path → the work queue is that single node.\n- Empty `$ARGUMENTS` → determine the work from the conversation. If nothing is clear, complete Step 1 first — use skill `product-tree:understand` when the live `PRODUCT_TREE_FOUNDATION` marker is absent — then read `spx\u002FEXCLUDE`, whose entries are relative to `spx\u002F`, and prefix each non-comment, non-blank entry with `spx\u002F` before adding it to the work queue. Never access `spx\u002FEXCLUDE` before the foundation is live, and never pass a bare entry to `\u002Fcontextualize`. If no work is found, report \"Nothing to apply\" and stop.\n\nWhen the work is described as a plan or proposal rather than a specific node or queue, use skill `product-tree:slice` first: it selects the next executable observable slice and produces the node set that becomes this flow's work queue. Skip the preflight when the queue is already a specific node or an `spx\u002FEXCLUDE` list.\n\nComplete Step 1 before the queue loop in every mode, so the foundation is live before the loop reads or edits `spx\u002FEXCLUDE`. When the queue holds more than one node, order by numeric index prefix (lower first) — lower-indexed nodes constrain higher-indexed ones. For each node in order:\n\n1. Strip the canonical node path's leading `spx\u002F` to derive its `spx\u002FEXCLUDE` entry. If that relative entry is listed, remove its exact line first — the `spx` CLI then includes its tests in `spx test passing`.\n2. Run Steps 2–9 on the node, and Step 1 again first when a compaction has made the foundation marker absent.\n3. Confirm the final gate subject is committed and the worktree is clean.\n4. Proceed to the next node without stopping or asking, subject to the gate cap of two counted rejections in `\u003Creview_gates>`.\n\nIf a node's flow cannot reach its gate-specific passing state or a passing review within the gate cap of two counted rejections, stop the queue, report the failed node and step, and leave the remaining nodes in `spx\u002FEXCLUDE`. Step 10 (`\u002Fmerge`) runs once over the whole changeset after the queue completes.\n\n\u003C\u002Finvocation_modes>\n\n\u003Clanguage_detection>\n\nBefore starting Step 3, determine the product language:\n\n- `tsconfig.json` exists -> **TypeScript**\n- `pyproject.toml` or `setup.py` exists -> **Python**\n- `Cargo.toml` or `rust-toolchain.toml` exists -> **Rust**\n- `go.mod` exists -> **Go**\n- Multiple supported language markers exist -> inspect the loaded spec node for a single applicable language; when ambiguity remains, ask the operator and stop before Step 3 until one language is selected\n- No supported marker exists, or the selected language has no installed architecture, test, and code skills -> stop before Step 3 and report the exact marker state plus the missing language-plugin capability\n\nProceed to Step 3 only after exactly one supported language and its required skill surface resolve. Use that language for ALL Steps 3–8. Do not switch mid-flow.\n\n\u003C\u002Flanguage_detection>\n\n\u003Cscope_detection>\n\nBefore starting Step 3, determine the change's scope — this determination governs every later gate:\n\n- **Node-local** — the entire diff stays within the target node's own directory (its spec, its `tests\u002F`, and the implementation files that node governs).\n- **Cross-node** — the work touches anything else: a refactor, a move, a consolidation, a cross-cutting rename, a shared enabler, a sibling spec, or any file outside the target node.\n\nWhen the scope is cross-node, every audit gate — Steps 4, 8, and 8a — runs at **whole-changeset** scope, not only the target node, and Step 9 is REQUIRED before the flow may be declared complete. A per-node audit reads only the target node's files; it cannot see a regression the change introduced in a file the node does not own. Carry the determination through Steps 4, 8, and 8a — each gate step restates the scope requirement at its point of action.\n\n\u003C\u002Fscope_detection>\n\n\u003Claunch_contract>\n\nEach audit or review step below requests exactly one native launch with its mapped subagent name and target-only prompt. Use the native tool schema and result-collection capabilities. A failed launch or unusable final result stops that invocation: analyze and report the exact failure without another launch, a substitute subagent or model, an alternative launch mechanism, or an audit in this conversation.\n\nPersist accepted requirements in decisions and specs before dispatch. Start each Verifier without authoring history, following the root guide's isolation mechanics. Never append an author-written context packet, reasoning, summary, or suggested verdict. The invoked skill independently discovers its evidence from the target and configured instructions.\n\nCompleted structured verdicts follow the existing finding-repair workflow: repair the defect class, verify and checkpoint the changed subject, then make one launch for that new subject. Never use a repair loop to replace a failed launch or unusable result. While the native capability reports work still running, collect that same invocation; an observation timeout never authorizes a new launch.\n\n\u003C\u002Flaunch_contract>\n\n\u003Cstabilized_diff_rule>\n\nBefore any audit gate or whole-changeset review runs, self-converge the diff: read the changed specs, tests, and implementation together; confirm the design is coherent; and fix obvious contradictions before asking an auditor or reviewer to find them. Audit gates confirm a stabilized design. They are not the design loop.\n\nWhen a gate returns `REJECTED`, `UNKNOWN`, or `BLOCKED`, or when a review surfaces a valid `blocking` finding, treat it as evidence of a defect class. Read the touched node(s) — the files they govern — find same-class instances, and fix the class before re-running the gate. The class is the rule the finding cites, as the cited standard defines that rule; the finding's examples are instances of the class, never its definition. Same-class means the same cited clause, the same source contract, evidence pattern, lifecycle step, generated-source relationship, or architectural boundary that clause governs. Fix every instance the cited clause covers across the touched node(s) and change nothing the clause does not require. A patch to the cited line alone is sufficient only when a sweep under that clause proves the defect isolated.\n\nRecord each repair with the clause it applies and the check that shows the class closed. That record enters the next `VERIFICATION_DISPATCH_READY` record under `\u003Cverification_checkpoint>`.\n\nDo not re-run a gate after every micro-edit. Batch the class fix, re-read the affected diff, then run the gate once on the stabilized tree.\n\nA rejection whose defect class a prior repair already claimed to close invalidates that repair invariant. Stop localized patching, analyze why the class survived, widen the repair and the same-class scan, and amend the governing workflow, standard, or source contract before the next dispatch. The work queue stops at the node that raised the repeat until that amendment lands; a new line number, file, or example does not make it a new class.\n\n\u003C\u002Fstabilized_diff_rule>\n\n\u003Cverification_checkpoint>\n\nUse skill `product-tree:merging-standards` and read its `merge-policy.md` reference before the first dispatch of the flow; `\u003Cverification_dispatch_readiness>` and `\u003Cverification_result_projection>` are its sections, and invoking the compact loader alone does not load them.\n\nBefore dispatching any persisted audit or review gate, bind its subject to an exact local commit:\n\n1. Use skill `product-tree:sync-base` before every deterministic verification command and before every dispatch, and record the result it returns — `already_current` or `rebased` — for the exact head, read from the command and never from memory. Only origin knows the base moved; a result established on a head behind the fetched base tip is a verdict on a tree that cannot merge, and every verifier's resolver refuses that head as a `stale-base` block. A `rebased` result reopens the deterministic results and Verifier verdicts its preservation proof does not cover.\n2. Changes may remain uncommitted until another agent session or human is expected or asked to read them. Before dispatching an audit or review, run the touched-scope deterministic verification required by the repository overlay when preparing a gate. Do not run an aggregate gate whose generated-output drift check requires committed generator sources and generated output before creating the checkpoint.\n3. When the relevant tracked or untracked files differ from `HEAD`, use skill `product-tree:commit-changes` before dispatch to commit the exact current version regardless of whether the latest verification state is `passing`, `failing`, or `not-run`; preserve that state in the checkpoint result. After any further change, commit the new version before another audit or review.\n4. Confirm the worktree is clean and record the checkpoint's full `HEAD` commit ID.\n5. Dispatch the gate only when the required deterministic verification is `passing`, against the committed `\u003Cbase>..\u003Chead>` scope. A `failing` or `not-run` checkpoint remains valid local history for recovery and collaboration while withholding gate dispatch. Do not supply a live file list for a gating run. The repository's declared full deterministic gate, when required, runs once against the clean checkpoint head as a later lifecycle step rather than before every checkpoint.\n6. Emit the complete `VERIFICATION_DISPATCH_READY` record `\u002Fmerging-standards` `\u003Cverification_dispatch_readiness>` defines, bound to that exact clean head, and dispatch only once it is complete. `VERIFICATION_DISPATCH_BLOCKED` withholds the dispatch until the named field, subject, result, writer, or defect class is resolved.\n\nAn audit or review over modified or untracked files is advisory. It may provide early feedback, but it never satisfies a Step 4, Step 8, Step 8a, Step 9, or merge-readiness predicate. Commit the exact version before dispatching any persisted gate or asking another agent session or human to read a reusable verification subject.\n\nA Verifier that returns a `stale-base` block returned no verdict: use skill `product-tree:sync-base`, re-establish the deterministic results on the rebased head, checkpoint, and dispatch again. After a rejected audit or valid `blocking` review finding, repair the defect class, rerun deterministic verification, and create a new checkpoint commit before redispatch. Append the rejection to the record's `priorRejections` — Verifier, exact head, finding identifiers, defect classes, failed repair invariant, root cause, widened repair rule, and same-class scan — and record in the new head's `sameClassScans` the cited clause each repair applies and the check that shows its class closed. Redispatch only once the new head's record proves every rejection resolved. The next Verifier's verdict, never the recorded check, decides whether the class closed. Preserve the earlier checkpoint identity while its run remains prior context; do not amend the audited commit in place.\n\n\u003C\u002Fverification_checkpoint>\n\n\u003Cresult_carryover>\n\nEach Verifier result is preserved once where that Verifier's own skill records it — the review journal for `changes-reviewer`, the `spx verification run` record for `implementation-auditor`, the returned structured verdict for every Auditor that returns one. What the flow carries forward from there is the bounded projection `\u002Fmerging-standards` `\u003Cverification_result_projection>` defines: the result reference or raw run token, exact head, verdict, finding identifiers, defect classes, and next required action.\n\nReopen the complete result by reference when a finding needs exact detail. Never re-paste a complete Verifier payload into a later step, a queue transition to the next node, or the closeout.\n\n\u003C\u002Fresult_carryover>\n\n\u003Cevidence_auditor_gate>\n\nAfter Step 8, run the applicable artifact-type evidence auditors over the stabilized diff. This gate applies to node-local and cross-node changes. It is the flow's only evidence audit, and it checks every evidence artifact the final changeset would publish. It runs after implementation because an agentic gate dispatches only once deterministic verification passes on its subject, and the evidence Step 5 establishes passes only after Step 7 implements what it verifies.\n\nRun deterministic verification first. Bring local validation, tests, and required eval runs to passing for the touched scope before dispatching evidence auditors. An evidence auditor reads and judges evidence quality; it never runs deterministic verification.\n\nDispatch `{{! subagent_name('product-tree', 'test-evidence-auditor') !}}` during Step 8a when the diff creates or modifies any `[test]` assertion, linked test file, or test-infrastructure artifact imported by a linked test. For each affected governing node, pass only its canonical node path. The invoked audit discovers the assertions, linked tests, and complete evidence chain. If the auditor returns `REJECTED`, `UNKNOWN`, a failing row, an unknown row, or a reject finding, fix the evidence defect class, re-run deterministic verification, and re-dispatch Step 8a.\n\nDispatch `{{! subagent_name('product-tree', 'eval-evidence-auditor') !}}` during Step 8a when the diff creates or modifies any `[eval]` assertion, `eval.toml`, `prompt.md`, `cases.jsonl`, `history.jsonl`, or producer artifact for an eval-backed assertion. For each affected governing node, pass only its canonical node path. The invoked audit discovers the assertions, eval artifacts, and producers. If the auditor returns `FAIL`, `UNKNOWN`, a failing row, an unknown row, or a reject finding, fix the evidence defect class, re-run the required eval evidence, and re-dispatch Step 8a.\n\nBefore dispatching an applicable evidence auditor, apply `\u003Cverification_checkpoint>`; carry each verdict forward under `\u003Cresult_carryover>`. When both evidence classes changed, dispatch both auditors against the same checkpoint. When the scope is cross-node (see `\u003Cscope_detection>`), enumerate every governed node whose linked test or eval evidence the change creates, modifies, or invalidates, and dispatch each applicable auditor once per governed node and evidence type, in parallel when independent. Step 8a completes only after every applicable evidence-auditor verdict is clean on the exact committed diff it reviews.\n\n\u003C\u002Fevidence_auditor_gate>\n\n\u003Cskill_map>\n\nStep 0 and Steps 1–2 are language-independent. Steps 3–8 use the detected language. Steps 9 and 10 are language-independent; Step 0 runs only when the work is described as a plan or proposal rather than a specific node or queue, Step 9 runs only when the change reaches beyond the target node, and Step 10 runs unless the work is explicitly scoped to a proposal, analysis, review, or local-only change.\n\n| Step | Purpose                  | TypeScript                                                                                                                                | Python                                                    | Rust                                                  | Go                                                |\n| ---- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------- |\n| 0 §  | Select the slice         | {!% require_skill 'product-tree:slice' %!}                                                                                                | same                                                      | same                                                  | same                                              |\n| 1    | Load methodology         | {!% require_skill 'product-tree:understand' %!}                                                                                           | same                                                      | same                                                  | same                                              |\n| 2    | Load context             | Use skill `product-tree:contextualize` for `{full-spx-node-path}`.                                                                        | same                                                      | same                                                  | same                                              |\n| 3    | Architect                | {!% require_skill 'typescript:author-typescript-architecture' %!}                                                                         | {!% require_skill 'python:author-python-architecture' %!} | {!% require_skill 'rust:author-rust-architecture' %!} | {!% require_skill 'go:author-go-architecture' %!} |\n| 4    | Architecture audit       | `{{! subagent_name('product-tree', 'adr-auditor') !}}` agent                                                                              | same                                                      | same                                                  | same                                              |\n| 5    | Establish evidence       | {!% require_skill 'product-tree:verify' %!}                                                                                               | same                                                      | same                                                  | same                                              |\n| 6    | Confirm failing evidence | Run the evidence Step 5 established                                                                                                       | same                                                      | same                                                  | same                                              |\n| 7    | Implement                | {!% require_skill 'typescript:author-typescript-code' %!}                                                                                 | {!% require_skill 'python:author-python-code' %!}         | {!% require_skill 'rust:author-rust-code' %!}         | {!% require_skill 'go:author-go-code' %!}         |\n| 7a   | Simplify implementation  | {!% require_skill 'typescript:simplify-typescript-code' %!}                                                                               | no simplification skill                                   | {!% require_skill 'rust:simplify-rust-code' %!}       | {!% require_skill 'go:simplify-go-code' %!}       |\n| 8    | Implementation audit     | `{{! subagent_name('product-tree', 'implementation-auditor') !}}` agent                                                                   | same                                                      | same                                                  | same                                              |\n| 8a   | Evidence-auditor gates   | `{{! subagent_name('product-tree', 'test-evidence-auditor') !}}`, `{{! subagent_name('product-tree', 'eval-evidence-auditor') !}}` agents | same                                                      | same                                                  | same                                              |\n| 9    | Whole-changeset review † | `{{! subagent_name('product-tree', 'changes-reviewer') !}}` agent                                                                         | same                                                      | same                                                  | same                                              |\n| 10   | Merge ‡                  | {!% require_skill 'product-tree:merge' %!}                                                                                                | same                                                      | same                                                  | same                                              |\n\n§ Step 0 runs only when the work is described as a plan or proposal rather than a specific node or queue; it selects the observable slice whose node set becomes the work queue (see `\u003Cinvocation_modes>`).\n† Step 9 runs only when the change touches files or specs beyond the target node (see the step for the condition).\n‡ Step 10 runs for any change destined for the default branch — skip only when the user explicitly scoped the work to a proposal, analysis, review, or local-only change (see the step).\n\nInvoke the exact skill or agent surface shown. Never substitute, skip, or reorder.\n\n\u003C\u002Fskill_map>\n\n\u003Cworkflow>\n\n\u003Cstep number=\"0\" name=\"Select the slice\" frequency=\"only for a plan or proposal\">\n\nUse skill `product-tree:slice` when the work is described as a plan or proposal rather than a specific node or queue, per `\u003Cinvocation_modes>`; its node set becomes the work queue. Skip this step for a specific node or an `spx\u002FEXCLUDE` list.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"1\" name=\"Load methodology\" frequency=\"once per session and after every compaction\">\n\nUse skill `product-tree:understand`.\n\nThis loads the product-tree methodology — node types, assertion formats, durable map rules. Skip only while a live `\u003CPRODUCT_TREE_FOUNDATION>` marker is present: after a compaction the marker counts as absent until this step emits it again.\n\n**Do not proceed until complete.**\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"2\" name=\"Load work item context\" frequency=\"every node and after every compaction\">\n\nUse skill `product-tree:contextualize` with the canonical full `spx\u002F...` node path from the work queue.\n\nLoad the full context hierarchy for the specific node — parent chain, sibling nodes, applicable decisions, assertions.\n\n**Repeat for every new node, and for the current node after every compaction**, which empties the set of contextualized nodes. Do not reuse context from a previous node.\n\n**Do not proceed until complete.**\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"3\" name=\"Architect\">\n\nInvoke the architecting skill for the detected language.\n\nProduce the ADR(s) for the work item. The architecture must be complete before audit.\n\nBefore the architecture audit, use skill `product-tree:verify` separately for every new or changed ADR\u002FPDR path. This moves each decision rule into its canonical verification subsection and supplies that subsection's tag before the auditor judges the decision. Keep target-node assertion routing in Step 5; this pre-audit decision routing creates no executable evidence link inside the decision record.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"4\" name=\"Architecture audit\" gate=\"true\">\n\nDispatch `{{! subagent_name('product-tree', 'adr-auditor') !}}` with only the ADR path. The invoked `audit-adr` discovers its governing node, committed changeset, and implementation-language partitions, then composes each applicable `audit-{lang}-architecture` concern inside its isolated agent session. Require its structured JSON verdict.\n\nWhen the scope is cross-node (see `\u003Cscope_detection>`), enumerate the ADRs governing every affected implementation surface across the whole changeset and dispatch each ADR path separately. This gate passes only when every required ADR audit approves.\n\nBefore invoking the audit, apply `\u003Cstabilized_diff_rule>` and `\u003Cverification_checkpoint>`; carry its verdict forward under `\u003Cresult_carryover>`.\n\n**REJECTED -> fix the defect class -> re-dispatch this step within the gate cap `\u003Creview_gates>` states.** The step passes only on `APPROVED`; a second counted rejection stops the flow.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"5\" name=\"Establish evidence\">\n\nUse skill `product-tree:verify` for the target node. It selects each assertion's verification type and routes selected test work through `\u002Ftest` to the detected language specialist. It routes eval work through `\u002Feval` when that capability is installed and records pathless audit requirements without producing their verdict.\n\nEstablish every selected path-bearing evidence definition before implementation. When `\u002Fverify` selects test, the linked tests exist before implementation. When it selects evaluate, the eval definition, cases, prompt, and producer contract exist before implementation. A pathless audit selection records the isolated-verifier requirement and creates no preimplementation artifact.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"6\" name=\"Confirm failing evidence\">\n\nRun the repository's touched-scope validation, and its test and eval commands over the evidence Step 5 created or changed. Validation passes, every other test and eval passes, and each new or changed test or eval fails only because the implementation it verifies is absent — a missing module, symbol, command, or behavior.\n\nA new or changed test or eval that passes here does not verify the absent behavior, and one that fails for any other cause — a syntax error, an import path the evidence itself gets wrong, a broken fixture — is defective evidence. Repair either through Step 5, then run this step again. Record each command, its exit code, and the failure each new or changed test or eval reports; Step 7 runs the same commands to passing.\n\nThis step dispatches no Verifier. An agentic gate dispatches only once deterministic verification passes on its subject, per `\u003Cverification_checkpoint>`, so the evidence audit runs at Step 8a, after implementation. A pathless audit requirement creates no artifact for this step; its isolated verifier produces the eventual verdict.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"7\" name=\"Implement\">\n\nInvoke the coding skill for the detected language.\n\nWrite implementation code, then run every applicable deterministic check selected in Step 5: selected tests pass and selected evals meet their declared completion threshold. Preserve each pathless audit requirement for its isolated verifier; never fabricate a test artifact for it.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"7a\" name=\"Simplify implementation\">\n\nFor Go, Rust, or TypeScript, run the language's simplification skill selected in `\u003Cskill_map>` in this conversation after Step 7. A language that ships no simplification skill skips this step.\n\nBefore running it, use skill `product-tree:commit-changes` when needed and require a clean worktree. Record the full committed head. Supply only `HEAD`, or the explicit three-dot range used for the selected base, as its target. The language skill independently selects the changed implementation and its governing evidence.\n\nRequire the skill's JSON result with `status`, `reason`, `target`, `base`, `head`, `scope`, `changed_paths`, `changes`, `evidence`, `verification`, `blockers`, and `recovery`. Check the returned target and full head against the committed subject, inspect every retained edit and command result, and apply the result contract:\n\n- `simplified`: inspect the retained patch for scope and behavior preservation. Complete any still-required deterministic checks, then checkpoint every resulting edit before Step 8. Preserve the successful command results against that exact content; do not repeat commands whose subject is unchanged.\n- `unchanged`: require no retained edit and a reason explaining the empty scope or absence of a safe improvement, then continue.\n- `blocked` or `failed`: preserve the complete prerequisite or verification diagnostic and recovery outcome; stop this node before Step 8. Repair the named prerequisite or implementation through its owning workflow. A new simplification run requires a repaired, verified, committed subject.\n\nAn absent or malformed result stops this node before Step 8 with the exact failure. A simplification result supplies no independent audit approval. Step 8 and every applicable evidence and review gate remain required. If later repair changes implementation, repeat Step 7a on the repaired committed subject before its final audits.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"8\" name=\"Code audit\" gate=\"true\">\n\nDispatch `{{! subagent_name('product-tree', 'implementation-auditor') !}}` with only\nthe committed scope selector: `HEAD` for the current branch, or an explicit\nthree-dot range for a selected base. The invoked skill discovers the repository,\ngoverning nodes, verification context, and language partitions; the wrapper\nsupplies its own run-driver identity internally.\n\nWhen the scope is cross-node (see `\u003Cscope_detection>`), point this audit at the **whole changeset**, not only the target node — Step 4 audits the committed scope while Step 8a fans out across every affected governed evidence node and type. Those audit lenses remain necessary but insufficient, so the distinct whole-diff review in Step 9 stays required for cross-cutting effects no single audit lens catches.\n\nBefore invoking the audit, apply `\u003Cstabilized_diff_rule>` and `\u003Cverification_checkpoint>`; carry its verdict forward under `\u003Cresult_carryover>`.\n\nDo not invoke the `audit-{lang}-{code|test|architecture}` concern skills directly from this workflow. Read the returned rendered projection: its `terminalStatus` is the Step 8 verdict — `approved` passes, `rejected` requires repair, and a missing projection or `BLOCKED` result blocks the gate. A command-failure `BLOCKED` result is complete only when it carries the run token or `not-started`, exact command, payload source, payload key, exit code, and stderr, including a failed preparation command. A missing-input diagnostic carries `runToken: not-started` and the exact missing selector or identity. A pre-run skill-load `BLOCKED` result is complete only when it carries run token `not-started`, required skill `product-tree:audit-implementation`, and the exact load or availability failure.\n\n**Projection `terminalStatus: rejected` -> fix the defect class; complete `BLOCKED` diagnostic -> repair the named preparation, input, command, payload, installation, or skill-load boundary.** Verify and checkpoint the changed subject before a new audit. A failed launch or unusable result follows `\u003Claunch_contract>` immediately.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"8a\" name=\"Evidence-auditor gates\" gate=\"true\" condition=\"the change creates or modifies test or eval evidence\">\n\nRun `\u003Cevidence_auditor_gate>` whenever the stabilized diff creates or modifies a `[test]` assertion, linked test file, imported test-infrastructure artifact, `[eval]` assertion, eval artifact, or producer artifact for eval-backed evidence. The condition applies whether the change is node-local or cross-node.\n\nSkip this step only when the diff changes no test or eval evidence surface named by `\u003Cevidence_auditor_gate>`.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"9\" name=\"Whole-changeset review\" gate=\"true\" condition=\"the change touches files or specs beyond the target node\">\n\nSkip this step only when the entire diff is confined to the target node's own directory — its spec, its `tests\u002F`, and the implementation files that node governs. The moment the work touches anything else — a refactor, a move, a consolidation, a cross-cutting rename, a shared enabler, a sibling spec, or any file outside the target node — this step is REQUIRED before the flow may be declared complete.\n\nBefore invoking the review, confirm every applicable Step 8a evidence-auditor verdict is clean, then apply `\u003Cverification_checkpoint>`. The reviewer must see the same committed diff whose touched evidence artifacts passed their artifact-type evidence audits.\n\nDispatch `{{! subagent_name('product-tree', 'changes-reviewer') !}}` over the full committed changeset, passing only the raw scope token: `HEAD` for the current branch or an explicit committed range for a selected base. Never add a prose prompt, severity filter, or emphasis instruction. Collect the final message through the native result-collection capabilities and require it to be the raw review run token. A tool failure, terminal result without a final message, or non-token final message blocks Step 9 and follows `\u003Claunch_contract>`.\n\nUse skill `product-tree:project-run-journal`, then inspect the returned token through its `render_review_run.py` helper exactly as that skill directs. Treat the helper output as the inspection projection of the sealed journal prefix; the sealed prefix remains the only review result. Read the rendered terminal status, full head\u002Fbase identity, scope coverage, blocking\u002Fdebt counts, and findings before deciding whether Step 9 converged. Carry the review forward as the bounded projection `\u003Cresult_carryover>` defines.\n\nThe per-node gates in Steps 4, 8, and 8a inspect through distinct audit lenses; they do not see every cross-node effect — a stale reference a rename left in a sibling, dead code a move orphaned, or a spec a consolidation made false. The whole-diff review catches those effects.\n\nApply `\u003Cstabilized_diff_rule>` before invoking the review. Fix every valid `blocking` finding in the rendered sealed projection, including every instance the cited clause covers that the same-class sweep finds and nothing the clause does not require, record each repair's clause and closing check per `\u003Cstabilized_diff_rule>`. Pass each new `debt` finding on text the changeset touches or invalidates up the chain of positions for its ruling as `\u002Fmerging-standards` directs, with its entry key, and act on it only as the ruling directs; record a finding a ruling accepts once in the governing node's `ISSUES.md` under a heading that ends with its entry key as three code spans, per the accepted-finding paragraph of `\u002Fmerging-standards` `\u003Cauthority_gates>`; a `debt` finding counts as no rejection. Then verify and checkpoint the changed subject before reviewing it again within the gate cap `\u003Creview_gates>` states; a second counted rejection stops the flow. A missing or unusable raw token follows `\u003Claunch_contract>`. If rendering a valid token fails, preserve that token and diagnose the inspection failure through `\u002Fproject-run-journal`; never launch another reviewer to replace the recorded result. The gate remains blocked until the sealed result is readable, every valid `blocking` finding is resolved, and every `debt` finding on touched or invalidated text has a ruling acted on or carries the label `TRACKED`.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"10\" name=\"Merge\" condition=\"the change is destined for the default branch\">\n\nSkip this step only when the user explicitly scoped the work to a proposal, analysis, review, or local-only change — then state that scope and stop. For every other change, the work is destined for the default branch, and the flow is NOT complete at Step 9.\n\nLocal readiness is not delivered value. A Step 8 projection with `terminalStatus: approved`, a converged Step 9 review, passing tests, a clean working tree, and a local commit ahead of base are progress. Delivered value is the change merged to the default branch on origin.\n\nUse skill `product-tree:merge`. It selects the transport and drives the change to the default branch under its own authority gates — this flow neither re-implements the merge protocol nor re-decides those gates. The `\u002Fmerge` lifecycle owns commit, push, integration review, and merge.\n\nThe flow is complete only when the change reaches the default branch on origin, or an explicit merge lifecycle gate blocks with no independent local action remaining. A clean working tree, a local commit, or a branch ahead of base is never the endpoint for default-branch work.\n\nClaude tends to report the flow done the moment Step 9 converges and tests pass — while nothing has been committed, pushed, reviewed at integration time, or merged. That treatment of local readiness as completion is the exact failure this step exists to prevent.\n\n\u003C\u002Fstep>\n\n\u003C\u002Fworkflow>\n\n\u003Cterminal_full_gate>\n\nWhen the repository overlay, governing node, or merge lifecycle requires a full deterministic bundle, run the repository's declared full deterministic gate exactly once at the terminal verification point: after Steps 4, 8, applicable Step 8a evidence-auditor gates, and Step 9 have converged on the same clean committed head. Do not run that full gate before those agentic checks, inside an auditor, or concurrently with another heavy command.\n\nIf the full deterministic gate fails, fix the reported defect, run the focused touched-scope checks, create a new checkpoint commit, rerun every invalidated agentic gate, and only then run the declared full gate again. A successful full gate is invalidated by any subsequent source, test, spec, generated-output, or configuration change.\n\n\u003C\u002Fterminal_full_gate>\n\n\u003Creview_gates>\n\nSteps 4, 8, and applicable Step 8a are blocking audit gates. Steps 4 and 8a emit verdicts from their auditor contracts. Step 8 returns an `spx verification run` token, run file, and rendered projection whose `terminalStatus` is authoritative; a `BLOCKED` result must relay a complete diagnostic from the implementation-auditor contract as described in Step 8. Step 9 is a blocking whole-changeset review gate that runs whenever the change reaches beyond the target node. Step 10 is the terminal lifecycle boundary for default-branch work.\n\n- Before starting Step 5: require Step 4's workflow-local result to be `APPROVED`. If it is absent or differs, stop and invoke or repair Step 4.\n- Before starting Step 7: require Step 6's record that validation and every other test and eval pass, and that each new or changed test or eval fails only because the implementation it verifies is absent. If the record is absent, run Step 6; if it differs, repair the evidence through Step 5 and run Step 6 again.\n- Before considering implementation complete: inspect the Step 8 rendered projection. If `terminalStatus` is absent or differs from `approved`, stop — invoke or repair Step 8.\n- Before Step 8 for Go, Rust, or TypeScript, require Step 7a's usable `simplified` or `unchanged` result for the implementation being verified, with every resulting edit inspected, verified, and committed.\n- Before starting Step 9, the terminal full deterministic gate, Step 10, or completion: if the diff touches a test or eval evidence surface named by `\u003Cevidence_auditor_gate>`, require a clean Step 8a verdict over the exact committed diff and invoke or repair Step 8a when that verdict is absent. When the diff touches no named evidence surface, skip Step 8a.\n- Before declaring the flow complete: if the change touches anything beyond the target node, require a raw Step 9 review run token from the native final result and a rendered sealed projection from `\u002Fproject-run-journal`. If no invocation has occurred, invoke Step 9. A failed invocation or unusable final result follows `\u003Claunch_contract>`; a blocked inspection preserves its token; valid `blocking` findings follow the repair workflow, and a `debt` finding follows Step 9.\n- Before using skill `product-tree:merge` when a full deterministic bundle is required: confirm the repository-declared full deterministic gate ran after every applicable agentic gate and against the current clean committed head. If any source, test, spec, generated-output, or configuration file changed afterward, rerun the invalidated agentic gates before running the declared full gate again.\n- Before declaring the flow complete for default-branch work: confirm the change reached the default branch on origin through Step 10's `\u002Fmerge`, or that the user scoped the work to a proposal, analysis, review, or local-only change, or that an explicit merge lifecycle gate blocks with no independent local action remaining. A clean working tree, a local commit, or a branch ahead of base does not satisfy this — invoke Step 10.\n\nFor completed verdicts of `REJECTED`, `UNKNOWN`, or a complete `BLOCKED` diagnostic at Steps 4 and 8a; projection `terminalStatus: rejected` or a complete blocked diagnostic at Step 8; or valid `blocking` findings at Step 9: fix the defect class per `\u003Cstabilized_diff_rule>`, bounded to the cited clause and recorded with its closing check, verify and checkpoint the changed subject, then audit that subject within the gate cap below. Use Step 8's complete blocked diagnostic to identify the failed command, payload, installation, or skill-load boundary. Launch failures, unusable results, and blocked inspection of a valid review token follow `\u003Claunch_contract>` and Step 9; they never enter this relaunch loop.\n\n**Gate cap: each gate launches at most twice, counting real rejections.** A gate is one Verifier definition judging one subject: one ADR path at Step 4, one governed node and evidence type at Step 8a, the committed scope at Step 8, and the whole changeset at Step 9. The cap covers the Step 9 review as well as the audit gates.\n\n- A rejection counts when at least one blocking finding, or a debt finding an audit raises, of a completed verdict — `REJECTED` or `UNKNOWN`, a failing or unknown row, projection `terminalStatus: rejected`, or a valid Step 9 `blocking` finding — sits on a line the changeset changed, or is caused by its edit, read from the diff against the base, and a complete `BLOCKED` diagnostic from an audit gate counts as a rejection with no finding to read. A `debt` finding the Step 9 review raises, a finding already filed in the owning node's `ISSUES.md`, a stale finding, a finding on untouched text, and a rejection whose run a recorded override names as the verdict it sets aside count for nothing; a launch that seals no run counts for nothing.\n- A second counted rejection on the same gate, one no recorded override sets aside -> STOP the flow. Report through `{{! tool('ask_user') !}}` the gate, both verdicts, the outstanding findings, and the same-class sweep already performed. NEVER launch a gate a third time, and NEVER repeat a gate until it approves.\n- The cap covers agentic gates only. A deterministic check that fails runs again after its repair outside the cap.\n\nA failed launch or unusable result stops on its first occurrence under `\u003Claunch_contract>`.\n\n\u003C\u002Freview_gates>\n\n\u003Crationale>\nWhen something breaks or behaves unexpectedly, Claude's instinct is to write ad hoc code — a quick script, a throwaway snippet, a print-and-pray debugging session. That instinct is the symptom, not the fix. The problem surfaced because the tests were insufficient. The ad hoc code patches over one instance; a proper test catches every future instance too.\n\n1. **Do not** write ad hoc code to \"see what's happening.\"\n2. **Do** write a test that reproduces the problem. Hitting this issue proves the test coverage has a gap.\n3. **Then** fix the implementation until the test passes.\n\nThis is not slower. The ad hoc script takes the same effort as a test, but the script gets deleted and the test stays.\n\n\u003C\u002Frationale>\n\n\u003Cfailure_modes>\n\n**Failure 1: Claude closed the flow at Step 9.** Claude reported the flow complete the moment the Step 8 audit passed, tests were green, and the Step 9 review converged — while nothing had been committed, pushed, reviewed at integration time, or merged. Signal: a \"done\" claim for default-branch work with a clean working tree or a local commit ahead of base and no merged PR. Avoid: for default-branch work the flow is incomplete until Step 10 reaches the default branch on origin; local readiness is progress, never delivered value.\n\n**Failure 2: Claude patched the cited line instead of the defect class.** An audit gate or the Step 9 review cited one instance; Claude fixed that line, re-ran the gate, and the same class reopened on the next iteration elsewhere. Signal: repeated rejected verdicts reopening the same rule, source contract, or evidence pattern. Avoid: per `\u003Cstabilized_diff_rule>`, treat each finding as defect-class evidence — sweep the touched node(s) under the cited clause, fix every instance that clause covers and nothing it does not require, record the clause and the closing check, then run the gate once on the stabilized tree.\n\n**Failure 3: Claude planned an evidence audit before implementation.** Claude wrote the tests at Step 5 and tried to audit them before Step 7, while they failed for want of the implementation. The dispatch could never proceed, because an agentic gate requires passing deterministic verification, and the flow stalled between two of its own rules. Signal: an evidence-auditor dispatch planned while new tests fail. Avoid: Step 6 confirms the failures deterministically, and Step 8a audits the evidence once Step 7 makes it pass.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- Every product-declared touched-scope deterministic command exits zero on the final committed subject.\n- Each applicable architecture and test-evidence auditor returns `APPROVED`; each applicable eval-evidence auditor returns JSON `overall: PASS` with no `FAIL` or `UNKNOWN` row; and each implementation-audit run renders `terminalStatus: approved` for the exact committed subject.\n- A cross-node changeset carries a raw Step 9 review run token whose sealed projection renders successfully, with every valid `blocking` finding fixed, every `debt` finding on touched or invalidated text ruled on or labeled `TRACKED`, including every instance its cited clause covers and nothing the clause does not require, and each repair's clause and closing check recorded in the next `VERIFICATION_DISPATCH_READY` record; unbacked findings are dropped.\n- `git rev-parse HEAD` matches the final gate subject and `git status --porcelain` is empty.\n- The requested delivery boundary has observable completion: default-branch work has reached the default branch on origin through `\u002Fmerge`'s selected transport and every declared release action reports success or no-op; proposal, analysis, review, or local-only work reaches its explicitly selected boundary; an explicit lifecycle gate reports its blocking token only after no independent action remains.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nA product-tree work item implemented, verified, and delivered to the boundary the user requested — the default branch on origin unless the request names a narrower one.\n\n\u003C\u002Fobjective>\n\n\u003Cinvocation_modes>\n\nThe raw invocation string `$ARGUMENTS` controls what runs before the per-node flow below. Parse it exactly once before Step 0:\n\n- `$ARGUMENTS` containing a canonical full `spx\u002F...` node path → the work queue is that single node.\n- Empty `$ARGUMENTS` → determine the work from the conversation. If nothing is clear, complete Step 1 first — use skill `product-tree:understand` when the live `PRODUCT_TREE_FOUNDATION` marker is absent — then read `spx\u002FEXCLUDE`, whose entries are relative to `spx\u002F`, and prefix each non-comment, non-blank entry with `spx\u002F` before adding it to the work queue. Never access `spx\u002FEXCLUDE` before the foundation is live, and never pass a bare entry to `\u002Fcontextualize`. If no work is found, report \"Nothing to apply\" and stop.\n\nWhen the work is described as a plan or proposal rather than a specific node or queue, use skill `product-tree:slice` first: it selects the next executable observable slice and produces the node set that becomes this flow's work queue. Skip the preflight when the queue is already a specific node or an `spx\u002FEXCLUDE` list.\n\nComplete Step 1 before the queue loop in every mode, so the foundation is live before the loop reads or edits `spx\u002FEXCLUDE`. When the queue holds more than one node, order by numeric index prefix (lower first) — lower-indexed nodes constrain higher-indexed ones. For each node in order:\n\n1. Strip the canonical node path's leading `spx\u002F` to derive its `spx\u002FEXCLUDE` entry. If that relative entry is listed, remove its exact line first — the `spx` CLI then includes its tests in `spx test passing`.\n2. Run Steps 2–9 on the node, and Step 1 again first when a compaction has made the foundation marker absent.\n3. Confirm the final gate subject is committed and the worktree is clean.\n4. Proceed to the next node without stopping or asking, subject to the gate cap of two counted rejections in `\u003Creview_gates>`.\n\nIf a node's flow cannot reach its gate-specific passing state or a passing review within the gate cap of two counted rejections, stop the queue, report the failed node and step, and leave the remaining nodes in `spx\u002FEXCLUDE`. Step 10 (`\u002Fmerge`) runs once over the whole changeset after the queue completes.\n\n\u003C\u002Finvocation_modes>\n\n\u003Clanguage_detection>\n\nBefore starting Step 3, determine the product language:\n\n- `tsconfig.json` exists -> **TypeScript**\n- `pyproject.toml` or `setup.py` exists -> **Python**\n- `Cargo.toml` or `rust-toolchain.toml` exists -> **Rust**\n- `go.mod` exists -> **Go**\n- Multiple supported language markers exist -> inspect the loaded spec node for a single applicable language; when ambiguity remains, ask the operator and stop before Step 3 until one language is selected\n- No supported marker exists, or the selected language has no installed architecture, test, and code skills -> stop before Step 3 and report the exact marker state plus the missing language-plugin capability\n\nProceed to Step 3 only after exactly one supported language and its required skill surface resolve. Use that language for ALL Steps 3–8. Do not switch mid-flow.\n\n\u003C\u002Flanguage_detection>\n\n\u003Cscope_detection>\n\nBefore starting Step 3, determine the change's scope — this determination governs every later gate:\n\n- **Node-local** — the entire diff stays within the target node's own directory (its spec, its `tests\u002F`, and the implementation files that node governs).\n- **Cross-node** — the work touches anything else: a refactor, a move, a consolidation, a cross-cutting rename, a shared enabler, a sibling spec, or any file outside the target node.\n\nWhen the scope is cross-node, every audit gate — Steps 4, 8, and 8a — runs at **whole-changeset** scope, not only the target node, and Step 9 is REQUIRED before the flow may be declared complete. A per-node audit reads only the target node's files; it cannot see a regression the change introduced in a file the node does not own. Carry the determination through Steps 4, 8, and 8a — each gate step restates the scope requirement at its point of action.\n\n\u003C\u002Fscope_detection>\n\n\u003Claunch_contract>\n\nEach audit or review step below requests exactly one native launch with its mapped subagent name and target-only prompt. Use the native tool schema and result-collection capabilities. A failed launch or unusable final result stops that invocation: analyze and report the exact failure without another launch, a substitute subagent or model, an alternative launch mechanism, or an audit in this conversation.\n\nPersist accepted requirements in decisions and specs before dispatch. Start each Verifier without authoring history, following the root guide's isolation mechanics. Never append an author-written context packet, reasoning, summary, or suggested verdict. The invoked skill independently discovers its evidence from the target and configured instructions.\n\nCompleted structured verdicts follow the existing finding-repair workflow: repair the defect class, verify and checkpoint the changed subject, then make one launch for that new subject. Never use a repair loop to replace a failed launch or unusable result. While the native capability reports work still running, collect that same invocation; an observation timeout never authorizes a new launch.\n\n\u003C\u002Flaunch_contract>\n\n\u003Cstabilized_diff_rule>\n\nBefore any audit gate or whole-changeset review runs, self-converge the diff: read the changed specs, tests, and implementation together; confirm the design is coherent; and fix obvious contradictions before asking an auditor or reviewer to find them. Audit gates confirm a stabilized design. They are not the design loop.\n\nWhen a gate returns `REJECTED`, `UNKNOWN`, or `BLOCKED`, or when a review surfaces a valid `blocking` finding, treat it as evidence of a defect class. Read the touched node(s) — the files they govern — find same-class instances, and fix the class before re-running the gate. The class is the rule the finding cites, as the cited standard defines that rule; the finding's examples are instances of the class, never its definition. Same-class means the same cited clause, the same source contract, evidence pattern, lifecycle step, generated-source relationship, or architectural boundary that clause governs. Fix every instance the cited clause covers across the touched node(s) and change nothing the clause does not require. A patch to the cited line alone is sufficient only when a sweep under that clause proves the defect isolated.\n\nRecord each repair with the clause it applies and the check that shows the class closed. That record enters the next `VERIFICATION_DISPATCH_READY` record under `\u003Cverification_checkpoint>`.\n\nDo not re-run a gate after every micro-edit. Batch the class fix, re-read the affected diff, then run the gate once on the stabilized tree.\n\nA rejection whose defect class a prior repair already claimed to close invalidates that repair invariant. Stop localized patching, analyze why the class survived, widen the repair and the same-class scan, and amend the governing workflow, standard, or source contract before the next dispatch. The work queue stops at the node that raised the repeat until that amendment lands; a new line number, file, or example does not make it a new class.\n\n\u003C\u002Fstabilized_diff_rule>\n\n\u003Cverification_checkpoint>\n\nUse skill `product-tree:merging-standards` and read its `merge-policy.md` reference before the first dispatch of the flow; `\u003Cverification_dispatch_readiness>` and `\u003Cverification_result_projection>` are its sections, and invoking the compact loader alone does not load them.\n\nBefore dispatching any persisted audit or review gate, bind its subject to an exact local commit:\n\n1. Use skill `product-tree:sync-base` before every deterministic verification command and before every dispatch, and record the result it returns — `already_current` or `rebased` — for the exact head, read from the command and never from memory. Only origin knows the base moved; a result established on a head behind the fetched base tip is a verdict on a tree that cannot merge, and every verifier's resolver refuses that head as a `stale-base` block. A `rebased` result reopens the deterministic results and Verifier verdicts its preservation proof does not cover.\n2. Changes may remain uncommitted until another agent session or human is expected or asked to read them. Before dispatching an audit or review, run the touched-scope deterministic verification required by the repository overlay when preparing a gate. Do not run an aggregate gate whose generated-output drift check requires committed generator sources and generated output before creating the checkpoint.\n3. When the relevant tracked or untracked files differ from `HEAD`, use skill `product-tree:commit-changes` before dispatch to commit the exact current version regardless of whether the latest verification state is `passing`, `failing`, or `not-run`; preserve that state in the checkpoint result. After any further change, commit the new version before another audit or review.\n4. Confirm the worktree is clean and record the checkpoint's full `HEAD` commit ID.\n5. Dispatch the gate only when the required deterministic verification is `passing`, against the committed `\u003Cbase>..\u003Chead>` scope. A `failing` or `not-run` checkpoint remains valid local history for recovery and collaboration while withholding gate dispatch. Do not supply a live file list for a gating run. The repository's declared full deterministic gate, when required, runs once against the clean checkpoint head as a later lifecycle step rather than before every checkpoint.\n6. Emit the complete `VERIFICATION_DISPATCH_READY` record `\u002Fmerging-standards` `\u003Cverification_dispatch_readiness>` defines, bound to that exact clean head, and dispatch only once it is complete. `VERIFICATION_DISPATCH_BLOCKED` withholds the dispatch until the named field, subject, result, writer, or defect class is resolved.\n\nAn audit or review over modified or untracked files is advisory. It may provide early feedback, but it never satisfies a Step 4, Step 8, Step 8a, Step 9, or merge-readiness predicate. Commit the exact version before dispatching any persisted gate or asking another agent session or human to read a reusable verification subject.\n\nA Verifier that returns a `stale-base` block returned no verdict: use skill `product-tree:sync-base`, re-establish the deterministic results on the rebased head, checkpoint, and dispatch again. After a rejected audit or valid `blocking` review finding, repair the defect class, rerun deterministic verification, and create a new checkpoint commit before redispatch. Append the rejection to the record's `priorRejections` — Verifier, exact head, finding identifiers, defect classes, failed repair invariant, root cause, widened repair rule, and same-class scan — and record in the new head's `sameClassScans` the cited clause each repair applies and the check that shows its class closed. Redispatch only once the new head's record proves every rejection resolved. The next Verifier's verdict, never the recorded check, decides whether the class closed. Preserve the earlier checkpoint identity while its run remains prior context; do not amend the audited commit in place.\n\n\u003C\u002Fverification_checkpoint>\n\n\u003Cresult_carryover>\n\nEach Verifier result is preserved once where that Verifier's own skill records it — the review journal for `changes-reviewer`, the `spx verification run` record for `implementation-auditor`, the returned structured verdict for every Auditor that returns one. What the flow carries forward from there is the bounded projection `\u002Fmerging-standards` `\u003Cverification_result_projection>` defines: the result reference or raw run token, exact head, verdict, finding identifiers, defect classes, and next required action.\n\nReopen the complete result by reference when a finding needs exact detail. Never re-paste a complete Verifier payload into a later step, a queue transition to the next node, or the closeout.\n\n\u003C\u002Fresult_carryover>\n\n\u003Cevidence_auditor_gate>\n\nAfter Step 8, run the applicable artifact-type evidence auditors over the stabilized diff. This gate applies to node-local and cross-node changes. It is the flow's only evidence audit, and it checks every evidence artifact the final changeset would publish. It runs after implementation because an agentic gate dispatches only once deterministic verification passes on its subject, and the evidence Step 5 establishes passes only after Step 7 implements what it verifies.\n\nRun deterministic verification first. Bring local validation, tests, and required eval runs to passing for the touched scope before dispatching evidence auditors. An evidence auditor reads and judges evidence quality; it never runs deterministic verification.\n\nDispatch `{{! subagent_name('product-tree', 'test-evidence-auditor') !}}` during Step 8a when the diff creates or modifies any `[test]` assertion, linked test file, or test-infrastructure artifact imported by a linked test. For each affected governing node, pass only its canonical node path. The invoked audit discovers the assertions, linked tests, and complete evidence chain. If the auditor returns `REJECTED`, `UNKNOWN`, a failing row, an unknown row, or a reject finding, fix the evidence defect class, re-run deterministic verification, and re-dispatch Step 8a.\n\nDispatch `{{! subagent_name('product-tree', 'eval-evidence-auditor') !}}` during Step 8a when the diff creates or modifies any `[eval]` assertion, `eval.toml`, `prompt.md`, `cases.jsonl`, `history.jsonl`, or producer artifact for an eval-backed assertion. For each affected governing node, pass only its canonical node path. The invoked audit discovers the assertions, eval artifacts, and producers. If the auditor returns `FAIL`, `UNKNOWN`, a failing row, an unknown row, or a reject finding, fix the evidence defect class, re-run the required eval evidence, and re-dispatch Step 8a.\n\nBefore dispatching an applicable evidence auditor, apply `\u003Cverification_checkpoint>`; carry each verdict forward under `\u003Cresult_carryover>`. When both evidence classes changed, dispatch both auditors against the same checkpoint. When the scope is cross-node (see `\u003Cscope_detection>`), enumerate every governed node whose linked test or eval evidence the change creates, modifies, or invalidates, and dispatch each applicable auditor once per governed node and evidence type, in parallel when independent. Step 8a completes only after every applicable evidence-auditor verdict is clean on the exact committed diff it reviews.\n\n\u003C\u002Fevidence_auditor_gate>\n\n\u003Cskill_map>\n\nStep 0 and Steps 1–2 are language-independent. Steps 3–8 use the detected language. Steps 9 and 10 are language-independent; Step 0 runs only when the work is described as a plan or proposal rather than a specific node or queue, Step 9 runs only when the change reaches beyond the target node, and Step 10 runs unless the work is explicitly scoped to a proposal, analysis, review, or local-only change.\n\n| Step | Purpose                  | TypeScript                                                                                                                                | Python                                                    | Rust                                                  | Go                                                |\n| ---- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------- |\n| 0 §  | Select the slice         | {!% require_skill 'product-tree:slice' %!}                                                                                                | same                                                      | same                                                  | same                                              |\n| 1    | Load methodology         | {!% require_skill 'product-tree:understand' %!}                                                                                           | same                                                      | same                                                  | same                                              |\n| 2    | Load context             | Use skill `product-tree:contextualize` for `{full-spx-node-path}`.                                                                        | same                                                      | same                                                  | same                                              |\n| 3    | Architect                | {!% require_skill 'typescript:author-typescript-architecture' %!}                                                                         | {!% require_skill 'python:author-python-architecture' %!} | {!% require_skill 'rust:author-rust-architecture' %!} | {!% require_skill 'go:author-go-architecture' %!} |\n| 4    | Architecture audit       | `{{! subagent_name('product-tree', 'adr-auditor') !}}` agent                                                                              | same                                                      | same                                                  | same                                              |\n| 5    | Establish evidence       | {!% require_skill 'product-tree:verify' %!}                                                                                               | same                                                      | same                                                  | same                                              |\n| 6    | Confirm failing evidence | Run the evidence Step 5 established                                                                                                       | same                                                      | same                                                  | same                                              |\n| 7    | Implement                | {!% require_skill 'typescript:author-typescript-code' %!}                                                                                 | {!% require_skill 'python:author-python-code' %!}         | {!% require_skill 'rust:author-rust-code' %!}         | {!% require_skill 'go:author-go-code' %!}         |\n| 7a   | Simplify implementation  | {!% require_skill 'typescript:simplify-typescript-code' %!}                                                                               | no simplification skill                                   | {!% require_skill 'rust:simplify-rust-code' %!}       | {!% require_skill 'go:simplify-go-code' %!}       |\n| 8    | Implementation audit     | `{{! subagent_name('product-tree', 'implementation-auditor') !}}` agent                                                                   | same                                                      | same                                                  | same                                              |\n| 8a   | Evidence-auditor gates   | `{{! subagent_name('product-tree', 'test-evidence-auditor') !}}`, `{{! subagent_name('product-tree', 'eval-evidence-auditor') !}}` agents | same                                                      | same                                                  | same                                              |\n| 9    | Whole-changeset review † | `{{! subagent_name('product-tree', 'changes-reviewer') !}}` agent                                                                         | same                                                      | same                                                  | same                                              |\n| 10   | Merge ‡                  | {!% require_skill 'product-tree:merge' %!}                                                                                                | same                                                      | same                                                  | same                                              |\n\n§ Step 0 runs only when the work is described as a plan or proposal rather than a specific node or queue; it selects the observable slice whose node set becomes the work queue (see `\u003Cinvocation_modes>`).\n† Step 9 runs only when the change touches files or specs beyond the target node (see the step for the condition).\n‡ Step 10 runs for any change destined for the default branch — skip only when the user explicitly scoped the work to a proposal, analysis, review, or local-only change (see the step).\n\nInvoke the exact skill or agent surface shown. Never substitute, skip, or reorder.\n\n\u003C\u002Fskill_map>\n\n\u003Cworkflow>\n\n\u003Cstep number=\"0\" name=\"Select the slice\" frequency=\"only for a plan or proposal\">\n\nUse skill `product-tree:slice` when the work is described as a plan or proposal rather than a specific node or queue, per `\u003Cinvocation_modes>`; its node set becomes the work queue. Skip this step for a specific node or an `spx\u002FEXCLUDE` list.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"1\" name=\"Load methodology\" frequency=\"once per session and after every compaction\">\n\nUse skill `product-tree:understand`.\n\nThis loads the product-tree methodology — node types, assertion formats, durable map rules. Skip only while a live `\u003CPRODUCT_TREE_FOUNDATION>` marker is present: after a compaction the marker counts as absent until this step emits it again.\n\n**Do not proceed until complete.**\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"2\" name=\"Load work item context\" frequency=\"every node and after every compaction\">\n\nUse skill `product-tree:contextualize` with the canonical full `spx\u002F...` node path from the work queue.\n\nLoad the full context hierarchy for the specific node — parent chain, sibling nodes, applicable decisions, assertions.\n\n**Repeat for every new node, and for the current node after every compaction**, which empties the set of contextualized nodes. Do not reuse context from a previous node.\n\n**Do not proceed until complete.**\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"3\" name=\"Architect\">\n\nInvoke the architecting skill for the detected language.\n\nProduce the ADR(s) for the work item. The architecture must be complete before audit.\n\nBefore the architecture audit, use skill `product-tree:verify` separately for every new or changed ADR\u002FPDR path. This moves each decision rule into its canonical verification subsection and supplies that subsection's tag before the auditor judges the decision. Keep target-node assertion routing in Step 5; this pre-audit decision routing creates no executable evidence link inside the decision record.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"4\" name=\"Architecture audit\" gate=\"true\">\n\nDispatch `{{! subagent_name('product-tree', 'adr-auditor') !}}` with only the ADR path. The invoked `audit-adr` discovers its governing node, committed changeset, and implementation-language partitions, then composes each applicable `audit-{lang}-architecture` concern inside its isolated agent session. Require its structured JSON verdict.\n\nWhen the scope is cross-node (see `\u003Cscope_detection>`), enumerate the ADRs governing every affected implementation surface across the whole changeset and dispatch each ADR path separately. This gate passes only when every required ADR audit approves.\n\nBefore invoking the audit, apply `\u003Cstabilized_diff_rule>` and `\u003Cverification_checkpoint>`; carry its verdict forward under `\u003Cresult_carryover>`.\n\n**REJECTED -> fix the defect class -> re-dispatch this step within the gate cap `\u003Creview_gates>` states.** The step passes only on `APPROVED`; a second counted rejection stops the flow.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"5\" name=\"Establish evidence\">\n\nUse skill `product-tree:verify` for the target node. It selects each assertion's verification type and routes selected test work through `\u002Ftest` to the detected language specialist. It routes eval work through `\u002Feval` when that capability is installed and records pathless audit requirements without producing their verdict.\n\nEstablish every selected path-bearing evidence definition before implementation. When `\u002Fverify` selects test, the linked tests exist before implementation. When it selects evaluate, the eval definition, cases, prompt, and producer contract exist before implementation. A pathless audit selection records the isolated-verifier requirement and creates no preimplementation artifact.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"6\" name=\"Confirm failing evidence\">\n\nRun the repository's touched-scope validation, and its test and eval commands over the evidence Step 5 created or changed. Validation passes, every other test and eval passes, and each new or changed test or eval fails only because the implementation it verifies is absent — a missing module, symbol, command, or behavior.\n\nA new or changed test or eval that passes here does not verify the absent behavior, and one that fails for any other cause — a syntax error, an import path the evidence itself gets wrong, a broken fixture — is defective evidence. Repair either through Step 5, then run this step again. Record each command, its exit code, and the failure each new or changed test or eval reports; Step 7 runs the same commands to passing.\n\nThis step dispatches no Verifier. An agentic gate dispatches only once deterministic verification passes on its subject, per `\u003Cverification_checkpoint>`, so the evidence audit runs at Step 8a, after implementation. A pathless audit requirement creates no artifact for this step; its isolated verifier produces the eventual verdict.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"7\" name=\"Implement\">\n\nInvoke the coding skill for the detected language.\n\nWrite implementation code, then run every applicable deterministic check selected in Step 5: selected tests pass and selected evals meet their declared completion threshold. Preserve each pathless audit requirement for its isolated verifier; never fabricate a test artifact for it.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"7a\" name=\"Simplify implementation\">\n\nFor Go, Rust, or TypeScript, run the language's simplification skill selected in `\u003Cskill_map>` in this conversation after Step 7. A language that ships no simplification skill skips this step.\n\nBefore running it, use skill `product-tree:commit-changes` when needed and require a clean worktree. Record the full committed head. Supply only `HEAD`, or the explicit three-dot range used for the selected base, as its target. The language skill independently selects the changed implementation and its governing evidence.\n\nRequire the skill's JSON result with `status`, `reason`, `target`, `base`, `head`, `scope`, `changed_paths`, `changes`, `evidence`, `verification`, `blockers`, and `recovery`. Check the returned target and full head against the committed subject, inspect every retained edit and command result, and apply the result contract:\n\n- `simplified`: inspect the retained patch for scope and behavior preservation. Complete any still-required deterministic checks, then checkpoint every resulting edit before Step 8. Preserve the successful command results against that exact content; do not repeat commands whose subject is unchanged.\n- `unchanged`: require no retained edit and a reason explaining the empty scope or absence of a safe improvement, then continue.\n- `blocked` or `failed`: preserve the complete prerequisite or verification diagnostic and recovery outcome; stop this node before Step 8. Repair the named prerequisite or implementation through its owning workflow. A new simplification run requires a repaired, verified, committed subject.\n\nAn absent or malformed result stops this node before Step 8 with the exact failure. A simplification result supplies no independent audit approval. Step 8 and every applicable evidence and review gate remain required. If later repair changes implementation, repeat Step 7a on the repaired committed subject before its final audits.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"8\" name=\"Code audit\" gate=\"true\">\n\nDispatch `{{! subagent_name('product-tree', 'implementation-auditor') !}}` with only\nthe committed scope selector: `HEAD` for the current branch, or an explicit\nthree-dot range for a selected base. The invoked skill discovers the repository,\ngoverning nodes, verification context, and language partitions; the wrapper\nsupplies its own run-driver identity internally.\n\nWhen the scope is cross-node (see `\u003Cscope_detection>`), point this audit at the **whole changeset**, not only the target node — Step 4 audits the committed scope while Step 8a fans out across every affected governed evidence node and type. Those audit lenses remain necessary but insufficient, so the distinct whole-diff review in Step 9 stays required for cross-cutting effects no single audit lens catches.\n\nBefore invoking the audit, apply `\u003Cstabilized_diff_rule>` and `\u003Cverification_checkpoint>`; carry its verdict forward under `\u003Cresult_carryover>`.\n\nDo not invoke the `audit-{lang}-{code|test|architecture}` concern skills directly from this workflow. Read the returned rendered projection: its `terminalStatus` is the Step 8 verdict — `approved` passes, `rejected` requires repair, and a missing projection or `BLOCKED` result blocks the gate. A command-failure `BLOCKED` result is complete only when it carries the run token or `not-started`, exact command, payload source, payload key, exit code, and stderr, including a failed preparation command. A missing-input diagnostic carries `runToken: not-started` and the exact missing selector or identity. A pre-run skill-load `BLOCKED` result is complete only when it carries run token `not-started`, required skill `product-tree:audit-implementation`, and the exact load or availability failure.\n\n**Projection `terminalStatus: rejected` -> fix the defect class; complete `BLOCKED` diagnostic -> repair the named preparation, input, command, payload, installation, or skill-load boundary.** Verify and checkpoint the changed subject before a new audit. A failed launch or unusable result follows `\u003Claunch_contract>` immediately.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"8a\" name=\"Evidence-auditor gates\" gate=\"true\" condition=\"the change creates or modifies test or eval evidence\">\n\nRun `\u003Cevidence_auditor_gate>` whenever the stabilized diff creates or modifies a `[test]` assertion, linked test file, imported test-infrastructure artifact, `[eval]` assertion, eval artifact, or producer artifact for eval-backed evidence. The condition applies whether the change is node-local or cross-node.\n\nSkip this step only when the diff changes no test or eval evidence surface named by `\u003Cevidence_auditor_gate>`.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"9\" name=\"Whole-changeset review\" gate=\"true\" condition=\"the change touches files or specs beyond the target node\">\n\nSkip this step only when the entire diff is confined to the target node's own directory — its spec, its `tests\u002F`, and the implementation files that node governs. The moment the work touches anything else — a refactor, a move, a consolidation, a cross-cutting rename, a shared enabler, a sibling spec, or any file outside the target node — this step is REQUIRED before the flow may be declared complete.\n\nBefore invoking the review, confirm every applicable Step 8a evidence-auditor verdict is clean, then apply `\u003Cverification_checkpoint>`. The reviewer must see the same committed diff whose touched evidence artifacts passed their artifact-type evidence audits.\n\nDispatch `{{! subagent_name('product-tree', 'changes-reviewer') !}}` over the full committed changeset, passing only the raw scope token: `HEAD` for the current branch or an explicit committed range for a selected base. Never add a prose prompt, severity filter, or emphasis instruction. Collect the final message through the native result-collection capabilities and require it to be the raw review run token. A tool failure, terminal result without a final message, or non-token final message blocks Step 9 and follows `\u003Claunch_contract>`.\n\nUse skill `product-tree:project-run-journal`, then inspect the returned token through its `render_review_run.py` helper exactly as that skill directs. Treat the helper output as the inspection projection of the sealed journal prefix; the sealed prefix remains the only review result. Read the rendered terminal status, full head\u002Fbase identity, scope coverage, blocking\u002Fdebt counts, and findings before deciding whether Step 9 converged. Carry the review forward as the bounded projection `\u003Cresult_carryover>` defines.\n\nThe per-node gates in Steps 4, 8, and 8a inspect through distinct audit lenses; they do not see every cross-node effect — a stale reference a rename left in a sibling, dead code a move orphaned, or a spec a consolidation made false. The whole-diff review catches those effects.\n\nApply `\u003Cstabilized_diff_rule>` before invoking the review. Fix every valid `blocking` finding in the rendered sealed projection, including every instance the cited clause covers that the same-class sweep finds and nothing the clause does not require, record each repair's clause and closing check per `\u003Cstabilized_diff_rule>`. Pass each new `debt` finding on text the changeset touches or invalidates up the chain of positions for its ruling as `\u002Fmerging-standards` directs, with its entry key, and act on it only as the ruling directs; record a finding a ruling accepts once in the governing node's `ISSUES.md` under a heading that ends with its entry key as three code spans, per the accepted-finding paragraph of `\u002Fmerging-standards` `\u003Cauthority_gates>`; a `debt` finding counts as no rejection. Then verify and checkpoint the changed subject before reviewing it again within the gate cap `\u003Creview_gates>` states; a second counted rejection stops the flow. A missing or unusable raw token follows `\u003Claunch_contract>`. If rendering a valid token fails, preserve that token and diagnose the inspection failure through `\u002Fproject-run-journal`; never launch another reviewer to replace the recorded result. The gate remains blocked until the sealed result is readable, every valid `blocking` finding is resolved, and every `debt` finding on touched or invalidated text has a ruling acted on or carries the label `TRACKED`.\n\n\u003C\u002Fstep>\n\n\u003Cstep number=\"10\" name=\"Merge\" condition=\"the change is destined for the default branch\">\n\nSkip this step only when the user explicitly scoped the work to a proposal, analysis, review, or local-only change — then state that scope and stop. For every other change, the work is destined for the default branch, and the flow is NOT complete at Step 9.\n\nLocal readiness is not delivered value. A Step 8 projection with `terminalStatus: approved`, a converged Step 9 review, passing tests, a clean working tree, and a local commit ahead of base are progress. Delivered value is the change merged to the default branch on origin.\n\nUse skill `product-tree:merge`. It selects the transport and drives the change to the default branch under its own authority gates — this flow neither re-implements the merge protocol nor re-decides those gates. The `\u002Fmerge` lifecycle owns commit, push, integration review, and merge.\n\nThe flow is complete only when the change reaches the default branch on origin, or an explicit merge lifecycle gate blocks with no independent local action remaining. A clean working tree, a local commit, or a branch ahead of base is never the endpoint for default-branch work.\n\nClaude tends to report the flow done the moment Step 9 converges and tests pass — while nothing has been committed, pushed, reviewed at integration time, or merged. That treatment of local readiness as completion is the exact failure this step exists to prevent.\n\n\u003C\u002Fstep>\n\n\u003C\u002Fworkflow>\n\n\u003Cterminal_full_gate>\n\nWhen the repository overlay, governing node, or merge lifecycle requires a full deterministic bundle, run the repository's declared full deterministic gate exactly once at the terminal verification point: after Steps 4, 8, applicable Step 8a evidence-auditor gates, and Step 9 have converged on the same clean committed head. Do not run that full gate before those agentic checks, inside an auditor, or concurrently with another heavy command.\n\nIf the full deterministic gate fails, fix the reported defect, run the focused touched-scope checks, create a new checkpoint commit, rerun every invalidated agentic gate, and only then run the declared full gate again. A successful full gate is invalidated by any subsequent source, test, spec, generated-output, or configuration change.\n\n\u003C\u002Fterminal_full_gate>\n\n\u003Creview_gates>\n\nSteps 4, 8, and applicable Step 8a are blocking audit gates. Steps 4 and 8a emit verdicts from their auditor contracts. Step 8 returns an `spx verification run` token, run file, and rendered projection whose `terminalStatus` is authoritative; a `BLOCKED` result must relay a complete diagnostic from the implementation-auditor contract as described in Step 8. Step 9 is a blocking whole-changeset review gate that runs whenever the change reaches beyond the target node. Step 10 is the terminal lifecycle boundary for default-branch work.\n\n- Before starting Step 5: require Step 4's workflow-local result to be `APPROVED`. If it is absent or differs, stop and invoke or repair Step 4.\n- Before starting Step 7: require Step 6's record that validation and every other test and eval pass, and that each new or changed test or eval fails only because the implementation it verifies is absent. If the record is absent, run Step 6; if it differs, repair the evidence through Step 5 and run Step 6 again.\n- Before considering implementation complete: inspect the Step 8 rendered projection. If `terminalStatus` is absent or differs from `approved`, stop — invoke or repair Step 8.\n- Before Step 8 for Go, Rust, or TypeScript, require Step 7a's usable `simplified` or `unchanged` result for the implementation being verified, with every resulting edit inspected, verified, and committed.\n- Before starting Step 9, the terminal full deterministic gate, Step 10, or completion: if the diff touches a test or eval evidence surface named by `\u003Cevidence_auditor_gate>`, require a clean Step 8a verdict over the exact committed diff and invoke or repair Step 8a when that verdict is absent. When the diff touches no named evidence surface, skip Step 8a.\n- Before declaring the flow complete: if the change touches anything beyond the target node, require a raw Step 9 review run token from the native final result and a rendered sealed projection from `\u002Fproject-run-journal`. If no invocation has occurred, invoke Step 9. A failed invocation or unusable final result follows `\u003Claunch_contract>`; a blocked inspection preserves its token; valid `blocking` findings follow the repair workflow, and a `debt` finding follows Step 9.\n- Before using skill `product-tree:merge` when a full deterministic bundle is required: confirm the repository-declared full deterministic gate ran after every applicable agentic gate and against the current clean committed head. If any source, test, spec, generated-output, or configuration file changed afterward, rerun the invalidated agentic gates before running the declared full gate again.\n- Before declaring the flow complete for default-branch work: confirm the change reached the default branch on origin through Step 10's `\u002Fmerge`, or that the user scoped the work to a proposal, analysis, review, or local-only change, or that an explicit merge lifecycle gate blocks with no independent local action remaining. A clean working tree, a local commit, or a branch ahead of base does not satisfy this — invoke Step 10.\n\nFor completed verdicts of `REJECTED`, `UNKNOWN`, or a complete `BLOCKED` diagnostic at Steps 4 and 8a; projection `terminalStatus: rejected` or a complete blocked diagnostic at Step 8; or valid `blocking` findings at Step 9: fix the defect class per `\u003Cstabilized_diff_rule>`, bounded to the cited clause and recorded with its closing check, verify and checkpoint the changed subject, then audit that subject within the gate cap below. Use Step 8's complete blocked diagnostic to identify the failed command, payload, installation, or skill-load boundary. Launch failures, unusable results, and blocked inspection of a valid review token follow `\u003Claunch_contract>` and Step 9; they never enter this relaunch loop.\n\n**Gate cap: each gate launches at most twice, counting real rejections.** A gate is one Verifier definition judging one subject: one ADR path at Step 4, one governed node and evidence type at Step 8a, the committed scope at Step 8, and the whole changeset at Step 9. The cap covers the Step 9 review as well as the audit gates.\n\n- A rejection counts when at least one blocking finding, or a debt finding an audit raises, of a completed verdict — `REJECTED` or `UNKNOWN`, a failing or unknown row, projection `terminalStatus: rejected`, or a valid Step 9 `blocking` finding — sits on a line the changeset changed, or is caused by its edit, read from the diff against the base, and a complete `BLOCKED` diagnostic from an audit gate counts as a rejection with no finding to read. A `debt` finding the Step 9 review raises, a finding already filed in the owning node's `ISSUES.md`, a stale finding, a finding on untouched text, and a rejection whose run a recorded override names as the verdict it sets aside count for nothing; a launch that seals no run counts for nothing.\n- A second counted rejection on the same gate, one no recorded override sets aside -> STOP the flow. Report through `{{! tool('ask_user') !}}` the gate, both verdicts, the outstanding findings, and the same-class sweep already performed. NEVER launch a gate a third time, and NEVER repeat a gate until it approves.\n- The cap covers agentic gates only. A deterministic check that fails runs again after its repair outside the cap.\n\nA failed launch or unusable result stops on its first occurrence under `\u003Claunch_contract>`.\n\n\u003C\u002Freview_gates>\n\n\u003Crationale>\nWhen something breaks or behaves unexpectedly, Claude's instinct is to write ad hoc code — a quick script, a throwaway snippet, a print-and-pray debugging session. That instinct is the symptom, not the fix. The problem surfaced because the tests were insufficient. The ad hoc code patches over one instance; a proper test catches every future instance too.\n\n1. **Do not** write ad hoc code to \"see what's happening.\"\n2. **Do** write a test that reproduces the problem. Hitting this issue proves the test coverage has a gap.\n3. **Then** fix the implementation until the test passes.\n\nThis is not slower. The ad hoc script takes the same effort as a test, but the script gets deleted and the test stays.\n\n\u003C\u002Frationale>\n\n\u003Cfailure_modes>\n\n**Failure 1: Claude closed the flow at Step 9.** Claude reported the flow complete the moment the Step 8 audit passed, tests were green, and the Step 9 review converged — while nothing had been committed, pushed, reviewed at integration time, or merged. Signal: a \"done\" claim for default-branch work with a clean working tree or a local commit ahead of base and no merged PR. Avoid: for default-branch work the flow is incomplete until Step 10 reaches the default branch on origin; local readiness is progress, never delivered value.\n\n**Failure 2: Claude patched the cited line instead of the defect class.** An audit gate or the Step 9 review cited one instance; Claude fixed that line, re-ran the gate, and the same class reopened on the next iteration elsewhere. Signal: repeated rejected verdicts reopening the same rule, source contract, or evidence pattern. Avoid: per `\u003Cstabilized_diff_rule>`, treat each finding as defect-class evidence — sweep the touched node(s) under the cited clause, fix every instance that clause covers and nothing it does not require, record the clause and the closing check, then run the gate once on the stabilized tree.\n\n**Failure 3: Claude planned an evidence audit before implementation.** Claude wrote the tests at Step 5 and tried to audit them before Step 7, while they failed for want of the implementation. The dispatch could never proceed, because an agentic gate requires passing deterministic verification, and the flow stalled between two of its own rules. Signal: an evidence-auditor dispatch planned while new tests fail. Avoid: Step 6 confirms the failures deterministically, and Step 8a audits the evidence once Step 7 makes it pass.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- Every product-declared touched-scope deterministic command exits zero on the final committed subject.\n- Each applicable architecture and test-evidence auditor returns `APPROVED`; each applicable eval-evidence auditor returns JSON `overall: PASS` with no `FAIL` or `UNKNOWN` row; and each implementation-audit run renders `terminalStatus: approved` for the exact committed subject.\n- A cross-node changeset carries a raw Step 9 review run token whose sealed projection renders successfully, with every valid `blocking` finding fixed, every `debt` finding on touched or invalidated text ruled on or labeled `TRACKED`, including every instance its cited clause covers and nothing the clause does not require, and each repair's clause and closing check recorded in the next `VERIFICATION_DISPATCH_READY` record; unbacked findings are dropped.\n- `git rev-parse HEAD` matches the final gate subject and `git status --porcelain` is empty.\n- The requested delivery boundary has observable completion: default-branch work has reached the default branch on origin through `\u002Fmerge`'s selected transport and every declared release action reports success or no-op; proposal, analysis, review, or local-only work reaches its explicitly selected boundary; an explicit lifecycle gate reports its blocking token only after no independent action remains.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":48,"argument-hint":49},"Read, Edit, {{! tool('use_skill') !}},{!% if target == 'claude' %!} Agent,{!% else %!} {{! tool('spawn_agent') !}}, {{! tool('wait_agent') !}},{!% endif %!} {{! tool('ask_user') !}}, Bash(git status:*), Bash(git rev-parse:*), Bash(git diff:*), Bash(spx validation:*), Bash(spx spec status:*), Bash(spx test:*), Bash(just test:*), Bash(just check:*), Bash(just check-full:*), Bash(just verify:*), Bash(just validate:*), Bash(pnpm test:*), Bash(pnpm run test:*), Bash(pnpm run check:*), Bash(pnpm run lint:*), Bash(pnpm run typecheck:*), Bash(pnpm run validate:*), Bash(pnpm run verify:*), Bash(npm test:*), Bash(npm run test:*), Bash(npm run check:*), Bash(npm run lint:*), Bash(npm run typecheck:*), Bash(npm run validate:*), Bash(npm run verify:*), Bash(yarn test:*), Bash(yarn run test:*), Bash(yarn run check:*), Bash(yarn run lint:*), Bash(yarn run typecheck:*), Bash(yarn run validate:*), Bash(yarn run verify:*), Bash(bun test:*), Bash(bun run test:*), Bash(bun run check:*), Bash(bun run lint:*), Bash(bun run typecheck:*), Bash(bun run validate:*), Bash(bun run verify:*), Bash(uv run pytest:*), Bash(pytest:*), Bash(cargo test:*), Bash(cargo check:*), Bash(cargo clippy:*), Bash(cargo fmt --check:*), Bash(go test:*), Bash(go vet:*), Bash(make test:*), Bash(make check:*), Bash(make verify:*), Bash(make validate:*)","[full-spx-node-path | plan-or-proposal]","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Fapply","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-12 11:34:11",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add outcomeeng\u002Fplugins --skill apply",{"tool":64,"command":65},"bunx","bunx skills add outcomeeng\u002Fplugins --skill apply",{"tool":67,"command":68},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill apply","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Fapply\u002FSKILL.md",true,[],[73,79,112,128,144,156],{"skillNo":74,"name":75,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":43},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[75],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":93,"publishedAt":43},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[85,88],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[94,95,96,97,98,99,100,24,101,102,103,104,105,106,107,108,109,110,26,111],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","when",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":43},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[119,120,121,122,123,24,26,124,125,111,126,127],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":137,"publishedAt":43},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[138,139,140,141,142,35,143],"typescript","typescript test standards","test","standards","false","across",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":153,"publishedAt":43},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[150],{"categoryNo":151,"categoryName":152,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000030","开发工程师",[138,41,154,155,141,142,35,143],"typescript code standards","code standards",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":43},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[163,141,164,33,138,165,166,143,35,167,142,168],"architecture standards","typescript architecture standards","adr","architect","auditor","conventions"]