[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FZHYY4MBKHTBTH3N23HE4":3,"skill-same:01M71FZHYY4MBKHTBTH3N23HE4":67},{"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":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M71FZHYY4MBKHTBTH3N23HE4","verify",null,"ALWAYS invoke this skill when selecting or establishing evidence for spec assertions, decision verification rules, or a product-tree scope.","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\u002Fverify\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"spec","Rules","assertions","invoke","use","grep","block","decision","edit","node","tool","read","for","scope","product","repair","evidence","verification","tree","2026-11-10 10:12:30",false,"---\nname: verify\ndescription: >-\n  ALWAYS invoke this skill when selecting or establishing evidence for spec\n  assertions, decision verification rules, or a product-tree scope.\nargument-hint: \u003Cfull-spx-node-or-decision-path|spx\u002F> [repair-block]\nallowed-tools: Read, Glob, Grep, Edit, {{! tool('use_skill') !}}\n---\n\n\u003Cobjective>\n\nValidated spec assertions and decision verification rules routed to test, evaluate, probe, or audit from the verdict their real subjects can produce.\n\n\u003C\u002Fobjective>\n\n\u003Cessential_principles>\n\n- Validate any existing tag shape before reading the subject. An absent tag proceeds to classification; unsupported tagged input returns `blocked` with no selected verification type, specialist, or evidence shape.\n- For every validated assertion, select exactly one current verification type before any specialist chooses assertion type, level, language expression, producer specialization, or verifier.\n- Choose test when behavior has a deterministic verdict, evaluate when an LLM-driven producer emits structured output a deterministic grader can score, probe when only an executed observation of the running node settles the claim, and audit when no deterministic, attested, or structural verdict exists.\n- For spec assertions, recognize only an absent tag, `[test](path)`, `[eval](path)`, `[probe](path)`, `[audit:{rule-slug}]`, and the pathless `[audit]` a repository whose toolchain has not adopted the slug form still carries. For ADR\u002FPDR rules, recognize an absent tag awaiting classification or the decision grammar: one assertion-type tag under `### Testing`, `[eval]` under `### Eval`, and `[audit:{rule-slug}]` with a slug unique within the record, or the pathless `[audit]` a toolchain without slug support still carries, under `### Audit`. Treat every other tag shape as invalid input without naming, aliasing, or translating it.\n- Derive evidence shape from the target artifact and selected verification type regardless of specialist availability: spec test, eval, and probe assertions are path-bearing; spec audit assertions carry a rule slug and no path, or the pathless form while the toolchain admits only that; decision rules carry requirements whose implementing specs own executable evidence links. A capability gap never changes the selected route's evidence shape.\n- Check the runtime skill catalog before invoking a selected path-bearing specialist — `\u002Ftest`, `\u002Feval`, or `\u002Fprobe`. An absent specialist produces `capability-required`, never `routed`, and the result still names the selected specialist and evidence shape; `null` values belong only to the blocked shape.\n- Keep routing acyclic: this skill composes specialists and never composes itself through them.\n- Use skill `product-tree:wait-for-load` for every resource-intensive command: run each one under that skill's guard line in the foreground, and report a result only after every such line has exited.\n- Keep judgment isolated: selecting audit records the audit requirement and leaves the verdict to the applicable auditor context; selecting probe records the protocol link and leaves the attested run to the Author.\n\n\u003C\u002Fessential_principles>\n\n\u003Cworkflow>\n\n\u003Cstep name=\"load-context\">\n\nWhen `$ARGUMENTS` is empty, abort before checking markers: \"A canonical product-tree target is required. Supply `spx\u002F`, one full `spx\u002F...` node path, or one full `spx\u002F...\u002F*.adr.md` or `spx\u002F...\u002F*.pdr.md` decision path.\"\n\nRequire a live `\u003CPRODUCT_TREE_FOUNDATION>` marker. Use skill `product-tree:understand` when it is absent. For a node or product-root target, require a `\u003CPRODUCT_TREE_CONTEXT>` marker matching the target. For a decision target, require the marker for its containing node, or `spx\u002F` for a product-level decision. Use skill `product-tree:contextualize` for that canonical context target when its marker is absent.\n\nAccept only `spx\u002F`, one canonical full `spx\u002F...` node path, or one canonical full decision path ending in `.adr.md` or `.pdr.md`. Read spec assertions from a spec target and `## Verification` rules from a decision target. For a product-root or aggregate target, walk the declared scope deterministically rather than selecting files by keyword, then partition the selected subjects by their owning canonical node or decision path. Each specialist invocation receives one supported node or decision target, never the aggregate target. Text after the target is a repair block: the verbatim result of each rejected verdict and the exact command line and output of each failed deterministic command of an earlier round on this target. Carry it into this workflow as repair input: repair every finding and failure it names within this workflow's scope, and report each one's disposition in the result.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"validate-input\">\n\nInspect only the existing tag shape before reading the subject or its verdict. For spec assertions, an absent tag or one current verification tag proceeds to classification. For decision rules, an absent tag proceeds to classification regardless of its current subsection; a present tag proceeds only when the enclosing subsection and tag match the decision grammar: `### Testing` carries exactly one of `[scenario]`, `[mapping]`, `[conformance]`, `[property]`, or `[compliance]`; `### Eval` carries `[eval]`; `### Audit` carries `[audit:{rule-slug}]` with a slug unique within the record, or the pathless `[audit]` where the toolchain has no slug support.\n\nAny other tag shape triggers an immediate terminal return for that assertion. Return before reading the `subject` field or applying any rule from `classify-subject`, `route-specialist`, or `record-result`. Do not inspect or classify the subject, repeat the tag text, select a specialist, or derive an evidence shape. The assertion has no selected verification type. Report `blocked` with the generic reason `unsupported-tag-shape`, in the blocked row shape `record-result` defines.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"classify-subject\">\n\nFor each assertion, identify the real subject and the verdict it can produce:\n\n| Subject capability                                                                 | Verification type | Current tag           |\n| ---------------------------------------------------------------------------------- | ----------------- | --------------------- |\n| Deterministic behavior can fail a finite command                                   | test              | `[test](path)`        |\n| LLM-driven producer emits parseable structured output scored by fixed expectations | evaluate          | `[eval](path)`        |\n| A claim about the running node that only an executed observation protocol settles  | probe             | `[probe](path)`       |\n| Semantic constraint has no deterministic, attested, or structural verdict          | audit             | `[audit:{rule-slug}]` |\n\nClassify the real subject's execution, not the determinism of a downstream grader. Ask whether rerunning the real subject with the same input produces the same behavior without model variance. When producing the asserted output requires an LLM, select evaluate even though fixed expectations and a deterministic grader later convert that output into pass or fail. Select test only when the behavior under assertion is itself deterministic.\n\nPrefer the strongest reachable evidence in that order after applying this boundary. A prose-content existence check is never deterministic behavior evidence; reading authored text and asserting its wording proves only that the text was authored.\n\nIgnore an existing current tag or decision subsection as classification authority. Input validation has already stopped every unsupported tag shape. Classify the remaining subject from its real verdict. A spec assertion whose current tag already names the selected verification type keeps that tag, is not passed to a specialist again, and reports `routed` with its existing evidence path or rule slug. A spec assertion whose current tag names another verification type has that tag removed before routing, so it reaches the selected specialist as an untagged assertion, and its row names the removed tag. For a decision rule, move it to the subsection matching the selected verification type before its specialist supplies the subsection's tag shape. The decision grammar has no probe subsection, so a decision rule whose claim only an executed observation settles stays unchanged and reports `blocked: probe-on-decision-rule` with its verification type `probe` and a `null` specialist; the spec that implements the rule carries its probe assertion.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"route-specialist\">\n\nRoute each classified assertion exactly once:\n\n- **test** — use skill `product-tree:test`; it owns test assertion typing, execution level, source-contract checks, generic test ceremony, and language delegation. For each spec node, pass that canonical node target plus a JSON array containing the exact text of every untagged assertion selected for test in that node so `\u002Ftest` can distinguish routed work from unrelated untagged assertions. Pass each decision target separately in decision-rule mode with no assertion array so `\u002Ftest` selects the rule's assertion-type tag without creating a test file or evidence link inside the ADR\u002FPDR. An aggregate scope fans out through these per-owner invocations.\n- **evaluate** — for each spec node carrying selected eval assertions, use skill `product-tree:eval` with that canonical node target plus a JSON array containing the exact text of every untagged assertion selected for evaluate in that node. This filtered set prevents `\u002Feval` from consuming unrelated untagged assertions. `\u002Feval` owns product command binding and producer-specialized eval authoring. For a decision rule, preserve the implementing-spec eval requirement under `### Eval` without writing an evidence path in the decision, and use skill `product-tree:eval` with that decision target only when it supports decision-rule mode. When the required capability is unavailable, preserve the target artifact's evaluate evidence shape and report `capability-required` with the subject and required producer kind. Never pass an aggregate target to `\u002Feval` or implement eval behavior inside this skill.\n- **probe** — use skill `product-tree:probe` with the canonical node target and the exact text of every assertion selected for probe in that node when the runtime skill catalog carries it; it owns the protocol at `probes\u002F{probe-slug}\u002Fprobe.md`, and the assertion records that link with routing status `routed`. When `\u002Fprobe` is not installed, preserve the probe evidence shape and report `capability-required` with the subject and the protocol path. Never author a protocol or attest a run inside this skill.\n- **audit** — record the `[audit:{rule-slug}]` tag with a rule slug unique within its spec — or the pathless `[audit]` tag where the toolchain admits only that form — and the applicable isolated-verifier requirement with routing status `routed`. The pending isolated-verifier verdict does not make evidence routing blocked. Never produce the audit verdict in this workflow.\n\nWhen the invocation carried a repair block, pass each specialist, after its target and assertion array, the repair items that concern that target's evidence verbatim, including items on an assertion whose current tag this workflow keeps; such an assertion's specialist is invoked for its repair items even though the assertion is not routed again.\n\nValidate the specialist result before updating the subject. A path-bearing spec assertion requires the specialist's canonical co-located evidence path. A decision rule requires the canonical subsection and tag, while its implementing specs own evidence paths. Spec audit assertions carry no path.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"record-result\">\n\nUpdate each successfully routed spec assertion with exactly one current tag. Update each decision rule with the selected verification subsection and that subsection's canonical tag shape. Leave blocked unsupported input unchanged and return the blocked result.\n\nReport one row per subject in this shape, with `null` written as `null`:\n\n```text\n| Subject | Verification type | Specialist | Evidence shape | Evidence path or requirement | Removed tag | Status |\n```\n\n- `Status` is `routed`, `capability-required`, or `blocked`.\n- `Evidence shape` is `path-bearing` for spec test, eval, and probe assertions, `pathless` for spec audit assertions, and `requirement` for decision rules. A `capability-required` row keeps the selected route intact: the specialist is the absent path-bearing specialist (`\u002Ftest`, `\u002Feval`, or `\u002Fprobe`) and the evidence shape is `path-bearing`.\n- `Removed tag` names the tag `classify-subject` removed from a reclassified assertion, and is `null` otherwise.\n- A `blocked` row from `validate-input` carries `null` as its verification type, specialist, evidence shape, and evidence path, and its reason `unsupported-tag-shape` in the status cell as `blocked: unsupported-tag-shape`.\n\nNever report an assertion verified merely because classification completed; path-bearing evidence must exist and pass its deterministic command, and audit requires its isolated verifier.\n\nWhen the invocation carried a repair block, add one line per repair item after the table: the item as the block names it, and its disposition — `forwarded to \u002F\u003Cspecialist>` with that specialist's reported outcome, `repaired` for a classification or tag defect this workflow fixed, or `not-owned` with the reason when no step of this workflow or its specialists owns the fix.\n\nExample:\n\n```text\n| Subject | Verification type | Specialist | Evidence shape | Evidence path or requirement | Removed tag | Status |\n| Node A deterministic rule | test | \u002Ftest | path-bearing | tests\u002F\u003Cthe language's compliance test file> | null | routed |\n| Node B producer rule | evaluate | \u002Feval | path-bearing | eval capability required for the structured producer | [audit:producer-voice] | capability-required |\n| Node C unsupported input | null | null | null | null | null | blocked: unsupported-tag-shape |\n```\n\nFor the terminal unsupported-input guard, record no verification type, specialist, or evidence shape. Classification output must never accompany that blocked result.\n\n\u003C\u002Fstep>\n\n\u003C\u002Fworkflow>\n\n\u003Csuccess_criteria>\n\n- Every validated spec assertion or decision rule has exactly one selected current verification type derived from its real verdict; unsupported input has none and returns the terminal blocked shape.\n- Test work routes through `\u002Ftest`, eval work routes through `\u002Feval`, probe work records the protocol link or the missing capability, and audit work records an isolated-verifier requirement.\n- Every path-bearing spec evidence link is canonical and co-located with its governing node; decision rules carry no executable evidence links.\n- Unsupported tags block the subject and receive no compatibility behavior or vocabulary in the workflow output.\n- Specialist dependency direction is acyclic and no agentic verdict is produced in the authoring context.\n\n\u003C\u002Fsuccess_criteria>\n\n\u003Cfailure_modes>\n\n**Claude passed an aggregate target to a specialist**\n\n- **What happened:** Claude accepted `spx\u002F` as a target, then forwarded that aggregate target unchanged to `\u002Ftest`, whose contract accepts one node or decision.\n- **Why it failed:** The router advertised a broader scope than its specialist interface could consume, so aggregate test work had no valid delegation path.\n- **How to avoid:** Partition aggregate subjects by owning canonical node or decision and invoke each path-bearing specialist once per owner.\n\n**Claude classified an unsupported tag before blocking it**\n\n- **What happened:** Claude read the subject and selected a verification type after encountering a tag outside the current grammar.\n- **Why it failed:** Classification leaked compatibility behavior and produced routing fields for input the workflow promises to leave unclassified.\n- **How to avoid:** Validate tag shape first and return the terminal blocked result with null verification type, specialist, and evidence shape before reading the subject.\n\n\u003C\u002Ffailure_modes>\n","\u003Cobjective>\n\nValidated spec assertions and decision verification rules routed to test, evaluate, probe, or audit from the verdict their real subjects can produce.\n\n\u003C\u002Fobjective>\n\n\u003Cessential_principles>\n\n- Validate any existing tag shape before reading the subject. An absent tag proceeds to classification; unsupported tagged input returns `blocked` with no selected verification type, specialist, or evidence shape.\n- For every validated assertion, select exactly one current verification type before any specialist chooses assertion type, level, language expression, producer specialization, or verifier.\n- Choose test when behavior has a deterministic verdict, evaluate when an LLM-driven producer emits structured output a deterministic grader can score, probe when only an executed observation of the running node settles the claim, and audit when no deterministic, attested, or structural verdict exists.\n- For spec assertions, recognize only an absent tag, `[test](path)`, `[eval](path)`, `[probe](path)`, `[audit:{rule-slug}]`, and the pathless `[audit]` a repository whose toolchain has not adopted the slug form still carries. For ADR\u002FPDR rules, recognize an absent tag awaiting classification or the decision grammar: one assertion-type tag under `### Testing`, `[eval]` under `### Eval`, and `[audit:{rule-slug}]` with a slug unique within the record, or the pathless `[audit]` a toolchain without slug support still carries, under `### Audit`. Treat every other tag shape as invalid input without naming, aliasing, or translating it.\n- Derive evidence shape from the target artifact and selected verification type regardless of specialist availability: spec test, eval, and probe assertions are path-bearing; spec audit assertions carry a rule slug and no path, or the pathless form while the toolchain admits only that; decision rules carry requirements whose implementing specs own executable evidence links. A capability gap never changes the selected route's evidence shape.\n- Check the runtime skill catalog before invoking a selected path-bearing specialist — `\u002Ftest`, `\u002Feval`, or `\u002Fprobe`. An absent specialist produces `capability-required`, never `routed`, and the result still names the selected specialist and evidence shape; `null` values belong only to the blocked shape.\n- Keep routing acyclic: this skill composes specialists and never composes itself through them.\n- Use skill `product-tree:wait-for-load` for every resource-intensive command: run each one under that skill's guard line in the foreground, and report a result only after every such line has exited.\n- Keep judgment isolated: selecting audit records the audit requirement and leaves the verdict to the applicable auditor context; selecting probe records the protocol link and leaves the attested run to the Author.\n\n\u003C\u002Fessential_principles>\n\n\u003Cworkflow>\n\n\u003Cstep name=\"load-context\">\n\nWhen `$ARGUMENTS` is empty, abort before checking markers: \"A canonical product-tree target is required. Supply `spx\u002F`, one full `spx\u002F...` node path, or one full `spx\u002F...\u002F*.adr.md` or `spx\u002F...\u002F*.pdr.md` decision path.\"\n\nRequire a live `\u003CPRODUCT_TREE_FOUNDATION>` marker. Use skill `product-tree:understand` when it is absent. For a node or product-root target, require a `\u003CPRODUCT_TREE_CONTEXT>` marker matching the target. For a decision target, require the marker for its containing node, or `spx\u002F` for a product-level decision. Use skill `product-tree:contextualize` for that canonical context target when its marker is absent.\n\nAccept only `spx\u002F`, one canonical full `spx\u002F...` node path, or one canonical full decision path ending in `.adr.md` or `.pdr.md`. Read spec assertions from a spec target and `## Verification` rules from a decision target. For a product-root or aggregate target, walk the declared scope deterministically rather than selecting files by keyword, then partition the selected subjects by their owning canonical node or decision path. Each specialist invocation receives one supported node or decision target, never the aggregate target. Text after the target is a repair block: the verbatim result of each rejected verdict and the exact command line and output of each failed deterministic command of an earlier round on this target. Carry it into this workflow as repair input: repair every finding and failure it names within this workflow's scope, and report each one's disposition in the result.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"validate-input\">\n\nInspect only the existing tag shape before reading the subject or its verdict. For spec assertions, an absent tag or one current verification tag proceeds to classification. For decision rules, an absent tag proceeds to classification regardless of its current subsection; a present tag proceeds only when the enclosing subsection and tag match the decision grammar: `### Testing` carries exactly one of `[scenario]`, `[mapping]`, `[conformance]`, `[property]`, or `[compliance]`; `### Eval` carries `[eval]`; `### Audit` carries `[audit:{rule-slug}]` with a slug unique within the record, or the pathless `[audit]` where the toolchain has no slug support.\n\nAny other tag shape triggers an immediate terminal return for that assertion. Return before reading the `subject` field or applying any rule from `classify-subject`, `route-specialist`, or `record-result`. Do not inspect or classify the subject, repeat the tag text, select a specialist, or derive an evidence shape. The assertion has no selected verification type. Report `blocked` with the generic reason `unsupported-tag-shape`, in the blocked row shape `record-result` defines.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"classify-subject\">\n\nFor each assertion, identify the real subject and the verdict it can produce:\n\n| Subject capability                                                                 | Verification type | Current tag           |\n| ---------------------------------------------------------------------------------- | ----------------- | --------------------- |\n| Deterministic behavior can fail a finite command                                   | test              | `[test](path)`        |\n| LLM-driven producer emits parseable structured output scored by fixed expectations | evaluate          | `[eval](path)`        |\n| A claim about the running node that only an executed observation protocol settles  | probe             | `[probe](path)`       |\n| Semantic constraint has no deterministic, attested, or structural verdict          | audit             | `[audit:{rule-slug}]` |\n\nClassify the real subject's execution, not the determinism of a downstream grader. Ask whether rerunning the real subject with the same input produces the same behavior without model variance. When producing the asserted output requires an LLM, select evaluate even though fixed expectations and a deterministic grader later convert that output into pass or fail. Select test only when the behavior under assertion is itself deterministic.\n\nPrefer the strongest reachable evidence in that order after applying this boundary. A prose-content existence check is never deterministic behavior evidence; reading authored text and asserting its wording proves only that the text was authored.\n\nIgnore an existing current tag or decision subsection as classification authority. Input validation has already stopped every unsupported tag shape. Classify the remaining subject from its real verdict. A spec assertion whose current tag already names the selected verification type keeps that tag, is not passed to a specialist again, and reports `routed` with its existing evidence path or rule slug. A spec assertion whose current tag names another verification type has that tag removed before routing, so it reaches the selected specialist as an untagged assertion, and its row names the removed tag. For a decision rule, move it to the subsection matching the selected verification type before its specialist supplies the subsection's tag shape. The decision grammar has no probe subsection, so a decision rule whose claim only an executed observation settles stays unchanged and reports `blocked: probe-on-decision-rule` with its verification type `probe` and a `null` specialist; the spec that implements the rule carries its probe assertion.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"route-specialist\">\n\nRoute each classified assertion exactly once:\n\n- **test** — use skill `product-tree:test`; it owns test assertion typing, execution level, source-contract checks, generic test ceremony, and language delegation. For each spec node, pass that canonical node target plus a JSON array containing the exact text of every untagged assertion selected for test in that node so `\u002Ftest` can distinguish routed work from unrelated untagged assertions. Pass each decision target separately in decision-rule mode with no assertion array so `\u002Ftest` selects the rule's assertion-type tag without creating a test file or evidence link inside the ADR\u002FPDR. An aggregate scope fans out through these per-owner invocations.\n- **evaluate** — for each spec node carrying selected eval assertions, use skill `product-tree:eval` with that canonical node target plus a JSON array containing the exact text of every untagged assertion selected for evaluate in that node. This filtered set prevents `\u002Feval` from consuming unrelated untagged assertions. `\u002Feval` owns product command binding and producer-specialized eval authoring. For a decision rule, preserve the implementing-spec eval requirement under `### Eval` without writing an evidence path in the decision, and use skill `product-tree:eval` with that decision target only when it supports decision-rule mode. When the required capability is unavailable, preserve the target artifact's evaluate evidence shape and report `capability-required` with the subject and required producer kind. Never pass an aggregate target to `\u002Feval` or implement eval behavior inside this skill.\n- **probe** — use skill `product-tree:probe` with the canonical node target and the exact text of every assertion selected for probe in that node when the runtime skill catalog carries it; it owns the protocol at `probes\u002F{probe-slug}\u002Fprobe.md`, and the assertion records that link with routing status `routed`. When `\u002Fprobe` is not installed, preserve the probe evidence shape and report `capability-required` with the subject and the protocol path. Never author a protocol or attest a run inside this skill.\n- **audit** — record the `[audit:{rule-slug}]` tag with a rule slug unique within its spec — or the pathless `[audit]` tag where the toolchain admits only that form — and the applicable isolated-verifier requirement with routing status `routed`. The pending isolated-verifier verdict does not make evidence routing blocked. Never produce the audit verdict in this workflow.\n\nWhen the invocation carried a repair block, pass each specialist, after its target and assertion array, the repair items that concern that target's evidence verbatim, including items on an assertion whose current tag this workflow keeps; such an assertion's specialist is invoked for its repair items even though the assertion is not routed again.\n\nValidate the specialist result before updating the subject. A path-bearing spec assertion requires the specialist's canonical co-located evidence path. A decision rule requires the canonical subsection and tag, while its implementing specs own evidence paths. Spec audit assertions carry no path.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"record-result\">\n\nUpdate each successfully routed spec assertion with exactly one current tag. Update each decision rule with the selected verification subsection and that subsection's canonical tag shape. Leave blocked unsupported input unchanged and return the blocked result.\n\nReport one row per subject in this shape, with `null` written as `null`:\n\n```text\n| Subject | Verification type | Specialist | Evidence shape | Evidence path or requirement | Removed tag | Status |\n```\n\n- `Status` is `routed`, `capability-required`, or `blocked`.\n- `Evidence shape` is `path-bearing` for spec test, eval, and probe assertions, `pathless` for spec audit assertions, and `requirement` for decision rules. A `capability-required` row keeps the selected route intact: the specialist is the absent path-bearing specialist (`\u002Ftest`, `\u002Feval`, or `\u002Fprobe`) and the evidence shape is `path-bearing`.\n- `Removed tag` names the tag `classify-subject` removed from a reclassified assertion, and is `null` otherwise.\n- A `blocked` row from `validate-input` carries `null` as its verification type, specialist, evidence shape, and evidence path, and its reason `unsupported-tag-shape` in the status cell as `blocked: unsupported-tag-shape`.\n\nNever report an assertion verified merely because classification completed; path-bearing evidence must exist and pass its deterministic command, and audit requires its isolated verifier.\n\nWhen the invocation carried a repair block, add one line per repair item after the table: the item as the block names it, and its disposition — `forwarded to \u002F\u003Cspecialist>` with that specialist's reported outcome, `repaired` for a classification or tag defect this workflow fixed, or `not-owned` with the reason when no step of this workflow or its specialists owns the fix.\n\nExample:\n\n```text\n| Subject | Verification type | Specialist | Evidence shape | Evidence path or requirement | Removed tag | Status |\n| Node A deterministic rule | test | \u002Ftest | path-bearing | tests\u002F\u003Cthe language's compliance test file> | null | routed |\n| Node B producer rule | evaluate | \u002Feval | path-bearing | eval capability required for the structured producer | [audit:producer-voice] | capability-required |\n| Node C unsupported input | null | null | null | null | null | blocked: unsupported-tag-shape |\n```\n\nFor the terminal unsupported-input guard, record no verification type, specialist, or evidence shape. Classification output must never accompany that blocked result.\n\n\u003C\u002Fstep>\n\n\u003C\u002Fworkflow>\n\n\u003Csuccess_criteria>\n\n- Every validated spec assertion or decision rule has exactly one selected current verification type derived from its real verdict; unsupported input has none and returns the terminal blocked shape.\n- Test work routes through `\u002Ftest`, eval work routes through `\u002Feval`, probe work records the protocol link or the missing capability, and audit work records an isolated-verifier requirement.\n- Every path-bearing spec evidence link is canonical and co-located with its governing node; decision rules carry no executable evidence links.\n- Unsupported tags block the subject and receive no compatibility behavior or vocabulary in the workflow output.\n- Specialist dependency direction is acyclic and no agentic verdict is produced in the authoring context.\n\n\u003C\u002Fsuccess_criteria>\n\n\u003Cfailure_modes>\n\n**Claude passed an aggregate target to a specialist**\n\n- **What happened:** Claude accepted `spx\u002F` as a target, then forwarded that aggregate target unchanged to `\u002Ftest`, whose contract accepts one node or decision.\n- **Why it failed:** The router advertised a broader scope than its specialist interface could consume, so aggregate test work had no valid delegation path.\n- **How to avoid:** Partition aggregate subjects by owning canonical node or decision and invoke each path-bearing specialist once per owner.\n\n**Claude classified an unsupported tag before blocking it**\n\n- **What happened:** Claude read the subject and selected a verification type after encountering a tag outside the current grammar.\n- **Why it failed:** Classification leaked compatibility behavior and produced routing fields for input the workflow promises to leave unclassified.\n- **How to avoid:** Validate tag shape first and return the terminal blocked result with null verification type, specialist, and evidence shape before reading the subject.\n\n\u003C\u002Ffailure_modes>\n",{"name":5,"description":7,"allowed-tools":43,"argument-hint":44},"Read, Glob, Grep, Edit, {{! tool('use_skill') !}}","\u003Cfull-spx-node-or-decision-path|spx\u002F> [repair-block]","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Fverify","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-10 01:06:33",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add outcomeeng\u002Fplugins --skill verify",{"tool":59,"command":60},"bunx","bunx skills add outcomeeng\u002Fplugins --skill verify",{"tool":62,"command":63},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill verify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Fverify\u002FSKILL.md",true,[],[68,74,109,125,141,154],{"skillNo":69,"name":70,"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":71,"categories":72,"keywords":73,"publishedAt":38},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[70],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":90,"publishedAt":38},"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",[80,85],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,27,106,107,22,108],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","xml","master","when",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":38},"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",[],[116,117,118,119,120,98,22,121,122,108,123,124],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":134,"publishedAt":38},"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",[131],{"categoryNo":132,"categoryName":133,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000008","测试与质量",[135,136,137,138,139,30,140],"typescript","typescript test standards","test","standards","false","across",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":150,"publishedAt":38},"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",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000030","开发工程师",[135,151,152,153,138,139,30,140],"code","typescript code standards","code standards",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":38},"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",[],[161,138,162,163,135,164,165,140,30,166,139,167],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]