[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FWMJR6M84BZ3469YVRNA2":3,"skill-same:01M71FWMJR6M84BZ3469YVRNA2":92},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":14,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M71FWMJR6M84BZ3469YVRNA2","audit-implementation",null,"Implementation audit methodology — judges a changeset's implementation against its governing decisions, specs, and the standards of each concern skill the artifact registry selects for its changed paths, covering code, test, and architecture concerns, finding falsifiability, and completeness of the inspection.","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\u002Faudit-implementation\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"audit implementation","implementation","audit","audit methodology","inspection","parse","Falsifiability","for","rev","selector","checkout","scope","show","standards","use","decisions","branch","changeset","python3","tool","2026-11-10 10:12:30",false,"---\nname: audit-implementation\ndescription: >-\n  Implementation audit methodology — judges a changeset's implementation\n  against its governing decisions, specs, and the standards of each concern\n  skill the artifact registry selects for its changed paths, covering code,\n  test, and architecture concerns, finding falsifiability, and completeness of\n  the inspection.\nargument-hint: \"\u003CHEAD | branch | base...head | worktree:selector> [absolute checkout directory]\"\nallowed-tools: Read, Bash(python3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fresolve_scope.py\":*), Bash(git rev-parse:*), Bash(git -C * rev-parse:*), Bash(git -C * status:*), Bash(git -C * show:*), Bash(spx -C * verification run:*), Write, Glob, Grep, {{! tool('use_skill') !}}\n---\n\n\u003Cobjective>\n\nAn authoritative SPX projection, raw run token, and run file for the requested implementation scope, judged against its governing decisions and specs and the standards of every concern skill the artifact registry selects for its changed paths, carrying `terminalStatus` (`approved` or `rejected`), the findings on touched text — each naming the artifact, the violated rule, and observed-versus-expected evidence — and every other finding returned as `filed`. A run that cannot reach that projection yields a `BLOCKED` diagnostic naming the request failure, command failure, or absent prerequisite that stopped it.\n\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\n- NEVER edit source, tests, specs, commits, branches, or pull requests — the audit is read-only over the audited project tree; the only state it changes is its payload files in the session scratch directory and the SPX verification-run journal its own recording commands write, and the file-write tool writes payload files only.\n- ALWAYS persist audit state through `spx verification run`; NEVER use legacy journal commands, plugin-side verdict scripts, markdown comments, `.spx\u002Faudits\u002F`, or tracked files as audit state.\n- NEVER run deterministic verification — the audit composes agentic concern audits only.\n- NEVER derive a kind, a partition, or a skill name from a file extension, a filename, or a language name — the artifact registry the scope resolver reads carries every kind and the skills it selects, the run reads each skill name from that selection, and each concern skill owns its policy.\n- ALWAYS treat the `spx verification run` command exit code as payload validity; NEVER hand-validate emitted payload JSON after SPX accepts it.\n- NEVER end a run because work remains, time has passed, context is tight, or reading is unfinished — a stop names the failed command with its exit code and stderr, or the absent prerequisite.\n- NEVER assign `incomplete` or `skipped` to a required coverage unit; neither describes an admissible terminal state for required coverage.\n- NEVER derive a subject body from a single commit's patch, or leave a truncated read unrecovered — a partial read is re-issued, never converted into coverage evidence.\n- NEVER hand-transcribe the resolved changed-path set into a payload — the resolver takes its audit input from a file in the session scratch directory and writes the run-start input to a file that the run-start command takes by path, because a retyped inventory drops and substitutes paths without any later step noticing.\n- NEVER select a skill from the installed skill inventory, and NEVER invoke a skill to discover whether a kind is installed — the registry selection in the run's sealed start input is the only selection source; the inventory this context carries decides only whether a selected skill runs or is recorded as `missing-skill`, and a failed invocation is not selection evidence.\n- ALWAYS record coverage as `\u003Ccoverage_model>` states; a run that narrows a set or records a unit only where it found something states its findings as its coverage.\n- NEVER let a raised finding or a rejected terminal status shorten the inspection: rejection is a verdict about what was inspected, never permission to leave a concern or a resolved path unrecorded.\n- ALWAYS start the verification run after resolving the target's Git metadata and validating the run-driver identity, before reading changed project file bodies or loading concern standards — every substantive project inspection and concern result belongs to the open run.\n- NEVER write the run journal or its context anywhere but the locations `spx verification run` resolves. When the native permission policy refuses a run-recording write — a payload file, a resolver output file, a run-recording command, or the journal — stop at that write, retry it no more, write to no other location, and return the `\u003Cverdict_format>` blocked diagnostic with `diagnostic: configuration error` naming the refused path; the host grants the paths, and this skill never widens its own access.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\n\n\u003Cexecution_sequence>\n\nRun these stages in order. Each names what holds before the next begins, and\n`finish` is reachable only from stage 7.\n\n1. **Anchor.** Resolve the repository, the scope selector, and the run-driver\n   identity per `\u003Crequest_contract>`. Retain the resolved `base` and `head`\n   identities unchanged for the rest of the run.\n2. **Open the run.** Start the run per `\u003Cverification_run_contract>` before any\n   project inspection or standards load, so every later stage belongs to it.\n3. **Load.** Read each discovered governing node's context, the governing\n   standards of each selected concern skill, and the audited repository's\n   declared `spx\u002Flocal\u002F` overlays.\n4. **Enumerate.** Build the complete expected coverage inventory per\n   `\u003Ccoverage_model>` before invoking any concern, reading the path set from the\n   `resolvedScope` the `start` result returned and each path's artifact\n   selection from the run's sealed start input, never from a retyped list or a\n   re-run of the resolver. Every resolved path enters the inventory — claimed by\n   a concern or left to another auditor — and a unit enters planned, without a\n   status.\n5. **Inspect.** Read each subject body completely from the resolved\n   `base..head` scope, re-issuing a truncated or partial read in bounded\n   ranges until the body is complete, per the subject-body constraint.\n6. **Record.** Hold each unit planned until its concern returns a final result,\n   classify each returned finding per the touched-text reference, then persist per `\u003Ccoverage_model>`. NEVER accept a finding raised before stage 3 loaded that concern's standards and overlays — withdraw it.\n7. **Reconcile, then finish.** Run the bundled reconciler; `finish` is\n   reachable only from its zero exit:\n\n   ```bash\n   python3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fresolve_scope.py\" '{committed-selector}' --repo '{repository-root}' --reconcile-run '{run-token}' --scope-identity '\u003Cbase>..\u003Chead>'\n   ```\n\n   `{committed-selector}` is the selector with any `worktree:` prefix removed,\n   exactly as stage 1 resolved it; `--scope-identity` is the stage 1 identity,\n   unchanged. The reconciler reads the run's sealed start inventory — with an\n   advisory run's `live_paths` beside it — and its recorded units, and emits\n   `unaccounted`, `unexpected`, `drifted`, and `nonfinal`. Exit 0 reaches\n   `finish`. Exit 1 with a non-empty `drifted`, `unexpected`, or `nonfinal`\n   returns the `\u003Cverdict_format>` blocked diagnostic naming that field,\n   whatever else the verdict carries: no inspection repairs drift, an accepted\n   subject cannot be removed, and an accepted required status cannot be\n   revised, so a new run addresses the head. Exit 1 with only `unaccounted`\n   returns the run to stage 5 or 6 for its remaining rows. Exit 2 is a command failure reported\n   under `\u003Cverdict_format>`. The referent is the sealed inventory, never the\n   plan the run driver holds; Failure 15 in\n   `\u003Cfailure_modes>` carries the reasoning.\n\nA run that cannot bring a required unit to a stage 6 status returns the\n`\u003Cverdict_format>` blocked diagnostic naming the concrete failed operation or\nabsent prerequisite. Remaining work, elapsed time, context pressure, and\nunfinished reading are never such a cause.\n\n\u003C\u002Fexecution_sequence>\n\n\u003Crequest_contract>\n\nBind the target scope selector before discovery. `$ARGUMENTS` supplies the\nrequest tokens when that argument is non-empty; when it is empty, the tokens are\nthe ones the request text carries, and the empty substitution binds nothing. Only a request\nthat carries no selector is the missing-input case. The target is one scope\nselector: `HEAD`, a branch, or an explicit three-dot range. `worktree:` before\na selector explicitly requests an advisory audit of that committed scope plus\nthe complete modified and untracked file set. Preserve the selector verbatim.\nNever infer advisory intent from a dirty checkout.\n\nRun-driver identity uses the six published producer fields (the\n`expectedProducer` shape in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`) in the invocation\ncontext, separate from `$ARGUMENTS`. Accept that identity generically; never\ninfer it from a role name, installed plugin, or descriptive text.\n\nA target in another worktree reaches the audit as the absolute path of the\ncheckout directory that holds the audited scope. The request carries the\nselector first and that directory second, separated by one space; a directory\npath that contains a space is wrapped in double quotes, and a request with one\ntoken carries the selector alone. Bind each token separately and preserve each\nverbatim. The session's working directory never decides the repository.\n\nBefore reading project file bodies:\n\n1. Resolve the repository root from the repository that holds the target: with\n   `git -C '{target-directory}' rev-parse --show-toplevel` when the request\n   names a target directory, and with `git rev-parse --show-toplevel` when it\n   names none. Run every later git command against that root with `git -C\n   '{repository-root}'` and every `spx verification run` command with `spx -C\n   '{repository-root}' verification run`, because an unrooted command resolves\n   its scope and store from the session's working directory, which may hold\n   another checkout. Address every file the audit reads or searches by its\n   absolute path beneath that root. Return the `\u003Cverdict_format>` blocked diagnostic with\n   `runToken: not-started` naming the target directory when it is no\n   repository checkout, and again when the resolved `head` or any\n   `changed_paths` entry does not resolve in that root; the audit judges no\n   scope outside the repository that holds its target.\n2. For an advisory target, remove only its `worktree:` prefix. Resolve the\n   remaining selector through the bundled consumer of `\u002Fscope-changeset`:\n\n   ```bash\n   python3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fresolve_scope.py\" '{selector}' --repo '{repository-root}'\n   ```\n\n   Read its `base` and `head`; the full endpoint IDs form the SPX scope identity\n   `{base}..{head}`. Never reinterpret that identity as a two-dot changed-file\n   query or substitute a local base branch. Its three-dot `changed_paths` reach\n   the run through the file in `\u003Cverification_run_contract>`, never by being\n   read out and retyped: a changeset carries more paths than a response\n   reproduces reliably, and a dropped path there is invisible to every later\n   stage. Quote each substituted argument independently, applying the\n   apostrophe splice below.\n3. Read `git -C '{repository-root}' status --porcelain=v1 -z --untracked-files=all`. An advisory audit includes every reported modified or untracked path,\n   consuming NUL-delimited paths and both paths of a rename or copy. A committed\n   audit includes none of those live changes. Read committed subject bodies with\n   `git -C '{repository-root}' show '{head}:{path}'` whenever the working file differs or the selected\n   head is not the checkout's `HEAD`; never silently audit a different version.\n   For a deleted path, inspect its base-side body and the committed deletion.\n4. Validate the generic run-driver identity and retain already-established\n   deterministic verification facts for this exact committed subject from the\n   available context. When evidence is unavailable, record it as unestablished;\n   never infer passing checks from a clean checkout or run them inside the audit.\n\nA missing selector or identity, failed repository discovery, or failed scope\nresolution returns `BLOCKED` with `runToken: not-started` and the exact missing\ninput or command failure; the resolver's stale-base refusal — a dedicated exit\ncode and a `stale-base` diagnostic on stderr for a head behind the fetched base\n— returns the same way before any subject is read. Make no replacement scope\nselection, synchronization, or retry.\n\nStart the run after this metadata preparation. Then discover governing nodes\nfrom the resolved paths through the product-tree evidence links and declared audit\nownership, load their context read-only, and pass that discovered context to the\nconcern skills. Never synchronize, rebase, or otherwise mutate the audited\ncheckout. Preserve missing governance as coverage evidence under the existing\ncoverage model. A committed audit is reusable only when the applicable\ndeterministic verification is established as passing for that subject; an\nadvisory audit never supplies reusable gate evidence.\n\n\u003C\u002Frequest_contract>\n\n\u003Cverification_run_contract>\n\nAfter validating the request, start one audit run as the first audit action. Do\nthis before loading concern standards, inspecting the changeset, or\ninvoking concern skills, so the returned run token identifies the in-flight\naudit from its beginning:\n\nHave the resolver write the run-start input to a file, so the resolved `base`,\n`head`, and complete `changed_paths` enter the run exactly as git produced them.\nName two paths in the session scratch directory, each unique to this run: the\naudit-input file, such as `\u003Crun-id>-audit-input.json`, written with the\nfile-write tool, and the resolver's output file, such as\n`\u003Crun-id>-start-input.json`. Pass the audit-input file as the resolver's\n`--audit-input` path, the session scratch directory as its `--scratch-dir` path,\nand the output file as its `--output` path:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fresolve_scope.py\" '{selector}' --repo '{repository-root}' --audit-input '\u003Caudit-input-file>' --scratch-dir '\u003Cscratch-directory>' --output '\u003Cstart-input-file>'\n```\n\nThen start the run with its own command, passing that file by path:\n\n```bash\nspx -C '{repository-root}' verification run start --verification-type audit --scope-type changeset --scope \u003Cbase>..\u003Chead> --input '\u003Cstart-input-file>'\n```\n\nThe audit-input file holds one JSON object carrying only the short values the\ninvocation supplies: the original selector, the resolved repository root, the\ndiscovered live file list under `live_paths` for an advisory audit, available\ndeterministic verification facts, generic run-driver identity, and advisory\nstatus. Write it with the file-write tool into the session scratch directory and pass\nits path exactly as the file-write result reports it; pass no inline JSON\nargument. The resolver refuses a file that resolves outside the directory named\nby `--scratch-dir` and exits nonzero, which returns the `\u003Cverdict_format>`\nblocked diagnostic with `runToken: not-started`. The\nresolver merges the object beneath the resolved scope,\nso a key that collides with `base`, `head`, or `changed_paths` is discarded\nrather than honored — the resolved scope is authoritative and unforgeable at\nthis boundary.\n\nGoverning nodes are discovered after start and accompany the concern inputs and\ncoverage evidence. The command returns a JSON locator; extract its `runToken`\nfield exactly and use that token for every later command, retain the run target it reports as the run file (only the start report names it), and read its\n`resolvedScope` array as the run's sealed inventory — the path set stage 4\nenumerates and stage 7 reconciles against. The resolver also recorded, under\n`artifact_selection` in that input, the registered artifacts and audit skills\neach path selects; `\u003Ccoverage_model>` reads it back with\n`spx -C '{repository-root}' verification run input`. Never pass the whole locator as `--run`.\n\nExecute every state-changing `spx -C '{repository-root}' verification run` command serially: a tool\nresponse or batch contains at most one `start`, `scope add`, `finding add`, or\n`finish` for a run, and the next mutation waits for that command to exit and\npreserves its result. NEVER place two journal mutations in a parallel tool\ngroup, multi-call batch, shell background group, or concurrently executing\nconcern — parallel writes race sequence assignment and produce a sealed\nprojection whose event prefix is neither strictly increasing nor contiguous.\nParallel concern analysis emits no SPX commands; queue each concern's completed\nresults and persist them one at a time. Render only after `finish` exits\nsuccessfully.\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md` before writing the first scope or finding payload: it carries the scope, accounting-record, and finding payload JSON, the idempotency key forms, and the payload-file rules. Those rules bind every command that follows:\n\n- Write each scope and finding payload with the file-write tool to its own file in the session scratch directory, and pass `--payload` the path exactly as the file-write result reports it, never retyped.\n- Add each scope unit and each finding with its own literal command, one at a time, and stop at the first nonzero exit with the `\u003Cverdict_format>` blocked diagnostic; the one exception is a single rerun of a scope-add or finding-add whose diagnostic names its payload file as absent. A permission refusal is no absent payload file and takes no rerun.\n- Pass every idempotency key as one single-quoted argument.\n- Send no payload through a heredoc, a pipe, or an inline argument, and remove no payload file.\n\n```bash\nspx -C '{repository-root}' verification run scope add --verification-type audit --scope-type changeset --scope '\u003Cbase>..\u003Chead>' --run '\u003Ctoken>' --idempotency-key '\u003Cstable-scope-key>' --payload '\u003Cscope-file>'\nspx -C '{repository-root}' verification run finding add --verification-type audit --scope-type changeset --scope '\u003Cbase>..\u003Chead>' --run '\u003Ctoken>' --idempotency-key '\u003Cstable-scope-key>:\u003Crule>' --payload '\u003Cfinding-file>'\n```\n\n```bash\nspx -C '{repository-root}' verification run finish \\\n  --verification-type audit \\\n  --scope-type changeset \\\n  --scope \u003Cbase>..\u003Chead> \\\n  --run \u003Ctoken> \\\n  --terminal-status \u003Cevidence-derived-status>\n\nspx -C '{repository-root}' verification run render \\\n  --verification-type audit \\\n  --scope-type changeset \\\n  --scope \u003Cbase>..\u003Chead> \\\n  --run \u003Ctoken>\n```\n\nThe final response relays the rendered SPX projection, the run token, and the run file. Do not summarize findings from memory when the render is available.\n\n\u003C\u002Fverification_run_contract>\n\n\u003Ccoverage_model>\n\nBuild the expected coverage inventory from the selection the scope resolver recorded in the run's sealed start input, before invoking any concern skill. Read the `artifact_selection` array back from that input — `spx -C '{repository-root}' verification run input --verification-type audit --scope-type changeset --scope \u003Cbase>..\u003Chead> --run '{run-token}'`, field `content` — never from a re-run of the resolver and never from a reading of the paths. For each resolved path, and each live path of an advisory audit, it holds the registered artifacts whose detection matches the path, most specific within a kind, kinds in declaration order, a kind with a match adding its detection-less artifacts; each artifact carries its `kind`, `role`, `plugin`, `audit` skill, and `contract`. Dispatch exactly the skills that selection names, validating each against the installed skill inventory this context carries before invoking any concern. The inventory never selects: it decides only whether a selected skill is invoked or recorded as a required `missing-skill` unit, and invoking a skill is dispatch to a selected artifact, never a probe for whether a kind is installed. Never load a write-capable author skill inside the audit — the skill-composition grant cannot be narrowed to names selected at run time, so this rule is the containment — and never create a partition from a file extension, filename, or artifact class the registry did not select.\n\nDispatch only a skill whose `contract` is `concern`. A path whose registered artifact's audit skill carries the `artifact-type` contract, a path matching no registered artifact, and a matched path whose selected concern skill returns `NOT_APPLICABLE` stay with their artifact-type auditor and the whole-changeset review; never manufacture a kind, a missing skill, or an unsupported unit for such a path.\n\nLeaving a path to another auditor is not leaving it unaccounted for. Record every resolved path no concern claimed as the accounting record shown in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`, with the exact resolved path as its `subject`: reconciliation matches inventory paths against recorded subjects, so a `subject` that is anything but the literal path leaves that path unaccounted forever. The record says the path was considered and left to another auditor, and names that auditor's skill as `\u003Cplugin>:\u003Caudit>` when the selection names an artifact-type audit skill for the path; it claims no coverage, creates no kind partition, and rejects no run, and it makes the run's own recorded subject set equal its sealed inventory.\n\nGive every selected concern skill the **complete** resolved three-dot changed-path set,\nthe resolved endpoint identities, discovered governing context, and the advisory\nlive file list when requested. Never pre-filter that set by extension,\ndirectory, or a guess at applicability: the selection decides which skills run, each concern skill owns its applicability within its selected match and answers for the paths it claims, and a set narrowed before\ndispatch produces a run whose coverage silently matches that guess rather than\nthe changeset. Require inspection of the selected committed bodies for committed\naudits. Each read-only concern skill identifies the subject paths it audited or returns `NOT_APPLICABLE`; the\norchestration never substitutes its own file-pattern table. Build the\npre-invocation inventory by selected kind and concern skill, then expand each\nconcern's result into subject-path units when its coverage status is settled: a\nrequired unit settles on a final status, an accounting record settles on `skipped`.\nA selected concern skill absent from the installed inventory records one required `missing-skill` unit whose `subject` and\n`priorContext.changedFilePartition` name the absent skill as `\u003Cplugin>:\u003Caudit>` rather than a path — no concern claimed a path, so\nnone is attached — with that skill as `expectedProducer`, and rejects the run.\nThe reconciler never counts a `missing-skill` unit as a subject outside the\ninventory; the paths themselves stay accounted by the kind's other concerns\nor by accounting records.\n\nEach expected unit carries the scope payload in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`: one resolved path as its `subject` — inspected by a concern, or accounted for as unclaimed; a `missing-skill` unit names the absent skill as `\u003Cplugin>:\u003Caudit>` instead — with `recordedByRunDriver` present on every unit so a missing-skill, unsupported, or accounting unit still identifies its recorder, `expectedProducer` naming the concern skill expected to cover it or the run-driver identity for an accounting record, and `producerProvenance` only where a concern skill executed. A concern's completion is every expected path unit carrying `coverageStatus: audited`; its finding count is the count of accepted finding rows for those path-scoped units.\n\n- Plan the complete inventory before invoking any concern skill. NEVER mark a planned unit `audited`.\n- Queue each unit only once its coverage status is settled: immediately for a classified gap or accounting record, or after its concern finishes for an executed producer.\n- NEVER append a preliminary required unit before its final coverage status is known — every accepted required uncovered event rejects the terminal rollup permanently.\n- A concern skill returns its result to the run driver and never writes SPX state itself.\n- After a concern returns, queue one path-scoped row per inspected path, carrying a stable path-scoped unit id, the exact path in `subject`, and `coverageStatus: audited`. NEVER record fewer rows than the concern returned paths, and NEVER collapse several inspected paths into one representative row — the recorded subject set is the evidence that the inspection happened, so a reduced set is an unverifiable claim.\n- Queue that concern's complete scope rows BEFORE any of its findings. A finding is recorded against coverage already accepted, never in place of it; recording a row only where a finding landed states the findings as the coverage.\n- Queue each returned finding on touched text after those scope rows, associated with its matching path-scoped unit. A finding outside touched text is queued nowhere: it is returned as `filed` under `\u003Cverdict_format>`.\n- Persist queued units one `spx -C '{repository-root}' verification run scope add` command at a time, ordered by the order each kind first appears in the selection, then concern order `code`, `tests`, `architecture`, preserving each command result before the next mutation and stopping at the first nonzero exit, other than the one rerun on an absent-payload diagnostic that the payload rules allow.\n- Derive the concern's finding count from the accepted finding rows; NEVER emit a custom count SPX discards.\n- A concern returning no complete result for a required unit MUST name the failed operation or absent prerequisite. When it names neither, drive the concern to a final result rather than recording a non-audited status.\n- NEVER manufacture a completed result from Claude's own inspection in place of a concern result.\n\nA missing selected concern skill or an unsupported path already claimed by a selected kind rejects the run through accepted coverage status and the evidence-derived terminal rollup. A required unit that receives no concern result reaches no admissible status, so the run returns BLOCKED under `\u003Cverdict_format>` naming the failed operation or absent prerequisite rather than sealing. An absent selected skill never shortens the inspection: dispatch every installed selected concern, record each path no concern claimed as an accounting record, persist the complete inventory serially, finish, and render the rejected run. An SPX command or payload rejection is a command failure and returns BLOCKED under `\u003Cverdict_format>` rather than becoming coverage evidence.\n\n\u003C\u002Fcoverage_model>\n\n\u003Cskill_map>\n\nFor each selected concern skill, compose it with the owned instruction, the selection's `plugin` and `audit` in place: Use skill `{plugin}:{audit}`. The selection entry's `role` fixes its concern partition — `implementation` maps to `code`, while `tests` and `architecture` keep their names — and its `kind` fixes the unit's kind partition.\n\nThe composition contract is the plugin-qualified skill name the selection carries; the registry's `concern` contract filter contains the dispatch, so only registry-selected concern skills run. The orchestration does not embed per-kind file globs, commands, test naming, architecture examples, or local standards. Each concern skill owns its policy and returns findings for its concern only.\n\n\u003C\u002Fskill_map>\n\n\u003Cfinding_model>\n\nRecord each accepted concern finding on touched text through `spx -C '{repository-root}' verification run finding add`, using the finding payload shape in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`; its `producerIdentity` matches the coverage unit's `expectedProducer`. Finding identity for convergence is content and stable producer identity, not plugin version, so a version change preserves provenance without making the same finding look new. Every `rule` is an identifier from `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frule-catalog.md` or, for a finding a composed concern skill returned, the identifier from that skill's own rule catalog; a finding naming any other identifier is withdrawn. Classify every returned finding as `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftouched-text.md` states, record only a finding on touched text, and return each other finding as `filed`.\n\n\u003C\u002Ffinding_model>\n\n\u003Cterminal_model>\n\nFinish the run only after the stage 7 reconciler exits zero. Record missing required skills, unsupported paths claimed by a selected kind, finding counts, and deterministic verification state in accepted scope and finding payload fields instead of terminal metadata.\n\nCompute the terminal status from accepted coverage and finding evidence: `approved` when every required non-gap unit is `audited` or `not-applicable` and no finding on touched text exists; `rejected` when a required unit is uncovered or any finding on touched text exists. A `filed` finding is never recorded through `finding add`, so it changes neither value. Pass that evidence-derived value through `finish --terminal-status`. Pass no terminal metadata for audit runs; the run's coverage and findings already carry the facts behind the terminal value.\n\nIf SPX rejects terminal status, report the rejected command and stderr as the audit result. Do not manufacture a prose fallback.\n\n\u003C\u002Fterminal_model>\n\n\u003C\u002Faudit_workflow>\n\n\u003Cverdict_format>\n\nWhen the run completes, return the exact run token, the exact run file, and the rendered `spx -C '{repository-root}' verification run render` projection. The projection's `terminalStatus` is authoritative: `approved` passes and `rejected` requires repair. Do not add an `APPROVED` or `REJECTED` prose envelope.\n\nReturn BLOCKED for three causes: target preparation fails before `spx\nverification run start` (a missing selector or identity field, a failed\ncommand, or the resolver's stale-base refusal), SPX rejects a command, or a\nrequired unit cannot reach a final status after the run started. Use the\ncomplete diagnostic below; preparation failures use `runToken: not-started`,\n`payloadSource: none`, and `payloadKey: none`.\n\nA required unit that cannot reach a final status is not a command rejection, so\nits diagnostic carries the started `runToken`, the absent prerequisite or failed\noperation in `command` — the exact operation attempted, such as the unreadable\nsubject path or the governing node that could not be discovered — and\n`payloadSource: none`, `payloadKey: none`, `exitCode: none`, `stderr: none`.\nName the unit by its `unitId` in the `command` line so the blocked unit is\nidentifiable. After a run starts, record a missing required concern skill\nas `missing-skill`, finish with terminal status `rejected`, render, and return\nthe run token, the run file, and the projection.\n\nPreserve each value verbatim from the invocation and command result:\n\n```text\nBLOCKED\nrunToken: \u003Cexact-token-if-start-succeeded-or-not-started>\ncommand: \u003Cexact-command-with-selectors-and-no-invented-redaction>\npayloadSource: \u003Cpayload-file-path-or-none>\npayloadKey: \u003CunitId-or-finding-idempotency-key-or-none>\nexitCode: \u003Cexact-exit-code>\nstderr: \u003Cexact-stderr>\ndiagnostic: \u003Cconfiguration error naming the refused path, or none>\n```\n\nNever return the command alone: the run token locates durable state, the payload\nsource and key identify the rejected boundary, and the exit code and stderr carry\nthe failure evidence — a stale-base refusal is read from its exit code and stderr.\n\nEach finding row names every field of the finding payload shape in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`, so a reader sees the producer, unit, rule, severity, location, message, and observed-versus-expected evidence without opening the journal. After the projection, return each `filed` finding on its own line in the form `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftouched-text.md` gives, or `filed: none`.\n\nThe rendered SPX projection is the inspection surface. Do not hand-format a competing verdict when `spx -C '{repository-root}' verification run render` succeeds.\n\n\u003C\u002Fverdict_format>\n\n\u003Cfailure_modes>\n\nA failed preparation, concern invocation, payload submission, or projection matches one failure below or one in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ffailure-modes.md`; read that file when a diagnostic matches none below, and before the first payload write. Preserve the exact diagnostic and apply the no-retry rule, since these records authorize no replacement invocation; the one rerun of a scope-add or finding-add command whose diagnostic names its payload file as absent is the only retry.\n\n**Failure 1: The request was empty or malformed**\n\nWhat happened: Claude received no resolvable scope or run-driver identity.\n\nWhy it failed: Starting a verification run without the required selector fields creates durable audit state that cannot be tied to the intended scope.\n\nHow to avoid: Resolve the target and validate the internal identity before\n`spx -C '{repository-root}' verification run start`; return the exact missing input or failed command\nwithout a retry or substitute scope.\n\n**Failure 2: A missing concern skill appeared after one concern already ran**\n\nWhat happened: Claude invoked one concern skill before validating that every concern skill the registry selected was installed.\n\nWhy it failed: The coverage inventory belongs before concern dispatch, so a late missing-skill discovery can leave other concern results without a complete expected-unit classification.\n\nHow to avoid: Validate and record every selected concern skill against the installed inventory before invoking any concern skill. Record an absent selected skill as `missing-skill` naming `\u003Cplugin>:\u003Caudit>`, then finish and render the rejected run.\n\n**Failure 5: Coverage labels replaced concern execution**\n\nWhat happened: Claude inspected changed files before opening the verification run, then emitted three scope rows labeled `audited` with generic partition subjects and no observable concern-skill results.\n\nWhy it failed: An `audited` label asserted completion without naming the inspected paths or preserving the concern invocation that produced the judgment. The sealed projection could not distinguish a completed concern audit from orchestration self-certification.\n\nHow to avoid: Start the run before project inspection and invoke each concern skill while the run is open. After a concern returns, record one accepted scope row per inspected path using the exact path in `subject` and `priorContext.changedFilePartition`, then record every finding with the accepted path-scoped `unitId`. Assign `coverageStatus: audited` only to those completed path-scoped rows; never emit custom concern-result fields.\n\n**Failure 10: A run sealed with required coverage uncovered and no blocker**\n\nWhat happened: Claude ended two audit attempts over one 48-path changeset with\nthe inspection unfinished. The second attempt recorded required `incomplete`\ncoverage for code, tests, and architecture, sealed `rejected` with zero\nfindings, and reported \"No external or tool condition blocks completion\" before\nfinishing.\n\nWhy it failed: `incomplete` was a finishable state for a required unit, so\n`finish` was reachable from Claude deciding to stop. A sealed `rejected` run\nwith no findings is indistinguishable at the projection from a completed audit\nthat found a coverage gap, so the gate consumed a giving-up as a verdict.\n\nHow to avoid: A required unit reaches only `audited`, `not-applicable`,\n`missing-skill`, or `unsupported`. When none is reachable, return the\n`\u003Cverdict_format>` blocked diagnostic naming the concrete failed operation or\nabsent prerequisite. Remaining work, elapsed time, context pressure, and\nunfinished reading are never that cause.\n\n**Failure 15: A narrowed plan reconciled with itself and sealed an approved run**\n\nWhat happened: Claude narrowed coverage to four paths of the resolved\nchangeset, planned four units, recorded four units, confirmed at stage 7 that\nevery planned unit carried a final status, and sealed the run `approved` with\nzero findings. Its own postmortem confirmed it had preserved no other inspected\npath. The projection reads as a complete approval of a changeset it never\ninspected.\n\nWhy it failed: Reconciling recorded units against the run's own plan tests\ninternal consistency, never correspondence to the changeset. A plan narrowed\nbefore enumeration reconciles perfectly, so the check that was meant to prevent\na partial seal certified one instead.\n\nHow to avoid: Reconcile at stage 7 with the bundled reconciler, whose referent\nis the run's own sealed start inventory rather than the plan. Its exit code is\nthe verdict: exit 1 naming only unaccounted paths returns the run to\ninspection; exit 1 naming drift, an unexpected subject, or a non-final\nrequired unit returns the blocked diagnostic whatever else it names, because\nno inspection changes what the selector resolves to and the append-only run\nrevises neither an accepted subject nor an accepted status; and only its zero\nexit reaches `finish`.\n\n**Failure 16: A run recorded a unit only where it found something, then let the rejection end it**\n\nWhat happened: Claude started the run with the complete 48-path inventory\nfrom the resolver's file, loaded the concern skills the selection named, and read\nfourteen subject bodies. It then recorded two scope units — both `code`, both\nfor paths carrying its one finding — added that finding, and finished\n`rejected`. Twelve inspected paths, every `tests` unit, and every\n`architecture` unit went unrecorded. The stage 7 reconciliation never ran.\n\nWhy it failed: Two failures compose. Scope rows were treated as anchors a\nfinding needs rather than as the evidence that an inspection happened, so a path\ninspected and found clean produced no row at all. The early `rejected` verdict\nthen read as settled — the run's outcome could not change — which made the\nremaining concerns look like work with no consequence. Both are invisible in the\nsealed projection unless a reader compares its subjects against its inventory,\nand the run driver comparing against its own recollection has nothing to\ncontradict it.\n\nHow to avoid: Persist a concern's complete claimed-path coverage before any of\nits findings, so a row exists for every inspected path whether or not it carries\none. Treat `rejected` as a verdict about what was inspected, never as permission\nto stop: the remaining concerns and every unclaimed resolved path are recorded\nbefore `finish`. Then run the stage 7 reconciler, which fails on exactly this\nshape by naming the paths the run left unaccounted.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- The verdict covers every concern skill the registry selects for the supplied scope: the code, tests, and architecture concerns of every selected kind.\n- A missing required concern skill after run start appears as `missing-skill` rejected coverage in the projection; the projection's `terminalStatus` is the sole determination.\n- Every recorded finding is falsifiable: a reader reproduces its judgment from the unit, rule identifier, location, and observed-versus-expected evidence it carries, and a standing finding on untouched text rejects no run.\n- Every missing-skill, unsupported-path, and accounting unit appears in the rendered projection rather than in prose, and each audited concern preserves its complete inspected-path set as path-scoped units whose `subject` fields are the exact paths, audited only after that concern completes, with finding counts derived from accepted finding rows rather than a custom field.\n- The same request, committed scope, normalized live file list, and installed plugin versions produce the same coverage units, finding identities, and terminal determination.\n- Every gate-eligible run addresses an exact committed head with no live-file additions and established passing deterministic evidence; an explicit `worktree:` target includes the complete discovered modified and untracked path list and supplies no reusable gate evidence.\n- The sealed run is self-describing: its recorded subject set equals the inventory its own start input carries, no recorded subject lies outside that inventory, every required unit carries a final status and every unclaimed path its accounting record, and every finding references an accepted unit of its own concern — so a reader establishes the inspection's completeness from the run without the run driver's account of it.\n- A run that reaches no admissible status for a required unit seals no projection; a head behind the fetched base returns the resolver's stale-base refusal before any subject is read.\n- No plugin-side verdict script, legacy journal command, deterministic verification command, or kind-specific file pattern can affect the determination outside the SPX-recorded run.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\n\nAn authoritative SPX projection, raw run token, and run file for the requested implementation scope, judged against its governing decisions and specs and the standards of every concern skill the artifact registry selects for its changed paths, carrying `terminalStatus` (`approved` or `rejected`), the findings on touched text — each naming the artifact, the violated rule, and observed-versus-expected evidence — and every other finding returned as `filed`. A run that cannot reach that projection yields a `BLOCKED` diagnostic naming the request failure, command failure, or absent prerequisite that stopped it.\n\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\n- NEVER edit source, tests, specs, commits, branches, or pull requests — the audit is read-only over the audited project tree; the only state it changes is its payload files in the session scratch directory and the SPX verification-run journal its own recording commands write, and the file-write tool writes payload files only.\n- ALWAYS persist audit state through `spx verification run`; NEVER use legacy journal commands, plugin-side verdict scripts, markdown comments, `.spx\u002Faudits\u002F`, or tracked files as audit state.\n- NEVER run deterministic verification — the audit composes agentic concern audits only.\n- NEVER derive a kind, a partition, or a skill name from a file extension, a filename, or a language name — the artifact registry the scope resolver reads carries every kind and the skills it selects, the run reads each skill name from that selection, and each concern skill owns its policy.\n- ALWAYS treat the `spx verification run` command exit code as payload validity; NEVER hand-validate emitted payload JSON after SPX accepts it.\n- NEVER end a run because work remains, time has passed, context is tight, or reading is unfinished — a stop names the failed command with its exit code and stderr, or the absent prerequisite.\n- NEVER assign `incomplete` or `skipped` to a required coverage unit; neither describes an admissible terminal state for required coverage.\n- NEVER derive a subject body from a single commit's patch, or leave a truncated read unrecovered — a partial read is re-issued, never converted into coverage evidence.\n- NEVER hand-transcribe the resolved changed-path set into a payload — the resolver takes its audit input from a file in the session scratch directory and writes the run-start input to a file that the run-start command takes by path, because a retyped inventory drops and substitutes paths without any later step noticing.\n- NEVER select a skill from the installed skill inventory, and NEVER invoke a skill to discover whether a kind is installed — the registry selection in the run's sealed start input is the only selection source; the inventory this context carries decides only whether a selected skill runs or is recorded as `missing-skill`, and a failed invocation is not selection evidence.\n- ALWAYS record coverage as `\u003Ccoverage_model>` states; a run that narrows a set or records a unit only where it found something states its findings as its coverage.\n- NEVER let a raised finding or a rejected terminal status shorten the inspection: rejection is a verdict about what was inspected, never permission to leave a concern or a resolved path unrecorded.\n- ALWAYS start the verification run after resolving the target's Git metadata and validating the run-driver identity, before reading changed project file bodies or loading concern standards — every substantive project inspection and concern result belongs to the open run.\n- NEVER write the run journal or its context anywhere but the locations `spx verification run` resolves. When the native permission policy refuses a run-recording write — a payload file, a resolver output file, a run-recording command, or the journal — stop at that write, retry it no more, write to no other location, and return the `\u003Cverdict_format>` blocked diagnostic with `diagnostic: configuration error` naming the refused path; the host grants the paths, and this skill never widens its own access.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\n\n\u003Cexecution_sequence>\n\nRun these stages in order. Each names what holds before the next begins, and\n`finish` is reachable only from stage 7.\n\n1. **Anchor.** Resolve the repository, the scope selector, and the run-driver\n   identity per `\u003Crequest_contract>`. Retain the resolved `base` and `head`\n   identities unchanged for the rest of the run.\n2. **Open the run.** Start the run per `\u003Cverification_run_contract>` before any\n   project inspection or standards load, so every later stage belongs to it.\n3. **Load.** Read each discovered governing node's context, the governing\n   standards of each selected concern skill, and the audited repository's\n   declared `spx\u002Flocal\u002F` overlays.\n4. **Enumerate.** Build the complete expected coverage inventory per\n   `\u003Ccoverage_model>` before invoking any concern, reading the path set from the\n   `resolvedScope` the `start` result returned and each path's artifact\n   selection from the run's sealed start input, never from a retyped list or a\n   re-run of the resolver. Every resolved path enters the inventory — claimed by\n   a concern or left to another auditor — and a unit enters planned, without a\n   status.\n5. **Inspect.** Read each subject body completely from the resolved\n   `base..head` scope, re-issuing a truncated or partial read in bounded\n   ranges until the body is complete, per the subject-body constraint.\n6. **Record.** Hold each unit planned until its concern returns a final result,\n   classify each returned finding per the touched-text reference, then persist per `\u003Ccoverage_model>`. NEVER accept a finding raised before stage 3 loaded that concern's standards and overlays — withdraw it.\n7. **Reconcile, then finish.** Run the bundled reconciler; `finish` is\n   reachable only from its zero exit:\n\n   ```bash\n   python3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fresolve_scope.py\" '{committed-selector}' --repo '{repository-root}' --reconcile-run '{run-token}' --scope-identity '\u003Cbase>..\u003Chead>'\n   ```\n\n   `{committed-selector}` is the selector with any `worktree:` prefix removed,\n   exactly as stage 1 resolved it; `--scope-identity` is the stage 1 identity,\n   unchanged. The reconciler reads the run's sealed start inventory — with an\n   advisory run's `live_paths` beside it — and its recorded units, and emits\n   `unaccounted`, `unexpected`, `drifted`, and `nonfinal`. Exit 0 reaches\n   `finish`. Exit 1 with a non-empty `drifted`, `unexpected`, or `nonfinal`\n   returns the `\u003Cverdict_format>` blocked diagnostic naming that field,\n   whatever else the verdict carries: no inspection repairs drift, an accepted\n   subject cannot be removed, and an accepted required status cannot be\n   revised, so a new run addresses the head. Exit 1 with only `unaccounted`\n   returns the run to stage 5 or 6 for its remaining rows. Exit 2 is a command failure reported\n   under `\u003Cverdict_format>`. The referent is the sealed inventory, never the\n   plan the run driver holds; Failure 15 in\n   `\u003Cfailure_modes>` carries the reasoning.\n\nA run that cannot bring a required unit to a stage 6 status returns the\n`\u003Cverdict_format>` blocked diagnostic naming the concrete failed operation or\nabsent prerequisite. Remaining work, elapsed time, context pressure, and\nunfinished reading are never such a cause.\n\n\u003C\u002Fexecution_sequence>\n\n\u003Crequest_contract>\n\nBind the target scope selector before discovery. `$ARGUMENTS` supplies the\nrequest tokens when that argument is non-empty; when it is empty, the tokens are\nthe ones the request text carries, and the empty substitution binds nothing. Only a request\nthat carries no selector is the missing-input case. The target is one scope\nselector: `HEAD`, a branch, or an explicit three-dot range. `worktree:` before\na selector explicitly requests an advisory audit of that committed scope plus\nthe complete modified and untracked file set. Preserve the selector verbatim.\nNever infer advisory intent from a dirty checkout.\n\nRun-driver identity uses the six published producer fields (the\n`expectedProducer` shape in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`) in the invocation\ncontext, separate from `$ARGUMENTS`. Accept that identity generically; never\ninfer it from a role name, installed plugin, or descriptive text.\n\nA target in another worktree reaches the audit as the absolute path of the\ncheckout directory that holds the audited scope. The request carries the\nselector first and that directory second, separated by one space; a directory\npath that contains a space is wrapped in double quotes, and a request with one\ntoken carries the selector alone. Bind each token separately and preserve each\nverbatim. The session's working directory never decides the repository.\n\nBefore reading project file bodies:\n\n1. Resolve the repository root from the repository that holds the target: with\n   `git -C '{target-directory}' rev-parse --show-toplevel` when the request\n   names a target directory, and with `git rev-parse --show-toplevel` when it\n   names none. Run every later git command against that root with `git -C\n   '{repository-root}'` and every `spx verification run` command with `spx -C\n   '{repository-root}' verification run`, because an unrooted command resolves\n   its scope and store from the session's working directory, which may hold\n   another checkout. Address every file the audit reads or searches by its\n   absolute path beneath that root. Return the `\u003Cverdict_format>` blocked diagnostic with\n   `runToken: not-started` naming the target directory when it is no\n   repository checkout, and again when the resolved `head` or any\n   `changed_paths` entry does not resolve in that root; the audit judges no\n   scope outside the repository that holds its target.\n2. For an advisory target, remove only its `worktree:` prefix. Resolve the\n   remaining selector through the bundled consumer of `\u002Fscope-changeset`:\n\n   ```bash\n   python3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fresolve_scope.py\" '{selector}' --repo '{repository-root}'\n   ```\n\n   Read its `base` and `head`; the full endpoint IDs form the SPX scope identity\n   `{base}..{head}`. Never reinterpret that identity as a two-dot changed-file\n   query or substitute a local base branch. Its three-dot `changed_paths` reach\n   the run through the file in `\u003Cverification_run_contract>`, never by being\n   read out and retyped: a changeset carries more paths than a response\n   reproduces reliably, and a dropped path there is invisible to every later\n   stage. Quote each substituted argument independently, applying the\n   apostrophe splice below.\n3. Read `git -C '{repository-root}' status --porcelain=v1 -z --untracked-files=all`. An advisory audit includes every reported modified or untracked path,\n   consuming NUL-delimited paths and both paths of a rename or copy. A committed\n   audit includes none of those live changes. Read committed subject bodies with\n   `git -C '{repository-root}' show '{head}:{path}'` whenever the working file differs or the selected\n   head is not the checkout's `HEAD`; never silently audit a different version.\n   For a deleted path, inspect its base-side body and the committed deletion.\n4. Validate the generic run-driver identity and retain already-established\n   deterministic verification facts for this exact committed subject from the\n   available context. When evidence is unavailable, record it as unestablished;\n   never infer passing checks from a clean checkout or run them inside the audit.\n\nA missing selector or identity, failed repository discovery, or failed scope\nresolution returns `BLOCKED` with `runToken: not-started` and the exact missing\ninput or command failure; the resolver's stale-base refusal — a dedicated exit\ncode and a `stale-base` diagnostic on stderr for a head behind the fetched base\n— returns the same way before any subject is read. Make no replacement scope\nselection, synchronization, or retry.\n\nStart the run after this metadata preparation. Then discover governing nodes\nfrom the resolved paths through the product-tree evidence links and declared audit\nownership, load their context read-only, and pass that discovered context to the\nconcern skills. Never synchronize, rebase, or otherwise mutate the audited\ncheckout. Preserve missing governance as coverage evidence under the existing\ncoverage model. A committed audit is reusable only when the applicable\ndeterministic verification is established as passing for that subject; an\nadvisory audit never supplies reusable gate evidence.\n\n\u003C\u002Frequest_contract>\n\n\u003Cverification_run_contract>\n\nAfter validating the request, start one audit run as the first audit action. Do\nthis before loading concern standards, inspecting the changeset, or\ninvoking concern skills, so the returned run token identifies the in-flight\naudit from its beginning:\n\nHave the resolver write the run-start input to a file, so the resolved `base`,\n`head`, and complete `changed_paths` enter the run exactly as git produced them.\nName two paths in the session scratch directory, each unique to this run: the\naudit-input file, such as `\u003Crun-id>-audit-input.json`, written with the\nfile-write tool, and the resolver's output file, such as\n`\u003Crun-id>-start-input.json`. Pass the audit-input file as the resolver's\n`--audit-input` path, the session scratch directory as its `--scratch-dir` path,\nand the output file as its `--output` path:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fresolve_scope.py\" '{selector}' --repo '{repository-root}' --audit-input '\u003Caudit-input-file>' --scratch-dir '\u003Cscratch-directory>' --output '\u003Cstart-input-file>'\n```\n\nThen start the run with its own command, passing that file by path:\n\n```bash\nspx -C '{repository-root}' verification run start --verification-type audit --scope-type changeset --scope \u003Cbase>..\u003Chead> --input '\u003Cstart-input-file>'\n```\n\nThe audit-input file holds one JSON object carrying only the short values the\ninvocation supplies: the original selector, the resolved repository root, the\ndiscovered live file list under `live_paths` for an advisory audit, available\ndeterministic verification facts, generic run-driver identity, and advisory\nstatus. Write it with the file-write tool into the session scratch directory and pass\nits path exactly as the file-write result reports it; pass no inline JSON\nargument. The resolver refuses a file that resolves outside the directory named\nby `--scratch-dir` and exits nonzero, which returns the `\u003Cverdict_format>`\nblocked diagnostic with `runToken: not-started`. The\nresolver merges the object beneath the resolved scope,\nso a key that collides with `base`, `head`, or `changed_paths` is discarded\nrather than honored — the resolved scope is authoritative and unforgeable at\nthis boundary.\n\nGoverning nodes are discovered after start and accompany the concern inputs and\ncoverage evidence. The command returns a JSON locator; extract its `runToken`\nfield exactly and use that token for every later command, retain the run target it reports as the run file (only the start report names it), and read its\n`resolvedScope` array as the run's sealed inventory — the path set stage 4\nenumerates and stage 7 reconciles against. The resolver also recorded, under\n`artifact_selection` in that input, the registered artifacts and audit skills\neach path selects; `\u003Ccoverage_model>` reads it back with\n`spx -C '{repository-root}' verification run input`. Never pass the whole locator as `--run`.\n\nExecute every state-changing `spx -C '{repository-root}' verification run` command serially: a tool\nresponse or batch contains at most one `start`, `scope add`, `finding add`, or\n`finish` for a run, and the next mutation waits for that command to exit and\npreserves its result. NEVER place two journal mutations in a parallel tool\ngroup, multi-call batch, shell background group, or concurrently executing\nconcern — parallel writes race sequence assignment and produce a sealed\nprojection whose event prefix is neither strictly increasing nor contiguous.\nParallel concern analysis emits no SPX commands; queue each concern's completed\nresults and persist them one at a time. Render only after `finish` exits\nsuccessfully.\n\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md` before writing the first scope or finding payload: it carries the scope, accounting-record, and finding payload JSON, the idempotency key forms, and the payload-file rules. Those rules bind every command that follows:\n\n- Write each scope and finding payload with the file-write tool to its own file in the session scratch directory, and pass `--payload` the path exactly as the file-write result reports it, never retyped.\n- Add each scope unit and each finding with its own literal command, one at a time, and stop at the first nonzero exit with the `\u003Cverdict_format>` blocked diagnostic; the one exception is a single rerun of a scope-add or finding-add whose diagnostic names its payload file as absent. A permission refusal is no absent payload file and takes no rerun.\n- Pass every idempotency key as one single-quoted argument.\n- Send no payload through a heredoc, a pipe, or an inline argument, and remove no payload file.\n\n```bash\nspx -C '{repository-root}' verification run scope add --verification-type audit --scope-type changeset --scope '\u003Cbase>..\u003Chead>' --run '\u003Ctoken>' --idempotency-key '\u003Cstable-scope-key>' --payload '\u003Cscope-file>'\nspx -C '{repository-root}' verification run finding add --verification-type audit --scope-type changeset --scope '\u003Cbase>..\u003Chead>' --run '\u003Ctoken>' --idempotency-key '\u003Cstable-scope-key>:\u003Crule>' --payload '\u003Cfinding-file>'\n```\n\n```bash\nspx -C '{repository-root}' verification run finish \\\n  --verification-type audit \\\n  --scope-type changeset \\\n  --scope \u003Cbase>..\u003Chead> \\\n  --run \u003Ctoken> \\\n  --terminal-status \u003Cevidence-derived-status>\n\nspx -C '{repository-root}' verification run render \\\n  --verification-type audit \\\n  --scope-type changeset \\\n  --scope \u003Cbase>..\u003Chead> \\\n  --run \u003Ctoken>\n```\n\nThe final response relays the rendered SPX projection, the run token, and the run file. Do not summarize findings from memory when the render is available.\n\n\u003C\u002Fverification_run_contract>\n\n\u003Ccoverage_model>\n\nBuild the expected coverage inventory from the selection the scope resolver recorded in the run's sealed start input, before invoking any concern skill. Read the `artifact_selection` array back from that input — `spx -C '{repository-root}' verification run input --verification-type audit --scope-type changeset --scope \u003Cbase>..\u003Chead> --run '{run-token}'`, field `content` — never from a re-run of the resolver and never from a reading of the paths. For each resolved path, and each live path of an advisory audit, it holds the registered artifacts whose detection matches the path, most specific within a kind, kinds in declaration order, a kind with a match adding its detection-less artifacts; each artifact carries its `kind`, `role`, `plugin`, `audit` skill, and `contract`. Dispatch exactly the skills that selection names, validating each against the installed skill inventory this context carries before invoking any concern. The inventory never selects: it decides only whether a selected skill is invoked or recorded as a required `missing-skill` unit, and invoking a skill is dispatch to a selected artifact, never a probe for whether a kind is installed. Never load a write-capable author skill inside the audit — the skill-composition grant cannot be narrowed to names selected at run time, so this rule is the containment — and never create a partition from a file extension, filename, or artifact class the registry did not select.\n\nDispatch only a skill whose `contract` is `concern`. A path whose registered artifact's audit skill carries the `artifact-type` contract, a path matching no registered artifact, and a matched path whose selected concern skill returns `NOT_APPLICABLE` stay with their artifact-type auditor and the whole-changeset review; never manufacture a kind, a missing skill, or an unsupported unit for such a path.\n\nLeaving a path to another auditor is not leaving it unaccounted for. Record every resolved path no concern claimed as the accounting record shown in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`, with the exact resolved path as its `subject`: reconciliation matches inventory paths against recorded subjects, so a `subject` that is anything but the literal path leaves that path unaccounted forever. The record says the path was considered and left to another auditor, and names that auditor's skill as `\u003Cplugin>:\u003Caudit>` when the selection names an artifact-type audit skill for the path; it claims no coverage, creates no kind partition, and rejects no run, and it makes the run's own recorded subject set equal its sealed inventory.\n\nGive every selected concern skill the **complete** resolved three-dot changed-path set,\nthe resolved endpoint identities, discovered governing context, and the advisory\nlive file list when requested. Never pre-filter that set by extension,\ndirectory, or a guess at applicability: the selection decides which skills run, each concern skill owns its applicability within its selected match and answers for the paths it claims, and a set narrowed before\ndispatch produces a run whose coverage silently matches that guess rather than\nthe changeset. Require inspection of the selected committed bodies for committed\naudits. Each read-only concern skill identifies the subject paths it audited or returns `NOT_APPLICABLE`; the\norchestration never substitutes its own file-pattern table. Build the\npre-invocation inventory by selected kind and concern skill, then expand each\nconcern's result into subject-path units when its coverage status is settled: a\nrequired unit settles on a final status, an accounting record settles on `skipped`.\nA selected concern skill absent from the installed inventory records one required `missing-skill` unit whose `subject` and\n`priorContext.changedFilePartition` name the absent skill as `\u003Cplugin>:\u003Caudit>` rather than a path — no concern claimed a path, so\nnone is attached — with that skill as `expectedProducer`, and rejects the run.\nThe reconciler never counts a `missing-skill` unit as a subject outside the\ninventory; the paths themselves stay accounted by the kind's other concerns\nor by accounting records.\n\nEach expected unit carries the scope payload in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`: one resolved path as its `subject` — inspected by a concern, or accounted for as unclaimed; a `missing-skill` unit names the absent skill as `\u003Cplugin>:\u003Caudit>` instead — with `recordedByRunDriver` present on every unit so a missing-skill, unsupported, or accounting unit still identifies its recorder, `expectedProducer` naming the concern skill expected to cover it or the run-driver identity for an accounting record, and `producerProvenance` only where a concern skill executed. A concern's completion is every expected path unit carrying `coverageStatus: audited`; its finding count is the count of accepted finding rows for those path-scoped units.\n\n- Plan the complete inventory before invoking any concern skill. NEVER mark a planned unit `audited`.\n- Queue each unit only once its coverage status is settled: immediately for a classified gap or accounting record, or after its concern finishes for an executed producer.\n- NEVER append a preliminary required unit before its final coverage status is known — every accepted required uncovered event rejects the terminal rollup permanently.\n- A concern skill returns its result to the run driver and never writes SPX state itself.\n- After a concern returns, queue one path-scoped row per inspected path, carrying a stable path-scoped unit id, the exact path in `subject`, and `coverageStatus: audited`. NEVER record fewer rows than the concern returned paths, and NEVER collapse several inspected paths into one representative row — the recorded subject set is the evidence that the inspection happened, so a reduced set is an unverifiable claim.\n- Queue that concern's complete scope rows BEFORE any of its findings. A finding is recorded against coverage already accepted, never in place of it; recording a row only where a finding landed states the findings as the coverage.\n- Queue each returned finding on touched text after those scope rows, associated with its matching path-scoped unit. A finding outside touched text is queued nowhere: it is returned as `filed` under `\u003Cverdict_format>`.\n- Persist queued units one `spx -C '{repository-root}' verification run scope add` command at a time, ordered by the order each kind first appears in the selection, then concern order `code`, `tests`, `architecture`, preserving each command result before the next mutation and stopping at the first nonzero exit, other than the one rerun on an absent-payload diagnostic that the payload rules allow.\n- Derive the concern's finding count from the accepted finding rows; NEVER emit a custom count SPX discards.\n- A concern returning no complete result for a required unit MUST name the failed operation or absent prerequisite. When it names neither, drive the concern to a final result rather than recording a non-audited status.\n- NEVER manufacture a completed result from Claude's own inspection in place of a concern result.\n\nA missing selected concern skill or an unsupported path already claimed by a selected kind rejects the run through accepted coverage status and the evidence-derived terminal rollup. A required unit that receives no concern result reaches no admissible status, so the run returns BLOCKED under `\u003Cverdict_format>` naming the failed operation or absent prerequisite rather than sealing. An absent selected skill never shortens the inspection: dispatch every installed selected concern, record each path no concern claimed as an accounting record, persist the complete inventory serially, finish, and render the rejected run. An SPX command or payload rejection is a command failure and returns BLOCKED under `\u003Cverdict_format>` rather than becoming coverage evidence.\n\n\u003C\u002Fcoverage_model>\n\n\u003Cskill_map>\n\nFor each selected concern skill, compose it with the owned instruction, the selection's `plugin` and `audit` in place: Use skill `{plugin}:{audit}`. The selection entry's `role` fixes its concern partition — `implementation` maps to `code`, while `tests` and `architecture` keep their names — and its `kind` fixes the unit's kind partition.\n\nThe composition contract is the plugin-qualified skill name the selection carries; the registry's `concern` contract filter contains the dispatch, so only registry-selected concern skills run. The orchestration does not embed per-kind file globs, commands, test naming, architecture examples, or local standards. Each concern skill owns its policy and returns findings for its concern only.\n\n\u003C\u002Fskill_map>\n\n\u003Cfinding_model>\n\nRecord each accepted concern finding on touched text through `spx -C '{repository-root}' verification run finding add`, using the finding payload shape in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`; its `producerIdentity` matches the coverage unit's `expectedProducer`. Finding identity for convergence is content and stable producer identity, not plugin version, so a version change preserves provenance without making the same finding look new. Every `rule` is an identifier from `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frule-catalog.md` or, for a finding a composed concern skill returned, the identifier from that skill's own rule catalog; a finding naming any other identifier is withdrawn. Classify every returned finding as `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftouched-text.md` states, record only a finding on touched text, and return each other finding as `filed`.\n\n\u003C\u002Ffinding_model>\n\n\u003Cterminal_model>\n\nFinish the run only after the stage 7 reconciler exits zero. Record missing required skills, unsupported paths claimed by a selected kind, finding counts, and deterministic verification state in accepted scope and finding payload fields instead of terminal metadata.\n\nCompute the terminal status from accepted coverage and finding evidence: `approved` when every required non-gap unit is `audited` or `not-applicable` and no finding on touched text exists; `rejected` when a required unit is uncovered or any finding on touched text exists. A `filed` finding is never recorded through `finding add`, so it changes neither value. Pass that evidence-derived value through `finish --terminal-status`. Pass no terminal metadata for audit runs; the run's coverage and findings already carry the facts behind the terminal value.\n\nIf SPX rejects terminal status, report the rejected command and stderr as the audit result. Do not manufacture a prose fallback.\n\n\u003C\u002Fterminal_model>\n\n\u003C\u002Faudit_workflow>\n\n\u003Cverdict_format>\n\nWhen the run completes, return the exact run token, the exact run file, and the rendered `spx -C '{repository-root}' verification run render` projection. The projection's `terminalStatus` is authoritative: `approved` passes and `rejected` requires repair. Do not add an `APPROVED` or `REJECTED` prose envelope.\n\nReturn BLOCKED for three causes: target preparation fails before `spx\nverification run start` (a missing selector or identity field, a failed\ncommand, or the resolver's stale-base refusal), SPX rejects a command, or a\nrequired unit cannot reach a final status after the run started. Use the\ncomplete diagnostic below; preparation failures use `runToken: not-started`,\n`payloadSource: none`, and `payloadKey: none`.\n\nA required unit that cannot reach a final status is not a command rejection, so\nits diagnostic carries the started `runToken`, the absent prerequisite or failed\noperation in `command` — the exact operation attempted, such as the unreadable\nsubject path or the governing node that could not be discovered — and\n`payloadSource: none`, `payloadKey: none`, `exitCode: none`, `stderr: none`.\nName the unit by its `unitId` in the `command` line so the blocked unit is\nidentifiable. After a run starts, record a missing required concern skill\nas `missing-skill`, finish with terminal status `rejected`, render, and return\nthe run token, the run file, and the projection.\n\nPreserve each value verbatim from the invocation and command result:\n\n```text\nBLOCKED\nrunToken: \u003Cexact-token-if-start-succeeded-or-not-started>\ncommand: \u003Cexact-command-with-selectors-and-no-invented-redaction>\npayloadSource: \u003Cpayload-file-path-or-none>\npayloadKey: \u003CunitId-or-finding-idempotency-key-or-none>\nexitCode: \u003Cexact-exit-code>\nstderr: \u003Cexact-stderr>\ndiagnostic: \u003Cconfiguration error naming the refused path, or none>\n```\n\nNever return the command alone: the run token locates durable state, the payload\nsource and key identify the rejected boundary, and the exit code and stderr carry\nthe failure evidence — a stale-base refusal is read from its exit code and stderr.\n\nEach finding row names every field of the finding payload shape in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frun-payloads.md`, so a reader sees the producer, unit, rule, severity, location, message, and observed-versus-expected evidence without opening the journal. After the projection, return each `filed` finding on its own line in the form `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftouched-text.md` gives, or `filed: none`.\n\nThe rendered SPX projection is the inspection surface. Do not hand-format a competing verdict when `spx -C '{repository-root}' verification run render` succeeds.\n\n\u003C\u002Fverdict_format>\n\n\u003Cfailure_modes>\n\nA failed preparation, concern invocation, payload submission, or projection matches one failure below or one in `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ffailure-modes.md`; read that file when a diagnostic matches none below, and before the first payload write. Preserve the exact diagnostic and apply the no-retry rule, since these records authorize no replacement invocation; the one rerun of a scope-add or finding-add command whose diagnostic names its payload file as absent is the only retry.\n\n**Failure 1: The request was empty or malformed**\n\nWhat happened: Claude received no resolvable scope or run-driver identity.\n\nWhy it failed: Starting a verification run without the required selector fields creates durable audit state that cannot be tied to the intended scope.\n\nHow to avoid: Resolve the target and validate the internal identity before\n`spx -C '{repository-root}' verification run start`; return the exact missing input or failed command\nwithout a retry or substitute scope.\n\n**Failure 2: A missing concern skill appeared after one concern already ran**\n\nWhat happened: Claude invoked one concern skill before validating that every concern skill the registry selected was installed.\n\nWhy it failed: The coverage inventory belongs before concern dispatch, so a late missing-skill discovery can leave other concern results without a complete expected-unit classification.\n\nHow to avoid: Validate and record every selected concern skill against the installed inventory before invoking any concern skill. Record an absent selected skill as `missing-skill` naming `\u003Cplugin>:\u003Caudit>`, then finish and render the rejected run.\n\n**Failure 5: Coverage labels replaced concern execution**\n\nWhat happened: Claude inspected changed files before opening the verification run, then emitted three scope rows labeled `audited` with generic partition subjects and no observable concern-skill results.\n\nWhy it failed: An `audited` label asserted completion without naming the inspected paths or preserving the concern invocation that produced the judgment. The sealed projection could not distinguish a completed concern audit from orchestration self-certification.\n\nHow to avoid: Start the run before project inspection and invoke each concern skill while the run is open. After a concern returns, record one accepted scope row per inspected path using the exact path in `subject` and `priorContext.changedFilePartition`, then record every finding with the accepted path-scoped `unitId`. Assign `coverageStatus: audited` only to those completed path-scoped rows; never emit custom concern-result fields.\n\n**Failure 10: A run sealed with required coverage uncovered and no blocker**\n\nWhat happened: Claude ended two audit attempts over one 48-path changeset with\nthe inspection unfinished. The second attempt recorded required `incomplete`\ncoverage for code, tests, and architecture, sealed `rejected` with zero\nfindings, and reported \"No external or tool condition blocks completion\" before\nfinishing.\n\nWhy it failed: `incomplete` was a finishable state for a required unit, so\n`finish` was reachable from Claude deciding to stop. A sealed `rejected` run\nwith no findings is indistinguishable at the projection from a completed audit\nthat found a coverage gap, so the gate consumed a giving-up as a verdict.\n\nHow to avoid: A required unit reaches only `audited`, `not-applicable`,\n`missing-skill`, or `unsupported`. When none is reachable, return the\n`\u003Cverdict_format>` blocked diagnostic naming the concrete failed operation or\nabsent prerequisite. Remaining work, elapsed time, context pressure, and\nunfinished reading are never that cause.\n\n**Failure 15: A narrowed plan reconciled with itself and sealed an approved run**\n\nWhat happened: Claude narrowed coverage to four paths of the resolved\nchangeset, planned four units, recorded four units, confirmed at stage 7 that\nevery planned unit carried a final status, and sealed the run `approved` with\nzero findings. Its own postmortem confirmed it had preserved no other inspected\npath. The projection reads as a complete approval of a changeset it never\ninspected.\n\nWhy it failed: Reconciling recorded units against the run's own plan tests\ninternal consistency, never correspondence to the changeset. A plan narrowed\nbefore enumeration reconciles perfectly, so the check that was meant to prevent\na partial seal certified one instead.\n\nHow to avoid: Reconcile at stage 7 with the bundled reconciler, whose referent\nis the run's own sealed start inventory rather than the plan. Its exit code is\nthe verdict: exit 1 naming only unaccounted paths returns the run to\ninspection; exit 1 naming drift, an unexpected subject, or a non-final\nrequired unit returns the blocked diagnostic whatever else it names, because\nno inspection changes what the selector resolves to and the append-only run\nrevises neither an accepted subject nor an accepted status; and only its zero\nexit reaches `finish`.\n\n**Failure 16: A run recorded a unit only where it found something, then let the rejection end it**\n\nWhat happened: Claude started the run with the complete 48-path inventory\nfrom the resolver's file, loaded the concern skills the selection named, and read\nfourteen subject bodies. It then recorded two scope units — both `code`, both\nfor paths carrying its one finding — added that finding, and finished\n`rejected`. Twelve inspected paths, every `tests` unit, and every\n`architecture` unit went unrecorded. The stage 7 reconciliation never ran.\n\nWhy it failed: Two failures compose. Scope rows were treated as anchors a\nfinding needs rather than as the evidence that an inspection happened, so a path\ninspected and found clean produced no row at all. The early `rejected` verdict\nthen read as settled — the run's outcome could not change — which made the\nremaining concerns look like work with no consequence. Both are invisible in the\nsealed projection unless a reader compares its subjects against its inventory,\nand the run driver comparing against its own recollection has nothing to\ncontradict it.\n\nHow to avoid: Persist a concern's complete claimed-path coverage before any of\nits findings, so a row exists for every inspected path whether or not it carries\none. Treat `rejected` as a verdict about what was inspected, never as permission\nto stop: the remaining concerns and every unclaimed resolved path are recorded\nbefore `finish`. Then run the stage 7 reconciler, which fails on exactly this\nshape by naming the paths the run left unaccounted.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- The verdict covers every concern skill the registry selects for the supplied scope: the code, tests, and architecture concerns of every selected kind.\n- A missing required concern skill after run start appears as `missing-skill` rejected coverage in the projection; the projection's `terminalStatus` is the sole determination.\n- Every recorded finding is falsifiable: a reader reproduces its judgment from the unit, rule identifier, location, and observed-versus-expected evidence it carries, and a standing finding on untouched text rejects no run.\n- Every missing-skill, unsupported-path, and accounting unit appears in the rendered projection rather than in prose, and each audited concern preserves its complete inspected-path set as path-scoped units whose `subject` fields are the exact paths, audited only after that concern completes, with finding counts derived from accepted finding rows rather than a custom field.\n- The same request, committed scope, normalized live file list, and installed plugin versions produce the same coverage units, finding identities, and terminal determination.\n- Every gate-eligible run addresses an exact committed head with no live-file additions and established passing deterministic evidence; an explicit `worktree:` target includes the complete discovered modified and untracked path list and supplies no reusable gate evidence.\n- The sealed run is self-describing: its recorded subject set equals the inventory its own start input carries, no recorded subject lies outside that inventory, every required unit carries a final status and every unclaimed path its accounting record, and every finding references an accepted unit of its own concern — so a reader establishes the inspection's completeness from the run without the run driver's account of it.\n- A run that reaches no admissible status for a required unit seals no projection; a head behind the fetched base returns the resolver's stale-base refusal before any subject is read.\n- No plugin-side verdict script, legacy journal command, deterministic verification command, or kind-specific file pattern can affect the determination outside the SPX-recorded run.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":44,"argument-hint":45},"Read, Bash(python3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fresolve_scope.py\":*), Bash(git rev-parse:*), Bash(git -C * rev-parse:*), Bash(git -C * status:*), Bash(git -C * show:*), Bash(spx -C * verification run:*), Write, Glob, Grep, {{! tool('use_skill') !}}","\u003CHEAD | branch | base...head | worktree:selector> [absolute checkout directory]","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-implementation","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-14 20:33:56",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add outcomeeng\u002Fplugins --skill audit-implementation",{"tool":60,"command":61},"bunx","bunx skills add outcomeeng\u002Fplugins --skill audit-implementation",{"tool":63,"command":64},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill audit-implementation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-implementation\u002FSKILL.md",true,[68,74,78,82,86],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Ffailure-modes.md","REFERENCE","参考文档",12083,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-implementation\u002Freferences\u002Ffailure-modes.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Frule-catalog.md",2645,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-implementation\u002Freferences\u002Frule-catalog.md",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Frun-payloads.md",8756,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-implementation\u002Freferences\u002Frun-payloads.md",{"path":83,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Ftouched-text.md",2997,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-implementation\u002Freferences\u002Ftouched-text.md",{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"scripts\u002Fresolve_scope.py","SCRIPT","脚本",19439,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-implementation\u002Fscripts\u002Fresolve_scope.py",[93,99,136,152,168,181],{"skillNo":94,"name":95,"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":96,"categories":97,"keywords":98,"publishedAt":39},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[95],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":115,"publishedAt":39},"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",[105,110],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":39},"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",[],[143,144,145,146,147,123,134,148,149,135,150,151],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":161,"publishedAt":39},"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",[158],{"categoryNo":159,"categoryName":160,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000008","测试与质量",[162,163,164,32,165,166,167],"typescript","typescript test standards","test","false","read","across",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":177,"publishedAt":39},"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",[174],{"categoryNo":175,"categoryName":176,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000030","开发工程师",[162,178,179,180,32,165,166,167],"code","typescript code standards","code standards",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":39},"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",[],[188,32,189,190,162,191,192,167,166,193,165,194],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]