[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K3ASSD16M8VG7FRPZACY1K":3,"skill-same:01M6K3ASSD16M8VG7FRPZACY1K":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":71},"01M6K3ASSD16M8VG7FRPZACY1K","coherence-check",null,"Use only within active engineer\u002Fconduct DECIDE after plan for a Medium or Large spec. Authors the committed outcomes-to-requirements-to-stories-to-tasks mapping; do not invoke for Small work or ordinary traceability questions.","jstoup111\u002Fai-conductor","jstoup111","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1585332?v=4","01M6K374Y0VEFPVCT2KPBAN4HC","James Stoup","01M6K3751X0GFKNBD0198F50XN",7,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fcoherence-check\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"check","coherence check","coherence","active","invoke","gating","stories","conduct","for","claims","true","questions","traceability","requirements","tasks","do","engineer","only","outcomes","use","decide","work","plan","verify","2026-11-10 10:12:30",false,"---\nname: coherence-check\nimplicit_invocation: required\ndescription: \"Use only within active engineer\u002Fconduct DECIDE after plan for a Medium or Large spec. Authors the committed outcomes-to-requirements-to-stories-to-tasks mapping; do not invoke for Small work or ordinary traceability questions.\"\nenforcement: gating\nphase: decide\nstandalone: true\nrequires: [verify-claims]\n---\n\n## Purpose\n\nAuthors `.docs\u002Fcoherence\u002F\u003Cplan-stem>.md`: a single committed artifact mapping every\nintake outcome bullet, every PRD FR (product track), every non-deleted ADR file in the\ncurrent spec change set when the coherence gate engages, every story,\nand every plan task to its counterpart ids with a per-row verdict. This artifact is the auditable\ntraceability record the operator (and the land-time coherence validator) reads instead\nof trusting self-reported \"everything's covered\" prose in a spec PR.\n\nAny current-change-set `.docs\u002Fdecisions\u002Fadr-*` path, including a deletion, engages the ADR\nlayer. That engagement is distinct from the ADR row pool: deleted ADRs produce no row, so a\ndeletion-only change has no ADR row to author.\n\n**Correctness gate:** a row's verdict (`covered` \u002F `gap` \u002F `fail`) is a judgment call, not\na mechanical grep. Mapping and achievability are separate questions: a counterpart can exist while\na criterion still cannot be delivered (§4g). Per the `\u002Fverify-claims` protocol, ground every verdict in the actual\ncited text — do not mark a row covered on the assumption that a plausible-looking\ncounterpart id exists; confirm it against the real artifact file.\n\n## 1. Tier Rule (M\u002FL only)\n\nRead the spec's tier from `.docs\u002Fcomplexity\u002F`.\n\n- **Tier S:** this skill does NOT run. Skip it entirely — same treatment as\n  architecture-diagram\u002Farchitecture-review\u002Fconflict-check for S tier. No\n  `.docs\u002Fcoherence\u002F` artifact is authored, and the land-time validator does not engage\n  for S-tier specs (Story 13). Do not author a stub file \"to be safe\" — its mere\n  presence is not required and produces work the S-tier exemption exists to avoid.\n- **Tier M:** this skill runs, using the session's default model (no override).\n- **Tier L:** this skill runs, pinned to opus for the dispatch (see Section 2).\n\n## 2. Model Rule (M = session default, L = pinned opus)\n\nThis skill is tier-varying, the same pattern as `conflict-check` and `plan`:\n\n- **M tier:** inherit whatever model the invoking session\u002Fstep is already running —\n  no pin.\n- **L tier:** pin to **opus** for this dispatch. Large-tier specs have the widest\n  fan-out of outcomes\u002FFRs\u002Fstories\u002Ftasks and the highest cost of a missed transitive\n  gap, so the semantic-judging pass needs the deepest reasoning tier.\n\nThe autonomous\u002Fdaemon path applies this through each provider policy's\n`stepTierOverrides.coherence_check.L` in `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fprovider-model-policy-defaults.ts`\n(Claude: `opus`; Codex: `gpt-5.6-sol`); this SKILL.md documents the same rule\nfor interactive\u002Fphone-driven runs, where the operator's active session may not be opus\nand must be told to escalate.\n\n## 3. Inputs\n\nLoad, in order:\n\n1. Staged\u002Fcommitted intake outcomes — `.pipeline\u002F` staged outcomes file if present, or\n   the committed `.docs\u002Fintake\u002F\u003Cplan-stem>.md` marker if land has already run once.\n   If neither exists (chat-origin idea), the outcome row class is not required.\n2. The approved PRD (product track only) — `.docs\u002Fspecs\u002F\u003Cplan-stem>.md`, for its\n   enumerated `FR-N` requirements.\n3. The stories file — `.docs\u002Fstories\u002F\u003Cplan-stem>.md`, for `**Requirement:**` and story\n   ids.\n4. The plan — `.docs\u002Fplans\u002F\u003Cplan-stem>.md`, for `**Story:**` lines, task ids, the\n   plan's own `## Coverage Check` table if present, and its `## Architecture Obligation\n   Coverage` table when the changed ADR pool contains citable decisions.\n5. The ADR files in the current spec change set — each non-deleted\n   `.docs\u002Fdecisions\u002Fadr-*.md` file. This is the row set when the coherence gate engages;\n   do not expand it to every decision that conceptually constrains the stories.\n\n## 4. Mapping-Artifact Format\n\nWrite `.docs\u002Fcoherence\u002F\u003Cplan-stem>.md`. The plan-stem in the filename MUST match the\nplan's own filename stem exactly — the land validator rejects a stem mismatch as\nmissing-coherence-artifact even when a coherence file exists under a different name.\n\nThe artifact is a Markdown table (or one table per row class) with these columns:\n\n| Row class | Cited id(s) | Counterpart id(s) | Verdict | Notes |\n|---|---|---|---|---|\n\n### 4a. Row Classes (six)\n\n1. **outcome** — one row per intake Desired-outcome bullet (skip this class entirely\n   if no outcomes were staged\u002Fcommitted — an empty outcome layer is \"not required,\"\n   never a gap). Cited id: `outcome-\u003Cn>` (1-based, in bullet order). Counterpart:\n   the story id(s) that cover the bullet. The `Quote` cell must be the staged bullet\n   itself — the sanitized projection under `.pipeline\u002Fintake-outcomes.md`, not the\n   tracker's raw text and not a paraphrase. Only presentation is normalized away (a\n   leading list marker, surrounding quotation marks, collapsed whitespace), so any\n   other difference is an unmatched outcome\n   (adr-2026-09-06-inbound-intake-trust-boundary D10).\n2. **fr** — one row per enumerated PRD `FR-N` (product track only; skip this class on\n   the technical track). Cited id: `fr-\u003CN>`. Counterpart: the story id(s) whose\n   `**Requirement:**` line cites that FR.\n3. **story** — one row per story id declared in the stories file. Cited id:\n   `story-\u003Cid>`. Counterpart: the task id(s) whose `**Story:**` line cites that story.\n4. **task** — one row per task in the plan's task tree. Cited id: `task-\u003Cid>`.\n   Counterpart: the story id it serves, OR — for `infrastructure`\u002F`refactor`-typed\n   tasks — a non-empty supporting-purpose statement from the task's `**Story:**` line\n   in place of a story id.\n5. **adr** — when the coherence gate engages, one row per non-deleted\n   `.docs\u002Fdecisions\u002Fadr-*.md` file in the current spec change set. Cited id:\n   `adr-\u003Cstem>`. Counterpart: the story id(s) that implement or are constrained by the\n   decision. Its verdict also covers the decision-by-decision plan mapping required by\n   Section 4f; any incorrect mapping makes this ADR row `fail`.\n6. **criterion** — one row per exact happy or negative Given\u002FWhen\u002FThen\n   criterion extracted from the stories file. Its cells are the exact criterion\n   text, cited task id(s), verdict, a verbatim quote from one cited task's\n   `Done when` block, and a diff-locality disposition. The quote is matched as\n   an exact substring after whitespace normalization; a paraphrase does not\n   ground coverage. Do not quote Steps or Files prose: those describe work but\n   do not require its completion, so they can ground a claim the builder is not\n   obliged to satisfy. The disposition is exactly `diff-local` or\n   `outside-diff`; only `diff-local` is non-negative and lands without a\n   coherence waiver. A seventh optional correction cell is allowed only when\n   the verdict is `fail`: use `plan`, or\n   `architecture:adr-\u003Cstem>#D\u003Cn>` for a decision enumerated from a non-deleted\n   ADR in the current change set. A corrected failure records a waivable\n   `criterion:cannot-deliver-\u003Clayer>:\u003Cn>` gap; an unknown architecture decision\n   also reports `criterion:correction-unknown-decision:\u003Cn>`. Do not use the\n   correction cell on `covered` or `gap` rows.\n\n**Layer ownership.** Story↔story pairs belong to `\u002Fconflict-check`. Cross-layer and task versus task\npairs belong to plan review at Medium and Large tier, and to the plan's §7b at Small tier.\n`\u002Fconflict-check` runs before `\u002Fplan`, so it cannot see tasks.\n\n### 4b. Verdict Vocabulary\n\nUse exactly these three verdict values — this is the same vocabulary the land-time\nvalidator parses and the same vocabulary the coherence-waiver mechanism consumes:\n\n- **covered** — the cited id has ≥1 real counterpart id (confirmed to exist in the\n  counterpart's own artifact file, not merely referenced); a criterion row must also establish\n  achievability (§4g).\n- **gap** — the cited id has zero counterparts, or its only counterpart is itself\n  transitively uncovered (e.g. a story maps to a task, but that task cites no story\n  back, or the coverage table claims a task id that does not exist in the task tree).\n- **fail** — the cited id has a real counterpart, but the cited task checks cannot deliver the\n  criterion under the approved architecture (§4g), or a required ADR decision mapping is\n  semantically wrong (§4f). Coverage is satisfied here; achievability or architecture alignment is\n  not. Recording it as `gap` would misdescribe it and send the reader hunting for a missing\n  artifact that is in fact present and wrong.\n\n**The exact strings matter more than they look.** The land-time validator treats\n`gap`, `missing`, `uncovered`, and `fail` as blocking for legacy rows, and **every other string as\naffirmative**. Criterion rows instead reject any verdict outside `covered`, `gap`, and `fail`.\nAn invented verdict — \"partial\", \"contradiction\", \"n\u002Fa\", \"pending\" — can therefore\n*silently pass the legacy gate* or make a criterion row malformed. That is why a\nachievability or architecture-alignment failure is recorded as `fail` rather than as a new word that\nreads more precisely: `fail` is already in the blocking set and already flows into the gap list a\nwaiver can cite. A row that is genuinely not applicable (e.g. the FR row class on a\ntechnical-track spec) is omitted entirely, never given a placeholder verdict.\n\n### 4c. Gap-ID Scheme\n\nEvery **gap** row's Notes column MUST restate its gap id in one of these canonical\nforms — this is the vocabulary a `.docs\u002Fcoherence-waivers\u002F\u003Cplan-stem>.md` waiver names\nto be recognized (waivers are validated by a separate mechanism; this skill only needs\nto emit the ids in the correct form so a later waiver can cite them):\n\nFor the `adr` row class, the cited id form and the canonical gap-id form are both\n`adr-\u003Cstem>`, where `\u003Cstem>` is the ADR filename stem.\n\n- `outcome-\u003Cn>` — unmapped or negative-verdict outcome bullet, or one whose row quotes\n  something other than the staged sanitized bullet\n- `fr-\u003CN>` — FR cited by no story, or only by a story that itself maps to no task\n- `story-\u003Cid>` — story cited by no task, or a story that does not tie out to the PRD\n  (cites an `FR-N` the PRD never declares, or cites no FR at all — §4e)\n- `task-\u003Cid>` — task with no valid story citation and no supporting-purpose exemption\n- `adr-\u003Cstem>` — non-deleted ADR file in the current spec change set cited by no story,\n  or only by a story that does not implement or honor the decision\n- `claim-\u003Crow>` — the plan's own `## Coverage Check` table cites a phantom id or\n  contradicts the parsed task tree (row number within that table)\n- `criterion:quote-not-done-when:\u003Cn>` — a criterion quote occurs in the cited\n  task body but not in any cited task's `Done when` block\n- `duplicate:\u003Cref>` — a second spec claiming an already-claimed `Source-Ref` (emitted\n  by the land-time duplicate-claim scan, not authored here — documented for vocabulary\n  completeness only)\n\nGap ids are opaque strings to downstream consumers (the validator, the waiver parser)\n— do not paraphrase or abbreviate them; use the exact forms above so cross-checking\nagainst the real artifact files (Section 5) is possible.\n\nBefore marking a criterion row `covered`, read every cited task's `Done when` block\nand verify that the quoted text comes from one of those checks.\n\nA **fail** row uses the same id form as its row class (`outcome-\u003Cn>`, `fr-\u003CN>`,\n`story-\u003Cid>`, `task-\u003Cid>`, `adr-\u003Cstem>`) — the id identifies *which* row, and the\nverdict says what is wrong with it. Name the supporting evidence in Notes so a reader can\nadjudicate without re-deriving the finding.\n\nUse `CANNOT-DELIVER:` for an achievability failure (§4g). Criterion rows have six required cells\nand no Notes cell; a `fail` row may add the optional seventh correction cell described in §4a.\nKeep the exact criterion text, task ids, verdict, verbatim `Done when` quote, and disposition\nintact. Put the explanation in a prose paragraph directly below the table, naming the criterion,\ncited task id, quoted check, and any binding ADR decision. Do not append commentary to the quote\nor create another table for these notes. This prefix is explanatory prose, not a verdict,\ndisposition, gap id, or correction-layer routing signal. Do not invent an achievability-specific\ngap-id form.\n\n### 4e. PRD ↔ Stories Tie-Out\n\nThe `fr` and `story` row classes are the two halves of one question: **do the PRD and the\nstories tie out?** Both directions must hold, and they fail differently:\n\n- **Forward (PRD → stories).** Every enumerated `FR-N` is cited by ≥1 story's\n  `**Requirement:**` line, and ≥1 of those stories is itself covered by a plan task. An FR\n  nothing implements is `gap` on its `fr` row (`fr-\u003CN>`).\n- **Reverse (stories → PRD).** Every story cites ≥1 `FR-N`, and every `FR-N` it cites is one\n  the PRD actually declares. A story citing `FR-9` when the PRD stops at `FR-4` is a phantom\n  requirement; a story citing no FR at all is untraced — it asserts behavior the product spec\n  never asked for. Either is `gap` on that story's `story` row (`story-\u003Cid>`).\n\nBoth directions are **enforced mechanically by the land-time gate** over parsed ids — it\nre-derives them from the real PRD and stories files regardless of what this artifact claims,\nand reports every offending id, not the first. Do not spend judgement re-deriving set\nmembership by hand: read the ids, record the rows, and let the gate be the authority on\ncoverage. Plan review at Medium and Large tier, and the plan's §7b at Small tier, own whether\ncross-layer artifacts conflict; this tie-out does not repeat that judgment.\n\n### 4f. Architecture-Decision ↔ Plan Tie-Out\n\nFor every citable decision in each non-deleted ADR in the current spec change set, independently judge\nthe plan's `## Architecture Obligation Coverage` row. A `task` disposition is `covered` only when the\ncited task's `Done when:` semantically asserts the decision—not merely because the task id and quoted\ntext exist. An `existing` disposition is covered only with verified implementation evidence; a\n`no-change` disposition is covered only when the decision genuinely imposes no implementation change on\nthis feature. If any decision mapping is semantically wrong, mark the parent `adr` row `fail` and identify\nthe decision id plus opposing evidence in Notes.\n\nThe land-time gate owns the mechanical checks: complete and unique decision ids, the closed disposition\nvocabulary, real task citations, and exact Done-when evidence. Do not duplicate those string\u002Fset checks.\nThis skill owns the judgement the engine cannot compute: whether that real evidence actually fulfills the\narchitecture obligation.\n\n### 4g. Achievability Pass\n\nFor every criterion row, ask: **given only what the cited task's `Done when` checks actually assert,\nand the approved architecture that constrains it, would satisfying them produce the criterion's\nThen-clause?** Related work and compatible wording do not establish delivery. When multiple tasks\nare cited, judge their checks together; do not require each task to deliver the whole criterion\nindependently, or assume an unstated connection between them.\n\nA task whose checks require only logging a warning, allowing an unsigned artifact through, is a\n§4g failure: all its checks can pass without rejection.\n\nA cited task that cannot deliver the criterion is **`fail`**, not `covered` or `gap`. The counterpart\nexists and coverage is satisfied; what is wrong is that its promised behavior does not work. Use the\nexisting verdict so the validator blocks it, and explain the failure with `CANNOT-DELIVER:` prose\nbelow the table per §4c.\n\nApply these detection heuristics:\n\n- **Mechanism-vs-restatement.** If the cited check merely paraphrases the Then-clause instead of\n  naming the code path, state change, or check that produces it, achievability is unestablished: the\n  task asserts the outcome without establishing how it delivers it. Surface this uncertainty per\n  §5 rather than crediting it. A named mechanism still needs to yield the criterion; its name alone\n  is not proof. Do not fill missing obligations from Steps prose or presumed BUILD work.\n- **Constraint sweep.** Re-read the criterion against each approved ADR in the current change set.\n  If the task could deliver it only by violating an approved decision, mark the criterion row `fail`.\n  The explanation must name the `adr-\u003Cstem>`, decision id, and binding decision text. Preserve §4f's\n  separate architecture-obligation judgement and its existing row pool.\n- **Representable outcomes.** When the approved design uses a closed set of states, result values,\n  or reasons, walk each required happy and negative scenario through the cited checks and identify\n  the legal value that represents its actual outcome. Include required absence, skip, and no-change\n  cases: reporting that an operation ran cannot deliver a criterion saying it did not run. A set\n  whose permitted values cannot express a required outcome is `fail`, even if the producer and\n  consumer agree on the same incomplete set. Quote the scenario and binding set; do not demand a\n  distinct value per scenario when an existing value represents it truthfully, or invent scenarios\n  outside the accepted criteria. Unspecified value meanings remain an assumption under §5.\n- **Input-boundary proof.** If checks operate on a prepared input, normalized status, or exported\n  subset, trace the required scenario to the check that produces that input from the actual source.\n  A helper that correctly handles `invalid` does not establish that malformed source data becomes\n  `invalid`; matching a registry to an exported subset does not establish that the subset includes\n  everything the criterion quantifies over. Identify the decoding\u002Fvalidation or enumeration boundary\n  and its owning task check. Consider required error exits too: a later reporter cannot supply a\n  promised result if the planned earlier refusal never reaches it. Credit existing evidence and\n  sibling tasks, and distinguish a demonstrated bypass (`fail`) from an unspecified connection (§5).\n\nGround each finding in the exact criterion and cited `Done when` text, with the binding ADR decision\nwhere applicable. \"This task feels thin\" is not a finding. If the artifacts do not settle\nachievability, surface the uncertainty as an assumption under §5: interactive runs wait for operator\nconfirmation; autonomous runs record `gap`. Never turn an unconfirmed assumption into a pass.\n\n## 5. Semantic-Judging Instructions (verify-claims protocol)\n\nPer `\u002Fverify-claims`, this skill is a **verifier\u002Fjudge** role: it renders a verdict\nper row and must never assert \"covered\" that it has not actually confirmed.\n\n- **Calibrate claims.** Before marking a row covered, `Read`\u002F`grep` the counterpart\n  artifact file and confirm the cited id is real and the coverage is genuine (not just\n  a plausible-sounding phrase match). Prefer the cheap read over an inferred guess\n  every time it would settle the question.\n- **Surface every assumption.** If a row's coverage is ambiguous (e.g. a story vaguely\n  gestures at an outcome without an explicit citation), do not silently resolve it in\n  either direction — surface it as an assumption with confidence, impact-if-wrong, and\n  how to confirm, per the repository's correctness and assumption gate.\n- **Hard-block on unconfirmed load-bearing assumptions.** A verdict on this artifact is\n  load-bearing — it gates land. Never mark a row \"covered\" on an unconfirmed\n  assumption about what a story or task \"probably\" means. Interactive runs: present\n  the ambiguous row and wait for operator confirmation before finalizing the artifact.\n  Autonomous\u002Fdaemon runs: mark the row `gap` and let the fail-closed land gate surface\n  it — never silently resolve ambiguity as a pass.\n- **Fabricated citations are never coverage.** A cited counterpart id that does not\n  exist in its source file is not \"covered with a typo\" — it is a gap, and the\n  land-time validator independently cross-checks every cited id against the real\n  artifact files regardless of what this skill wrote.\n\n## 6. Output\n\n1. Write `.docs\u002Fcoherence\u002F\u003Cplan-stem>.md` with the table(s) described in Section 4.\n2. Ensure the file renders as valid Markdown (a real table, not fenced prose) — it\n   must be readable directly in the spec PR diff (Story 2).\n3. Do not stage or commit a coherence artifact for a technical-track spec's `fr` row\n   class, a chat-origin spec's `outcome` row class, or an `adr` row class when the current\n   spec change set has no non-deleted `.docs\u002Fdecisions\u002Fadr-*.md` file — omission is\n   correct there, not a gap. A deleted ADR path still engages the ADR layer, but it does\n   not enter that row pool.\n\n## Verification\n\n- [ ] Tier read from `.docs\u002Fcomplexity\u002F`; skill does not run at all for tier S\n- [ ] Tier L dispatch is pinned to opus; tier M inherits the session\u002Fstep default\n- [ ] `.docs\u002Fcoherence\u002F\u003Cplan-stem>.md` filename stem matches the plan's filename stem exactly\n- [ ] All five row classes present where applicable (outcome\u002Ffr\u002Fadr omitted only when genuinely not required)\n- [ ] Every verdict is exactly `covered`, `gap`, or `fail` — no invented verdict strings\n      (legacy rows can silently pass them; criterion rows reject them as malformed)\n- [ ] §4e PRD↔stories tie-out checked in BOTH directions — no FR without a story, and no\n      story citing a phantom FR or citing no FR at all\n- [ ] §4f architecture-decision mappings judged semantically; every `task`, `existing`, or\n      `no-change` disposition actually satisfies its cited ADR decision\n- [ ] §4g achievability judged for every criterion from cited `Done when` checks and approved\n      architecture; mechanism-vs-restatement, ADR constraints, representable outcomes, and input boundaries checked\n- [ ] Established inability to deliver recorded as `fail`; unsettled achievability handled under §5\n- [ ] Each achievability failure has `CANNOT-DELIVER:` prose below the table naming the criterion,\n      task id, quoted check, and any binding ADR and decision id; six-cell rows and quotes stay intact\n- [ ] Story↔story pairs left to `\u002Fconflict-check`; plan review at Medium and Large tier and plan\n      §7b at Small tier own cross-layer and task-versus-task checks\n- [ ] Every `gap` row's Notes column restates its gap id in the canonical form (Section 4c)\n- [ ] Every `covered` verdict was confirmed against the real counterpart artifact file, not inferred\n- [ ] Ambiguous rows surfaced as assumptions (interactive: wait for confirmation; autonomous: mark `gap`, never silently pass)\n- [ ] Output renders as a valid Markdown table in the spec PR diff\n","## Purpose\n\nAuthors `.docs\u002Fcoherence\u002F\u003Cplan-stem>.md`: a single committed artifact mapping every\nintake outcome bullet, every PRD FR (product track), every non-deleted ADR file in the\ncurrent spec change set when the coherence gate engages, every story,\nand every plan task to its counterpart ids with a per-row verdict. This artifact is the auditable\ntraceability record the operator (and the land-time coherence validator) reads instead\nof trusting self-reported \"everything's covered\" prose in a spec PR.\n\nAny current-change-set `.docs\u002Fdecisions\u002Fadr-*` path, including a deletion, engages the ADR\nlayer. That engagement is distinct from the ADR row pool: deleted ADRs produce no row, so a\ndeletion-only change has no ADR row to author.\n\n**Correctness gate:** a row's verdict (`covered` \u002F `gap` \u002F `fail`) is a judgment call, not\na mechanical grep. Mapping and achievability are separate questions: a counterpart can exist while\na criterion still cannot be delivered (§4g). Per the `\u002Fverify-claims` protocol, ground every verdict in the actual\ncited text — do not mark a row covered on the assumption that a plausible-looking\ncounterpart id exists; confirm it against the real artifact file.\n\n## 1. Tier Rule (M\u002FL only)\n\nRead the spec's tier from `.docs\u002Fcomplexity\u002F`.\n\n- **Tier S:** this skill does NOT run. Skip it entirely — same treatment as\n  architecture-diagram\u002Farchitecture-review\u002Fconflict-check for S tier. No\n  `.docs\u002Fcoherence\u002F` artifact is authored, and the land-time validator does not engage\n  for S-tier specs (Story 13). Do not author a stub file \"to be safe\" — its mere\n  presence is not required and produces work the S-tier exemption exists to avoid.\n- **Tier M:** this skill runs, using the session's default model (no override).\n- **Tier L:** this skill runs, pinned to opus for the dispatch (see Section 2).\n\n## 2. Model Rule (M = session default, L = pinned opus)\n\nThis skill is tier-varying, the same pattern as `conflict-check` and `plan`:\n\n- **M tier:** inherit whatever model the invoking session\u002Fstep is already running —\n  no pin.\n- **L tier:** pin to **opus** for this dispatch. Large-tier specs have the widest\n  fan-out of outcomes\u002FFRs\u002Fstories\u002Ftasks and the highest cost of a missed transitive\n  gap, so the semantic-judging pass needs the deepest reasoning tier.\n\nThe autonomous\u002Fdaemon path applies this through each provider policy's\n`stepTierOverrides.coherence_check.L` in `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fprovider-model-policy-defaults.ts`\n(Claude: `opus`; Codex: `gpt-5.6-sol`); this SKILL.md documents the same rule\nfor interactive\u002Fphone-driven runs, where the operator's active session may not be opus\nand must be told to escalate.\n\n## 3. Inputs\n\nLoad, in order:\n\n1. Staged\u002Fcommitted intake outcomes — `.pipeline\u002F` staged outcomes file if present, or\n   the committed `.docs\u002Fintake\u002F\u003Cplan-stem>.md` marker if land has already run once.\n   If neither exists (chat-origin idea), the outcome row class is not required.\n2. The approved PRD (product track only) — `.docs\u002Fspecs\u002F\u003Cplan-stem>.md`, for its\n   enumerated `FR-N` requirements.\n3. The stories file — `.docs\u002Fstories\u002F\u003Cplan-stem>.md`, for `**Requirement:**` and story\n   ids.\n4. The plan — `.docs\u002Fplans\u002F\u003Cplan-stem>.md`, for `**Story:**` lines, task ids, the\n   plan's own `## Coverage Check` table if present, and its `## Architecture Obligation\n   Coverage` table when the changed ADR pool contains citable decisions.\n5. The ADR files in the current spec change set — each non-deleted\n   `.docs\u002Fdecisions\u002Fadr-*.md` file. This is the row set when the coherence gate engages;\n   do not expand it to every decision that conceptually constrains the stories.\n\n## 4. Mapping-Artifact Format\n\nWrite `.docs\u002Fcoherence\u002F\u003Cplan-stem>.md`. The plan-stem in the filename MUST match the\nplan's own filename stem exactly — the land validator rejects a stem mismatch as\nmissing-coherence-artifact even when a coherence file exists under a different name.\n\nThe artifact is a Markdown table (or one table per row class) with these columns:\n\n| Row class | Cited id(s) | Counterpart id(s) | Verdict | Notes |\n|---|---|---|---|---|\n\n### 4a. Row Classes (six)\n\n1. **outcome** — one row per intake Desired-outcome bullet (skip this class entirely\n   if no outcomes were staged\u002Fcommitted — an empty outcome layer is \"not required,\"\n   never a gap). Cited id: `outcome-\u003Cn>` (1-based, in bullet order). Counterpart:\n   the story id(s) that cover the bullet. The `Quote` cell must be the staged bullet\n   itself — the sanitized projection under `.pipeline\u002Fintake-outcomes.md`, not the\n   tracker's raw text and not a paraphrase. Only presentation is normalized away (a\n   leading list marker, surrounding quotation marks, collapsed whitespace), so any\n   other difference is an unmatched outcome\n   (adr-2026-09-06-inbound-intake-trust-boundary D10).\n2. **fr** — one row per enumerated PRD `FR-N` (product track only; skip this class on\n   the technical track). Cited id: `fr-\u003CN>`. Counterpart: the story id(s) whose\n   `**Requirement:**` line cites that FR.\n3. **story** — one row per story id declared in the stories file. Cited id:\n   `story-\u003Cid>`. Counterpart: the task id(s) whose `**Story:**` line cites that story.\n4. **task** — one row per task in the plan's task tree. Cited id: `task-\u003Cid>`.\n   Counterpart: the story id it serves, OR — for `infrastructure`\u002F`refactor`-typed\n   tasks — a non-empty supporting-purpose statement from the task's `**Story:**` line\n   in place of a story id.\n5. **adr** — when the coherence gate engages, one row per non-deleted\n   `.docs\u002Fdecisions\u002Fadr-*.md` file in the current spec change set. Cited id:\n   `adr-\u003Cstem>`. Counterpart: the story id(s) that implement or are constrained by the\n   decision. Its verdict also covers the decision-by-decision plan mapping required by\n   Section 4f; any incorrect mapping makes this ADR row `fail`.\n6. **criterion** — one row per exact happy or negative Given\u002FWhen\u002FThen\n   criterion extracted from the stories file. Its cells are the exact criterion\n   text, cited task id(s), verdict, a verbatim quote from one cited task's\n   `Done when` block, and a diff-locality disposition. The quote is matched as\n   an exact substring after whitespace normalization; a paraphrase does not\n   ground coverage. Do not quote Steps or Files prose: those describe work but\n   do not require its completion, so they can ground a claim the builder is not\n   obliged to satisfy. The disposition is exactly `diff-local` or\n   `outside-diff`; only `diff-local` is non-negative and lands without a\n   coherence waiver. A seventh optional correction cell is allowed only when\n   the verdict is `fail`: use `plan`, or\n   `architecture:adr-\u003Cstem>#D\u003Cn>` for a decision enumerated from a non-deleted\n   ADR in the current change set. A corrected failure records a waivable\n   `criterion:cannot-deliver-\u003Clayer>:\u003Cn>` gap; an unknown architecture decision\n   also reports `criterion:correction-unknown-decision:\u003Cn>`. Do not use the\n   correction cell on `covered` or `gap` rows.\n\n**Layer ownership.** Story↔story pairs belong to `\u002Fconflict-check`. Cross-layer and task versus task\npairs belong to plan review at Medium and Large tier, and to the plan's §7b at Small tier.\n`\u002Fconflict-check` runs before `\u002Fplan`, so it cannot see tasks.\n\n### 4b. Verdict Vocabulary\n\nUse exactly these three verdict values — this is the same vocabulary the land-time\nvalidator parses and the same vocabulary the coherence-waiver mechanism consumes:\n\n- **covered** — the cited id has ≥1 real counterpart id (confirmed to exist in the\n  counterpart's own artifact file, not merely referenced); a criterion row must also establish\n  achievability (§4g).\n- **gap** — the cited id has zero counterparts, or its only counterpart is itself\n  transitively uncovered (e.g. a story maps to a task, but that task cites no story\n  back, or the coverage table claims a task id that does not exist in the task tree).\n- **fail** — the cited id has a real counterpart, but the cited task checks cannot deliver the\n  criterion under the approved architecture (§4g), or a required ADR decision mapping is\n  semantically wrong (§4f). Coverage is satisfied here; achievability or architecture alignment is\n  not. Recording it as `gap` would misdescribe it and send the reader hunting for a missing\n  artifact that is in fact present and wrong.\n\n**The exact strings matter more than they look.** The land-time validator treats\n`gap`, `missing`, `uncovered`, and `fail` as blocking for legacy rows, and **every other string as\naffirmative**. Criterion rows instead reject any verdict outside `covered`, `gap`, and `fail`.\nAn invented verdict — \"partial\", \"contradiction\", \"n\u002Fa\", \"pending\" — can therefore\n*silently pass the legacy gate* or make a criterion row malformed. That is why a\nachievability or architecture-alignment failure is recorded as `fail` rather than as a new word that\nreads more precisely: `fail` is already in the blocking set and already flows into the gap list a\nwaiver can cite. A row that is genuinely not applicable (e.g. the FR row class on a\ntechnical-track spec) is omitted entirely, never given a placeholder verdict.\n\n### 4c. Gap-ID Scheme\n\nEvery **gap** row's Notes column MUST restate its gap id in one of these canonical\nforms — this is the vocabulary a `.docs\u002Fcoherence-waivers\u002F\u003Cplan-stem>.md` waiver names\nto be recognized (waivers are validated by a separate mechanism; this skill only needs\nto emit the ids in the correct form so a later waiver can cite them):\n\nFor the `adr` row class, the cited id form and the canonical gap-id form are both\n`adr-\u003Cstem>`, where `\u003Cstem>` is the ADR filename stem.\n\n- `outcome-\u003Cn>` — unmapped or negative-verdict outcome bullet, or one whose row quotes\n  something other than the staged sanitized bullet\n- `fr-\u003CN>` — FR cited by no story, or only by a story that itself maps to no task\n- `story-\u003Cid>` — story cited by no task, or a story that does not tie out to the PRD\n  (cites an `FR-N` the PRD never declares, or cites no FR at all — §4e)\n- `task-\u003Cid>` — task with no valid story citation and no supporting-purpose exemption\n- `adr-\u003Cstem>` — non-deleted ADR file in the current spec change set cited by no story,\n  or only by a story that does not implement or honor the decision\n- `claim-\u003Crow>` — the plan's own `## Coverage Check` table cites a phantom id or\n  contradicts the parsed task tree (row number within that table)\n- `criterion:quote-not-done-when:\u003Cn>` — a criterion quote occurs in the cited\n  task body but not in any cited task's `Done when` block\n- `duplicate:\u003Cref>` — a second spec claiming an already-claimed `Source-Ref` (emitted\n  by the land-time duplicate-claim scan, not authored here — documented for vocabulary\n  completeness only)\n\nGap ids are opaque strings to downstream consumers (the validator, the waiver parser)\n— do not paraphrase or abbreviate them; use the exact forms above so cross-checking\nagainst the real artifact files (Section 5) is possible.\n\nBefore marking a criterion row `covered`, read every cited task's `Done when` block\nand verify that the quoted text comes from one of those checks.\n\nA **fail** row uses the same id form as its row class (`outcome-\u003Cn>`, `fr-\u003CN>`,\n`story-\u003Cid>`, `task-\u003Cid>`, `adr-\u003Cstem>`) — the id identifies *which* row, and the\nverdict says what is wrong with it. Name the supporting evidence in Notes so a reader can\nadjudicate without re-deriving the finding.\n\nUse `CANNOT-DELIVER:` for an achievability failure (§4g). Criterion rows have six required cells\nand no Notes cell; a `fail` row may add the optional seventh correction cell described in §4a.\nKeep the exact criterion text, task ids, verdict, verbatim `Done when` quote, and disposition\nintact. Put the explanation in a prose paragraph directly below the table, naming the criterion,\ncited task id, quoted check, and any binding ADR decision. Do not append commentary to the quote\nor create another table for these notes. This prefix is explanatory prose, not a verdict,\ndisposition, gap id, or correction-layer routing signal. Do not invent an achievability-specific\ngap-id form.\n\n### 4e. PRD ↔ Stories Tie-Out\n\nThe `fr` and `story` row classes are the two halves of one question: **do the PRD and the\nstories tie out?** Both directions must hold, and they fail differently:\n\n- **Forward (PRD → stories).** Every enumerated `FR-N` is cited by ≥1 story's\n  `**Requirement:**` line, and ≥1 of those stories is itself covered by a plan task. An FR\n  nothing implements is `gap` on its `fr` row (`fr-\u003CN>`).\n- **Reverse (stories → PRD).** Every story cites ≥1 `FR-N`, and every `FR-N` it cites is one\n  the PRD actually declares. A story citing `FR-9` when the PRD stops at `FR-4` is a phantom\n  requirement; a story citing no FR at all is untraced — it asserts behavior the product spec\n  never asked for. Either is `gap` on that story's `story` row (`story-\u003Cid>`).\n\nBoth directions are **enforced mechanically by the land-time gate** over parsed ids — it\nre-derives them from the real PRD and stories files regardless of what this artifact claims,\nand reports every offending id, not the first. Do not spend judgement re-deriving set\nmembership by hand: read the ids, record the rows, and let the gate be the authority on\ncoverage. Plan review at Medium and Large tier, and the plan's §7b at Small tier, own whether\ncross-layer artifacts conflict; this tie-out does not repeat that judgment.\n\n### 4f. Architecture-Decision ↔ Plan Tie-Out\n\nFor every citable decision in each non-deleted ADR in the current spec change set, independently judge\nthe plan's `## Architecture Obligation Coverage` row. A `task` disposition is `covered` only when the\ncited task's `Done when:` semantically asserts the decision—not merely because the task id and quoted\ntext exist. An `existing` disposition is covered only with verified implementation evidence; a\n`no-change` disposition is covered only when the decision genuinely imposes no implementation change on\nthis feature. If any decision mapping is semantically wrong, mark the parent `adr` row `fail` and identify\nthe decision id plus opposing evidence in Notes.\n\nThe land-time gate owns the mechanical checks: complete and unique decision ids, the closed disposition\nvocabulary, real task citations, and exact Done-when evidence. Do not duplicate those string\u002Fset checks.\nThis skill owns the judgement the engine cannot compute: whether that real evidence actually fulfills the\narchitecture obligation.\n\n### 4g. Achievability Pass\n\nFor every criterion row, ask: **given only what the cited task's `Done when` checks actually assert,\nand the approved architecture that constrains it, would satisfying them produce the criterion's\nThen-clause?** Related work and compatible wording do not establish delivery. When multiple tasks\nare cited, judge their checks together; do not require each task to deliver the whole criterion\nindependently, or assume an unstated connection between them.\n\nA task whose checks require only logging a warning, allowing an unsigned artifact through, is a\n§4g failure: all its checks can pass without rejection.\n\nA cited task that cannot deliver the criterion is **`fail`**, not `covered` or `gap`. The counterpart\nexists and coverage is satisfied; what is wrong is that its promised behavior does not work. Use the\nexisting verdict so the validator blocks it, and explain the failure with `CANNOT-DELIVER:` prose\nbelow the table per §4c.\n\nApply these detection heuristics:\n\n- **Mechanism-vs-restatement.** If the cited check merely paraphrases the Then-clause instead of\n  naming the code path, state change, or check that produces it, achievability is unestablished: the\n  task asserts the outcome without establishing how it delivers it. Surface this uncertainty per\n  §5 rather than crediting it. A named mechanism still needs to yield the criterion; its name alone\n  is not proof. Do not fill missing obligations from Steps prose or presumed BUILD work.\n- **Constraint sweep.** Re-read the criterion against each approved ADR in the current change set.\n  If the task could deliver it only by violating an approved decision, mark the criterion row `fail`.\n  The explanation must name the `adr-\u003Cstem>`, decision id, and binding decision text. Preserve §4f's\n  separate architecture-obligation judgement and its existing row pool.\n- **Representable outcomes.** When the approved design uses a closed set of states, result values,\n  or reasons, walk each required happy and negative scenario through the cited checks and identify\n  the legal value that represents its actual outcome. Include required absence, skip, and no-change\n  cases: reporting that an operation ran cannot deliver a criterion saying it did not run. A set\n  whose permitted values cannot express a required outcome is `fail`, even if the producer and\n  consumer agree on the same incomplete set. Quote the scenario and binding set; do not demand a\n  distinct value per scenario when an existing value represents it truthfully, or invent scenarios\n  outside the accepted criteria. Unspecified value meanings remain an assumption under §5.\n- **Input-boundary proof.** If checks operate on a prepared input, normalized status, or exported\n  subset, trace the required scenario to the check that produces that input from the actual source.\n  A helper that correctly handles `invalid` does not establish that malformed source data becomes\n  `invalid`; matching a registry to an exported subset does not establish that the subset includes\n  everything the criterion quantifies over. Identify the decoding\u002Fvalidation or enumeration boundary\n  and its owning task check. Consider required error exits too: a later reporter cannot supply a\n  promised result if the planned earlier refusal never reaches it. Credit existing evidence and\n  sibling tasks, and distinguish a demonstrated bypass (`fail`) from an unspecified connection (§5).\n\nGround each finding in the exact criterion and cited `Done when` text, with the binding ADR decision\nwhere applicable. \"This task feels thin\" is not a finding. If the artifacts do not settle\nachievability, surface the uncertainty as an assumption under §5: interactive runs wait for operator\nconfirmation; autonomous runs record `gap`. Never turn an unconfirmed assumption into a pass.\n\n## 5. Semantic-Judging Instructions (verify-claims protocol)\n\nPer `\u002Fverify-claims`, this skill is a **verifier\u002Fjudge** role: it renders a verdict\nper row and must never assert \"covered\" that it has not actually confirmed.\n\n- **Calibrate claims.** Before marking a row covered, `Read`\u002F`grep` the counterpart\n  artifact file and confirm the cited id is real and the coverage is genuine (not just\n  a plausible-sounding phrase match). Prefer the cheap read over an inferred guess\n  every time it would settle the question.\n- **Surface every assumption.** If a row's coverage is ambiguous (e.g. a story vaguely\n  gestures at an outcome without an explicit citation), do not silently resolve it in\n  either direction — surface it as an assumption with confidence, impact-if-wrong, and\n  how to confirm, per the repository's correctness and assumption gate.\n- **Hard-block on unconfirmed load-bearing assumptions.** A verdict on this artifact is\n  load-bearing — it gates land. Never mark a row \"covered\" on an unconfirmed\n  assumption about what a story or task \"probably\" means. Interactive runs: present\n  the ambiguous row and wait for operator confirmation before finalizing the artifact.\n  Autonomous\u002Fdaemon runs: mark the row `gap` and let the fail-closed land gate surface\n  it — never silently resolve ambiguity as a pass.\n- **Fabricated citations are never coverage.** A cited counterpart id that does not\n  exist in its source file is not \"covered with a typo\" — it is a gap, and the\n  land-time validator independently cross-checks every cited id against the real\n  artifact files regardless of what this skill wrote.\n\n## 6. Output\n\n1. Write `.docs\u002Fcoherence\u002F\u003Cplan-stem>.md` with the table(s) described in Section 4.\n2. Ensure the file renders as valid Markdown (a real table, not fenced prose) — it\n   must be readable directly in the spec PR diff (Story 2).\n3. Do not stage or commit a coherence artifact for a technical-track spec's `fr` row\n   class, a chat-origin spec's `outcome` row class, or an `adr` row class when the current\n   spec change set has no non-deleted `.docs\u002Fdecisions\u002Fadr-*.md` file — omission is\n   correct there, not a gap. A deleted ADR path still engages the ADR layer, but it does\n   not enter that row pool.\n\n## Verification\n\n- [ ] Tier read from `.docs\u002Fcomplexity\u002F`; skill does not run at all for tier S\n- [ ] Tier L dispatch is pinned to opus; tier M inherits the session\u002Fstep default\n- [ ] `.docs\u002Fcoherence\u002F\u003Cplan-stem>.md` filename stem matches the plan's filename stem exactly\n- [ ] All five row classes present where applicable (outcome\u002Ffr\u002Fadr omitted only when genuinely not required)\n- [ ] Every verdict is exactly `covered`, `gap`, or `fail` — no invented verdict strings\n      (legacy rows can silently pass them; criterion rows reject them as malformed)\n- [ ] §4e PRD↔stories tie-out checked in BOTH directions — no FR without a story, and no\n      story citing a phantom FR or citing no FR at all\n- [ ] §4f architecture-decision mappings judged semantically; every `task`, `existing`, or\n      `no-change` disposition actually satisfies its cited ADR decision\n- [ ] §4g achievability judged for every criterion from cited `Done when` checks and approved\n      architecture; mechanism-vs-restatement, ADR constraints, representable outcomes, and input boundaries checked\n- [ ] Established inability to deliver recorded as `fail`; unsettled achievability handled under §5\n- [ ] Each achievability failure has `CANNOT-DELIVER:` prose below the table naming the criterion,\n      task id, quoted check, and any binding ADR and decision id; six-cell rows and quotes stay intact\n- [ ] Story↔story pairs left to `\u002Fconflict-check`; plan review at Medium and Large tier and plan\n      §7b at Small tier own cross-layer and task-versus-task checks\n- [ ] Every `gap` row's Notes column restates its gap id in the canonical form (Section 4c)\n- [ ] Every `covered` verdict was confirmed against the real counterpart artifact file, not inferred\n- [ ] Ambiguous rows surfaced as assumptions (interactive: wait for confirmation; autonomous: mark `gap`, never silently pass)\n- [ ] Output renders as a valid Markdown table in the spec PR diff\n",{"name":5,"phase":39,"requires":48,"standalone":50,"description":7,"enforcement":24,"implicit_invocation":51},[49],"verify-claims",true,"required","main","136b34ec6792f53d0beba330dfa2dffad6c93484","skills\u002Fcoherence-check",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 08:28:50",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":50},[61,64,67],{"tool":62,"command":63},"npx","npx skills add jstoup111\u002Fai-conductor --skill coherence-check",{"tool":65,"command":66},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill coherence-check",{"tool":68,"command":69},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill coherence-check","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fcoherence-check\u002FSKILL.md",[],[73,91,129,146,165,177],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":43},"01M70YKSA2H7Q9WSRD1ECEGY20","build-review-dependency-hygiene","Judge whether a feature diff adds unnecessary, insufficiently pinned, or license-incompatible dependencies.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-review-dependency-hygiene\u002FSKILL.md",[],[80,81,82,83,84,85,86,87,88,89,29,90,24],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","dependencies","license","judge",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":110,"publishedAt":43},"01M6K3EQQ6ADH3G2RMYK6XE26E","writing-system-tests","Use BEFORE implementing any feature that has stories in .docs\u002Fstories\u002F — generates failing acceptance specs from acceptance criteria as the RED phase of TDD. Generates HTTP\u002Frequest-level acceptance tests for headless\u002FAPI projects, end-to-end UI tests for projects with a frontend, using the project's own test framework and directory conventions.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-system-tests\u002FSKILL.md",[97,102,105],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":103,"categoryName":104,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[111,112,113,114,115,116,117,118,119,120,121,122,28,123,124,125,126,24,127,128],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","api","directory","ui","framework","failing","phase","request",{"skillNo":130,"name":49,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":43},"01M6K3EHR0QQ1QY1S9RC6D1WTD","Use only when an active workflow is about to rely on a nontrivial factual claim or assumption for a spec, plan, ADR, finding, or code decision. Do not invoke for casual questions, status reports, restatements, or trivially verifiable mechanics.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fverify-claims\u002FSKILL.md",[],[135,28,42,34,136,27,137,138,29,139,36,38,140,141,142,41,22,30,143,144,23,24,145],"verify claims","adr","decision","claim","mechanics","workflow","code","reports","about","spec","when",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":43},"01M6K3ED4NF5DJA2Y35MH2JCRC","tdd","Use when implementing any feature or bugfix. Five-step cycle: RED → DOMAIN → GREEN → DOMAIN → COMMIT. Enforces test-first development with domain integrity review at every phase boundary.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[],[148,153,154,155,119,156,85,157,158,159,160,86,161,29,38,162,163,164,145,127],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":166,"name":25,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":43},"01M6K3E6PEXBXYY2K8TSRTN1JT","Use only within active engineer\u002Fconduct DECIDE after architecture approval, when a committed `.docs\u002Fstories` acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstories\u002FSKILL.md",[],[25,26,34,27,39,35,171,29,36,38,121,32,172,173,28,174,42,175,22,176,23,24,145],"general","architecture","examples","artifact","requests","implementation",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":43},"01M6K3E1HE7267YKFJQ3YFCGW5","stack-land","Use when an operator needs to land reviewed manual changes on the correct closed child of a stacked feature. Operator-invoked only: inspect ownership, propose the safe child with evidence, and require confirmation before opening the landing.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstack-land\u002FSKILL.md",[],[184,185,186,162,28,187,188,189,42,86,190,191,192,193,194,29,195,36,38,196,145,197],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation","advisory"]