[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K397Q1KSSRC6CFVCWDYJ8T":3,"skill-same:01M6K397Q1KSSRC6CFVCWDYJ8T":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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":65},"01M6K397Q1KSSRC6CFVCWDYJ8T","scope-check",null,"Use before authoring any change to the ai-conductor harness repository, and before creating any new skill, to decide three things deterministically: whether the change is harness-repo-only or consumer-facing, whether a new skill belongs in the shipped `skills\u002F` catalog or this repository's local `.agents\u002Fskills\u002F` catalog, and whether the change is provider-agnostic. Produces a placement verdict and the registration steps that verdict requires.","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\u002F.agents\u002Fskills\u002Fscope-check\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"check","scope","scope check","provider","new","things","true","verdict","conductor","authoring","local","three","registration","change","only","use","catalog","repo","decide","repository","harness","2026-11-10 10:12:30",false,"---\nname: scope-check\ndisable-model-invocation: true\ndescription: \"Use before authoring any change to the ai-conductor harness repository, and before creating any new skill, to decide three things deterministically: whether the change is harness-repo-only or consumer-facing, whether a new skill belongs in the shipped `skills\u002F` catalog or this repository's local `.agents\u002Fskills\u002F` catalog, and whether the change is provider-agnostic. Produces a placement verdict and the registration steps that verdict requires.\"\n---\n\n# Scope Check\n\nThree scope questions recur on every change to this repository, and each has a cheap wrong answer\nthat is expensive to unwind. Run the decision procedures below **before** authoring, not after.\n\nThis repository is the harness. It authors skills, agents, an engine (`src\u002Fconductor`), and\nbehavioral rules that get installed into *other* repositories — \"consumer repositories\" — which then\nuse the harness to build their own software. It also builds *itself* with itself (self-host). Those\ntwo audiences share a checkout, which is exactly why scope errors are easy to make here and nowhere\nelse.\n\nAnswer A, then B, then C. B is only reached when the change adds a skill. C applies to every change.\n\n---\n\n## 1. Decision A — harness-repo-only, or consumer-facing?\n\n**Question:** does this change serve *this repository's own construction*, or *every repository that\ninstalls the harness*?\n\n### Procedure\n\nWalk the signals in order. The first HALT wins; a signal that does not fire is not evidence for the\nother side.\n\n**Step 1 — repo-only signals.** Answer YES to any of these and the change is **harness-repo-only**:\n\n1. It touches self-host, daemon, or sandbox machinery — anything under\n   `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fself-host\u002F`, the live-boundary fingerprint, the isolated provider home,\n   or a code path gated behind `isSelfBuild()`. That gate is the canonical shape of a repo-only\n   feature: it is `daemon && selfHost`, so every other repository's bytes are unchanged.\n2. It touches this repository's own validation or release gates — `test\u002Ftest_harness_integrity.sh`,\n   `test\u002Flint_shell.sh`, `test\u002Ftest_provider_skill_contracts.sh`, `bin\u002Fgenerate-model-table`, the\n   release-gate classifier, `.docs\u002Frelease-waivers\u002F`.\n3. It touches this repository's own CI (`.github\u002Fworkflows\u002F`) or its `.ai-conductor\u002Fconfig.yml`\n   custom steps.\n4. It depends on a convention only this repository has — its `.docs\u002F` layout, its `[Unreleased]`\n   changelog gate, its `VERSION` file, its shipped-record ledger, its own branch policy.\n\n**Step 2 — consumer signals.** If no repo-only signal fired, answer this:\n\n> Would a repository that installed the harness, has **no** daemon, has **no** `.docs\u002F` history, and\n> has never run a self-host build still benefit from this change?\n\n- **YES** → **consumer-facing.**\n- **NO** → **harness-repo-only.**\n\nThis question is a general-benefit heuristic and over-generalizes a change whose subject is a\nmechanism that exists only here — ask first whether that mechanism exists outside this repository.\nSee the caveat under `AGENT_INSTRUCTIONS.md` → **Scope Decisions**: this skill's verdict is an input,\nnot the decision, and a conflict with the operator's plain request is surfaced before landing.\n\n**Step 3 — mixed changes are split, never averaged.** A change that fires both a repo-only signal\nand the consumer question is two changes. Land the consumer-facing behavior in the shared surface\nand the repo-only behavior in the repo-local surface, and say so in the diff. Do not ship a shared\nrule with a repo-only escape clause buried in it.\n\n### Where the artifact goes\n\n| Verdict | Rules go in | Docs go in | Skill catalog |\n| --- | --- | --- | --- |\n| Consumer-facing | `HARNESS.md` | `docs\u002F` (`reference\u002F`, `guides\u002F`, `explanation\u002F`, `runbooks\u002F`) | `skills\u002F` |\n| Harness-repo-only | `AGENT_INSTRUCTIONS.md` (the file `CLAUDE.md` and `AGENTS.md` both point at) | `docs\u002Fguides\u002Fself-hosting.md`, `docs\u002Fcontributing\u002F` | `.agents\u002Fskills\u002F` |\n\n`HARNESS.md` is the single source of truth for behavioral rules *consumed by* projects using the\nharness. `AGENT_INSTRUCTIONS.md` describes how *this* repository is built. A rule written into the\nwrong one is either invisible to consumers or imposed on them without cause.\n\n### Follow the existing precedent\n\nThis repository already states the boundary explicitly, in a fixed sentence shape, wherever a rule is\ndeliberately repo-only. The release-disposition rule in `AGENT_INSTRUCTIONS.md` uses:\n\n> \"For consumer projects without this custom-step configuration, the global harness … convention\n> remains unchanged.\"\n\nWhen Decision A returns **harness-repo-only** for a rule that *narrows or replaces* a shared\nconvention, write that sentence. It is the established contract, and omitting it is what makes a\nreader assume a repo-local rule is universal. When the repo-only rule is purely additive — a new\ngate consumers have no analogue for — no such sentence is needed, because there is no shared\nconvention being narrowed.\n\n### Cost of getting A wrong\n\n- **Repo-only shipped as consumer-facing.** Every consumer repository inherits machinery it has no\n  daemon, no `.docs\u002F` ledger, and no self-host build to satisfy. The failure is not loud — it is a\n  gate that can never pass in a repository that was never supposed to run it, and the operator there\n  has no context to diagnose why.\n- **Consumer-facing buried as repo-only.** A genuinely universal capability is trapped behind this\n  repository's private conventions. It never installs, never appears in the shipped catalog, and the\n  next author re-implements it — badly — because the existing one looked repo-specific.\n\n---\n\n## 2. Decision B — shipped `skills\u002F`, or local `.agents\u002Fskills\u002F`?\n\nReached only when the change adds a skill. There are exactly two catalogs.\n\n| | `skills\u002F\u003Cname>\u002FSKILL.md` | `.agents\u002Fskills\u002F\u003Cname>\u002FSKILL.md` |\n| --- | --- | --- |\n| Audience | every repository that installs the harness | this repository only |\n| Installed by | `bin\u002Finstall`, which auto-discovers every `skills\u002F\u003Cname>\u002F` containing a `SKILL.md` | nothing — never installed anywhere |\n| Discovery homes | both user-space catalogs: `~\u002F.claude\u002Fskills` and `~\u002F.agents\u002Fskills` | in-repo only: `.agents\u002Fskills\u002F` natively, plus a `.claude\u002Fskills\u002F\u003Cname>` symlink |\n| Current members | the shipped lifecycle catalog | every directory under `.agents\u002Fskills\u002F` |\n\n### Procedure\n\n1. **Would a consumer repository ever invoke it?** If NO → `.agents\u002Fskills\u002F`. Stop.\n2. **Does it encode conventions only this repository has** — its validation suite, its release gates,\n   its `.docs\u002F` layout, its self-host build, its own test-isolation policy? If YES → `.agents\u002Fskills\u002F`.\n   Stop.\n3. **Is it a lifecycle capability** — something that belongs to a phase of building software in *any*\n   repository (understand, decide, build, ship)? If YES → `skills\u002F`.\n4. **Still ambiguous?** Default to `.agents\u002Fskills\u002F`. Promoting a local skill to the shipped catalog\n   later is additive and reversible; demoting a shipped skill breaks every installation that already\n   symlinked it.\n\n### The registration asymmetry — why B is load-bearing\n\nThe two catalogs cost radically different amounts to join, because this repository's integrity suite\nglobs `skills\u002F*\u002FSKILL.md` and nothing else.\n\nA **`skills\u002F` addition** must satisfy all of:\n\n- Frontmatter with all four required fields — `name`, `description`, `enforcement`, `phase`\n  (integrity check 2).\n- A row in `ARCHITECTURE.md`'s model-selection table (check 5). That region is **generated**: its source\n  is `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fmodel-table-metadata.ts` plus the resolved config, rendered by\n  `bin\u002Fgenerate-model-table`. Hand-editing `ARCHITECTURE.md` fails check 5a's drift gate — the fix is to\n  update the metadata and regenerate.\n- Agreement between the model table's tier and the skill's own `model:` pin, in both directions\n  (check 5b).\n- Every `` `\u002Fskill-name` `` reference it makes must resolve to a real `skills\u002F` directory (check 4).\n- The provider contract audit in `test\u002Ftest_provider_skill_contracts.sh`, which is mechanically\n  hostile to Claude-only phrasing (see Decision C).\n- Automatic symlinking into both user-space catalogs on the next `bin\u002Finstall`, for every consumer.\n\nA **`.agents\u002Fskills\u002F` addition** requires none of the shipped catalog's model-table registration.\nIts frontmatter is deliberately minimal — `name`, `description`, and the Claude invocation-policy\nfield only; no `enforcement`, no `phase`, no `model` — and `docs\u002Freference\u002Fskills.md` states that\nexclusion in so many words. Integrity check 2a still includes the local catalog so invocation policy\ncannot drift between hosts.\n\nTwo consequences follow, and both matter:\n\n- The catalog choice is a real fork, not a filing preference. One path drags six gates and a global\n  install; the other drags none.\n- The local catalog remains outside the broader provider-language audit, so provider-agnosticism is\n  still a human obligation beyond the mechanically checked invocation policy. Decision C is therefore\n  *more* important for a local skill, not less.\n\n### What a local skill still owes\n\n1. `.agents\u002Fskills\u002F\u003Cname>\u002FSKILL.md` — frontmatter of `name`, `description`, and\n   `disable-model-invocation: true`; local skills are explicit-only by default.\n2. `.agents\u002Fskills\u002F\u003Cname>\u002Fagents\u002Fopenai.yaml` — the Codex-side interface block, matching the existing\n   local skills: `interface:` with `display_name`, `short_description`, and `default_prompt`, plus\n   `policy.allow_implicit_invocation: false` for parity with Claude.\n3. A symlink `.claude\u002Fskills\u002F\u003Cname> → ..\u002F..\u002F.agents\u002Fskills\u002F\u003Cname>`, committed as a git symlink (mode\n   `120000`), so the skill is discoverable from the other supported host too. This is the local\n   catalog's provider-parity mechanism — see Decision C.\n4. An entry in `docs\u002Freference\u002Fskills.md` under **Repository-local skills**, plus its two counts at\n   the top of that file.\n5. If it is wired as an engine step, a `steps:` entry in `.ai-conductor\u002Fconfig.yml` pointing at its\n   `.agents\u002Fskills\u002F\u003Cname>\u002FSKILL.md` path. Operator-invoked local skills need no wiring.\n\n### Worked example — this skill\n\n`scope-check` runs Decision B on itself.\n\n- Step 1: would a consumer repository ever invoke it? **No.** Its entire subject is the boundary\n  between this repository and its consumers, the two catalogs *this* repository maintains, and the\n  registration gates *this* repository enforces. A repository that merely installs the harness has\n  one catalog, no model-selection table to regenerate, and no consumer of its own.\n- Verdict: `.agents\u002Fskills\u002Fscope-check\u002FSKILL.md`.\n\nPlacing it in `skills\u002F` would ship a skill about this repository's private authoring decisions into\nevery consumer's user-space catalog, where its advice is not merely useless but actively wrong —\ntelling an operator to weigh a `HARNESS.md`-versus-`AGENT_INSTRUCTIONS.md` split that does not exist\nin their repository. That is precisely the error Decision A exists to prevent, committed by the\nartifact meant to prevent it. It is recorded here as the worked example on purpose.\n\n### Cost of getting B wrong\n\n- **Local skill filed as shipped.** It installs into every consumer's `~\u002F.claude\u002Fskills` and\n  `~\u002F.agents\u002Fskills` on their next update, where a host agent can match its `description` and invoke\n  it against a repository whose layout it describes incorrectly. Removing it later is a breaking\n  change to installed state, not a revert.\n- **Shipped skill filed as local.** It never installs anywhere. No consumer can reach it, it gets no\n  model-table row, no `enforcement`\u002F`phase` declaration, and no provider audit — so it silently\n  accumulates provider-specific assumptions until promotion becomes a rewrite.\n\n---\n\n## 3. Decision C — is it provider-agnostic?\n\nEvery supported host must be able to do the thing. Nothing may work only on Claude or only on Codex.\n\n### Procedure\n\nAnswer each. Any YES in steps 1–3 requires the remedy in step 4 before the change lands.\n\n1. **Does it name a provider-specific path, environment variable, config file, or CLI flag?**\n   Examples that are provider-specific: `~\u002F.claude\u002Fskills`, `~\u002F.agents\u002Fskills`, `CLAUDE_CONFIG_DIR`,\n   `CODEX_HOME`, `.claude\u002Fsettings.local.json`, `.claude\u002Fskills\u002F`. Naming one is allowed; *relying*\n   on one without its counterpart is not.\n2. **Does it rely on a capability only one provider has?** Interactive slash commands, a specific\n   one host's subagent facility, a model-selection parameter, a settings key one host reads and the\n   other ignores.\n3. **Is there an equivalent seam on the other side?** If a seam exists, use both. If no seam exists,\n   the capability is genuinely unsupported on that host and must fail closed with a diagnostic that\n   names the selected provider and a recovery action — `HARNESS.md`'s unsupported-capability contract,\n   which `test\u002Ftest_provider_skill_contracts.sh` asserts. It must not silently degrade.\n4. **Remedy — scope, don't remove.** Provider mechanics stay; they get an explicit owner on the same\n   line. The house pattern, which the audit's own fixtures encode:\n\n   > Claude Code invokes `conduct` as `\u002Fconduct`; Codex invokes it as `$conduct`.\n\n   > Claude Code uses its Agent tool with a model parameter; other hosts use the selected host's\n   > available subagent facility.\n\n   The shared outcome and the shared gate are stated once, provider-neutrally, and only the\n   invocation mechanics fork.\n\n### What is already mechanized — point at it, do not restate it\n\n- `test\u002Ftest_provider_skill_contracts.sh` runs in the integrity suite. It does two things: it\n  pins required provider-neutral language in `HARNESS.md` and in the shipped skills, and it runs a\n  deterministic audit that rejects the specific ways an instruction accidentally becomes Claude-only\n  — an unscoped imperative slash command, an unscoped reference to Claude Code's Agent tool, an\n  unscoped model\n  parameter, unscoped Claude-subagent delegation, an unscoped interactive slash command. It also\n  carries fixtures proving each category fails for the right reason. Read it before writing new\n  prose about provider neutrality; it is the specification.\n- **Root instruction parity is structural, not editorial.** `CLAUDE.md` and `AGENTS.md` are both\n  symlinks to `AGENT_INSTRUCTIONS.md`, and integrity check 15 asserts exactly that. Claude reads\n  `CLAUDE.md`, Codex reads `AGENTS.md`; because both resolve to one file, a change to this\n  repository's agent instructions reaches both hosts by construction. **Never break that by\n  converting either into a regular file to hold host-specific text** — that is what makes them drift,\n  and it is the failure check 15 exists to catch. Host-specific guidance goes *inside* the shared\n  file, scoped on the line.\n- **The local catalog's parity mechanism is the symlink pair.** `.agents\u002Fskills\u002F` is already Codex's\n  native project-local location; the committed `.claude\u002Fskills\u002F\u003Cname>` symlink makes the identical\n  file reachable from Claude. One file, two discovery paths — the same construction as the root\n  instructions. A local skill that exists in only one of the two is reachable by only one host.\n  `test\u002Fcheck_local_skill_host_wiring.sh` (integrity check 2b) rejects a local skill without a\n  resolving `.claude\u002Fskills\u002F\u003Cname>` symlink and an orphaned `.claude\u002Fskills` entry;\n  `test\u002Fcheck_skill_invocation_policy.sh` (integrity check 2a) rejects a local skill without its\n  `agents\u002Fopenai.yaml` policy.\n\n### Real asymmetries this decision must catch\n\nThese are live in this repository. They are the shape of the trap, not hypotheticals.\n\n- **Discovery and invocation are separate host seams.** `bin\u002Finstall` enumerates `skills\u002F*\u002F`\n  containing a `SKILL.md` and symlinks the identical set into `~\u002F.claude\u002Fskills` and\n  `~\u002F.agents\u002Fskills`; it has no per-provider catalog filter. Invocation control is paired instead:\n  Claude reads `disable-model-invocation: true` from `SKILL.md`, while Codex reads\n  `policy.allow_implicit_invocation: false` from `agents\u002Fopenai.yaml`. Adding only one side recreates\n  the exact provider-parity failure Decision C exists to prevent. Engine-rendered `\u002Fskill` or `$skill`\n  prompts remain explicit and continue to work.\n- **`.claude\u002Fsettings.local.json` has no Codex counterpart.** That file carries a `permissions.allow[]`\n  array that Claude reads and Codex does not. Anything whose behavior depends on it — an allowed\n  command, a suppressed prompt — is Claude-only by construction, and will appear to work because the\n  operator tested it on Claude. Behavior that both hosts must share cannot live in one host's\n  settings file.\n- **The isolated provider home — a correct seam, and a real provider difference inside it.**\n  `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fself-host\u002Fprovider-home.ts` provisions a throwaway home and sets\n  `CLAUDE_CONFIG_DIR` for Claude or `CODEX_HOME` for Codex from a single `HOME_VARIABLE` map. That is\n  the shape to imitate: one seam, both sides named, and gated behind `isSelfBuild()` — literally\n  `daemon && selfHost` in `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fconductor.ts` — so every other repository's build\n  path is byte-for-byte unchanged. Note what the file had to absorb to stay symmetric: it **copies**\n  `skills\u002F` rather than symlinking it, because Codex's skill discovery writes `.system\u002F` bookkeeping\n  back through a live link into the git-tracked worktree; and it creates a Codex-only\n  `\u003Chome>\u002F.agents\u002Fskills → \u003Chome>\u002Fskills` link, because Codex discovers by that directory name while\n  Claude reads its config dir. Claude's parallel path is a different file entirely\n  (`self-host\u002Fsandbox-build-env.ts`, which symlinks). Same outcome, two mechanisms, both explicit —\n  that is what \"provider-agnostic\" means in practice. It does not mean identical code.\n- **Ambient credentials are not symmetric.** The same provisioning path deletes\n  `CLAUDE_CODE_OAUTH_TOKEN` from the child environment. It is a Claude-side variable with no Codex\n  equivalent; assuming a token variable exists on both sides is the same class of error in reverse.\n- **`~\u002F.codex\u002Fskills` is a legacy Codex location; `~\u002F.agents\u002Fskills` is the active one.** Installation\n  cleans up the former. A change that writes only one of the two user-space catalogs halves the\n  corpus for one host, and duplicate discovery across the legacy and active Codex directories is an\n  install failure, not a warning.\n\n### Cost of getting C wrong\n\nThe change works — for the operator who wrote it, on the provider they happened to be running. It\nfails for the other host at a time and place with no connection to the commit that caused it: a skill\nthat never triggers, an override that never applies, a catalog that is half-populated. Provider\nasymmetry does not produce errors; it produces absence, which is far harder to trace.\n\n---\n\n## 4. Output\n\nEmit the three verdicts explicitly before authoring, and carry them into the change description:\n\n```\nScope check\n  A. Audience:  harness-repo-only | consumer-facing   — \u003Cthe signal that decided it>\n  B. Catalog:   skills\u002F | .agents\u002Fskills\u002F | n\u002Fa       — \u003Cthe step that decided it>\n  C. Provider:  agnostic | scoped-with-both-seams | unsupported-and-fails-closed\n  Registration: \u003Cthe list this verdict requires, from §1 and §2>\n```\n\nIf A and B disagree — a consumer-facing rule paired with a local skill, or vice versa — that is not\na nuance to reconcile in prose. Re-run A; one of the two answers is wrong.\n\n---\n\n## Verification\n\n- [ ] Decision A run, with the specific signal that decided it named — not \"feels repo-specific\"\n- [ ] Rules landed in `HARNESS.md` (consumer-facing) or `AGENT_INSTRUCTIONS.md` (repo-only), never both by copy\n- [ ] A repo-only rule that narrows a shared convention carries the established\n      \"For consumer projects … remains unchanged\" sentence\n- [ ] Mixed-scope change split into its consumer-facing and repo-only halves, not averaged into one rule\n- [ ] Decision B run for every new skill, with its deciding step named\n- [ ] A `skills\u002F` addition declares `name`, `description`, `enforcement`, `phase`\n- [ ] A `skills\u002F` addition is registered via `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fmodel-table-metadata.ts` and\n      `bin\u002Fgenerate-model-table` — `ARCHITECTURE.md`'s generated table is **not** hand-edited\n- [ ] A `.agents\u002Fskills\u002F` addition declares `name`, `description`, and\n      `disable-model-invocation: true`, and adds no other fields the local catalog does not use\n- [ ] A `.agents\u002Fskills\u002F` addition ships its `agents\u002Fopenai.yaml` interface block with\n      `policy.allow_implicit_invocation: false` and a committed\n      `.claude\u002Fskills\u002F\u003Cname>` symlink (git mode `120000`)\n- [ ] Decision C run; every provider-specific path, variable, or capability either has its\n      counterpart or is scoped to its host on the same line\n- [ ] `CLAUDE.md` and `AGENTS.md` remain symlinks to `AGENT_INSTRUCTIONS.md` — no host-specific text\n      was added by splitting them\n- [ ] `docs\u002Freference\u002Fskills.md` updated: the new skill's entry and the counts at the top of the file\n- [ ] Documentation upkeep satisfied per this repository's rule — the canonical affected page updated\n      in the same change\n- [ ] Changelog decision made deliberately: an entry under `[Unreleased]` only for a notable\n      reader-visible implementation change\n- [ ] `test\u002Ftest_harness_integrity.sh` passes, including check 5a (model-table drift), check 15\n      (root instruction parity), and the provider skill contract suite\n","# Scope Check\n\nThree scope questions recur on every change to this repository, and each has a cheap wrong answer\nthat is expensive to unwind. Run the decision procedures below **before** authoring, not after.\n\nThis repository is the harness. It authors skills, agents, an engine (`src\u002Fconductor`), and\nbehavioral rules that get installed into *other* repositories — \"consumer repositories\" — which then\nuse the harness to build their own software. It also builds *itself* with itself (self-host). Those\ntwo audiences share a checkout, which is exactly why scope errors are easy to make here and nowhere\nelse.\n\nAnswer A, then B, then C. B is only reached when the change adds a skill. C applies to every change.\n\n---\n\n## 1. Decision A — harness-repo-only, or consumer-facing?\n\n**Question:** does this change serve *this repository's own construction*, or *every repository that\ninstalls the harness*?\n\n### Procedure\n\nWalk the signals in order. The first HALT wins; a signal that does not fire is not evidence for the\nother side.\n\n**Step 1 — repo-only signals.** Answer YES to any of these and the change is **harness-repo-only**:\n\n1. It touches self-host, daemon, or sandbox machinery — anything under\n   `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fself-host\u002F`, the live-boundary fingerprint, the isolated provider home,\n   or a code path gated behind `isSelfBuild()`. That gate is the canonical shape of a repo-only\n   feature: it is `daemon && selfHost`, so every other repository's bytes are unchanged.\n2. It touches this repository's own validation or release gates — `test\u002Ftest_harness_integrity.sh`,\n   `test\u002Flint_shell.sh`, `test\u002Ftest_provider_skill_contracts.sh`, `bin\u002Fgenerate-model-table`, the\n   release-gate classifier, `.docs\u002Frelease-waivers\u002F`.\n3. It touches this repository's own CI (`.github\u002Fworkflows\u002F`) or its `.ai-conductor\u002Fconfig.yml`\n   custom steps.\n4. It depends on a convention only this repository has — its `.docs\u002F` layout, its `[Unreleased]`\n   changelog gate, its `VERSION` file, its shipped-record ledger, its own branch policy.\n\n**Step 2 — consumer signals.** If no repo-only signal fired, answer this:\n\n> Would a repository that installed the harness, has **no** daemon, has **no** `.docs\u002F` history, and\n> has never run a self-host build still benefit from this change?\n\n- **YES** → **consumer-facing.**\n- **NO** → **harness-repo-only.**\n\nThis question is a general-benefit heuristic and over-generalizes a change whose subject is a\nmechanism that exists only here — ask first whether that mechanism exists outside this repository.\nSee the caveat under `AGENT_INSTRUCTIONS.md` → **Scope Decisions**: this skill's verdict is an input,\nnot the decision, and a conflict with the operator's plain request is surfaced before landing.\n\n**Step 3 — mixed changes are split, never averaged.** A change that fires both a repo-only signal\nand the consumer question is two changes. Land the consumer-facing behavior in the shared surface\nand the repo-only behavior in the repo-local surface, and say so in the diff. Do not ship a shared\nrule with a repo-only escape clause buried in it.\n\n### Where the artifact goes\n\n| Verdict | Rules go in | Docs go in | Skill catalog |\n| --- | --- | --- | --- |\n| Consumer-facing | `HARNESS.md` | `docs\u002F` (`reference\u002F`, `guides\u002F`, `explanation\u002F`, `runbooks\u002F`) | `skills\u002F` |\n| Harness-repo-only | `AGENT_INSTRUCTIONS.md` (the file `CLAUDE.md` and `AGENTS.md` both point at) | `docs\u002Fguides\u002Fself-hosting.md`, `docs\u002Fcontributing\u002F` | `.agents\u002Fskills\u002F` |\n\n`HARNESS.md` is the single source of truth for behavioral rules *consumed by* projects using the\nharness. `AGENT_INSTRUCTIONS.md` describes how *this* repository is built. A rule written into the\nwrong one is either invisible to consumers or imposed on them without cause.\n\n### Follow the existing precedent\n\nThis repository already states the boundary explicitly, in a fixed sentence shape, wherever a rule is\ndeliberately repo-only. The release-disposition rule in `AGENT_INSTRUCTIONS.md` uses:\n\n> \"For consumer projects without this custom-step configuration, the global harness … convention\n> remains unchanged.\"\n\nWhen Decision A returns **harness-repo-only** for a rule that *narrows or replaces* a shared\nconvention, write that sentence. It is the established contract, and omitting it is what makes a\nreader assume a repo-local rule is universal. When the repo-only rule is purely additive — a new\ngate consumers have no analogue for — no such sentence is needed, because there is no shared\nconvention being narrowed.\n\n### Cost of getting A wrong\n\n- **Repo-only shipped as consumer-facing.** Every consumer repository inherits machinery it has no\n  daemon, no `.docs\u002F` ledger, and no self-host build to satisfy. The failure is not loud — it is a\n  gate that can never pass in a repository that was never supposed to run it, and the operator there\n  has no context to diagnose why.\n- **Consumer-facing buried as repo-only.** A genuinely universal capability is trapped behind this\n  repository's private conventions. It never installs, never appears in the shipped catalog, and the\n  next author re-implements it — badly — because the existing one looked repo-specific.\n\n---\n\n## 2. Decision B — shipped `skills\u002F`, or local `.agents\u002Fskills\u002F`?\n\nReached only when the change adds a skill. There are exactly two catalogs.\n\n| | `skills\u002F\u003Cname>\u002FSKILL.md` | `.agents\u002Fskills\u002F\u003Cname>\u002FSKILL.md` |\n| --- | --- | --- |\n| Audience | every repository that installs the harness | this repository only |\n| Installed by | `bin\u002Finstall`, which auto-discovers every `skills\u002F\u003Cname>\u002F` containing a `SKILL.md` | nothing — never installed anywhere |\n| Discovery homes | both user-space catalogs: `~\u002F.claude\u002Fskills` and `~\u002F.agents\u002Fskills` | in-repo only: `.agents\u002Fskills\u002F` natively, plus a `.claude\u002Fskills\u002F\u003Cname>` symlink |\n| Current members | the shipped lifecycle catalog | every directory under `.agents\u002Fskills\u002F` |\n\n### Procedure\n\n1. **Would a consumer repository ever invoke it?** If NO → `.agents\u002Fskills\u002F`. Stop.\n2. **Does it encode conventions only this repository has** — its validation suite, its release gates,\n   its `.docs\u002F` layout, its self-host build, its own test-isolation policy? If YES → `.agents\u002Fskills\u002F`.\n   Stop.\n3. **Is it a lifecycle capability** — something that belongs to a phase of building software in *any*\n   repository (understand, decide, build, ship)? If YES → `skills\u002F`.\n4. **Still ambiguous?** Default to `.agents\u002Fskills\u002F`. Promoting a local skill to the shipped catalog\n   later is additive and reversible; demoting a shipped skill breaks every installation that already\n   symlinked it.\n\n### The registration asymmetry — why B is load-bearing\n\nThe two catalogs cost radically different amounts to join, because this repository's integrity suite\nglobs `skills\u002F*\u002FSKILL.md` and nothing else.\n\nA **`skills\u002F` addition** must satisfy all of:\n\n- Frontmatter with all four required fields — `name`, `description`, `enforcement`, `phase`\n  (integrity check 2).\n- A row in `ARCHITECTURE.md`'s model-selection table (check 5). That region is **generated**: its source\n  is `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fmodel-table-metadata.ts` plus the resolved config, rendered by\n  `bin\u002Fgenerate-model-table`. Hand-editing `ARCHITECTURE.md` fails check 5a's drift gate — the fix is to\n  update the metadata and regenerate.\n- Agreement between the model table's tier and the skill's own `model:` pin, in both directions\n  (check 5b).\n- Every `` `\u002Fskill-name` `` reference it makes must resolve to a real `skills\u002F` directory (check 4).\n- The provider contract audit in `test\u002Ftest_provider_skill_contracts.sh`, which is mechanically\n  hostile to Claude-only phrasing (see Decision C).\n- Automatic symlinking into both user-space catalogs on the next `bin\u002Finstall`, for every consumer.\n\nA **`.agents\u002Fskills\u002F` addition** requires none of the shipped catalog's model-table registration.\nIts frontmatter is deliberately minimal — `name`, `description`, and the Claude invocation-policy\nfield only; no `enforcement`, no `phase`, no `model` — and `docs\u002Freference\u002Fskills.md` states that\nexclusion in so many words. Integrity check 2a still includes the local catalog so invocation policy\ncannot drift between hosts.\n\nTwo consequences follow, and both matter:\n\n- The catalog choice is a real fork, not a filing preference. One path drags six gates and a global\n  install; the other drags none.\n- The local catalog remains outside the broader provider-language audit, so provider-agnosticism is\n  still a human obligation beyond the mechanically checked invocation policy. Decision C is therefore\n  *more* important for a local skill, not less.\n\n### What a local skill still owes\n\n1. `.agents\u002Fskills\u002F\u003Cname>\u002FSKILL.md` — frontmatter of `name`, `description`, and\n   `disable-model-invocation: true`; local skills are explicit-only by default.\n2. `.agents\u002Fskills\u002F\u003Cname>\u002Fagents\u002Fopenai.yaml` — the Codex-side interface block, matching the existing\n   local skills: `interface:` with `display_name`, `short_description`, and `default_prompt`, plus\n   `policy.allow_implicit_invocation: false` for parity with Claude.\n3. A symlink `.claude\u002Fskills\u002F\u003Cname> → ..\u002F..\u002F.agents\u002Fskills\u002F\u003Cname>`, committed as a git symlink (mode\n   `120000`), so the skill is discoverable from the other supported host too. This is the local\n   catalog's provider-parity mechanism — see Decision C.\n4. An entry in `docs\u002Freference\u002Fskills.md` under **Repository-local skills**, plus its two counts at\n   the top of that file.\n5. If it is wired as an engine step, a `steps:` entry in `.ai-conductor\u002Fconfig.yml` pointing at its\n   `.agents\u002Fskills\u002F\u003Cname>\u002FSKILL.md` path. Operator-invoked local skills need no wiring.\n\n### Worked example — this skill\n\n`scope-check` runs Decision B on itself.\n\n- Step 1: would a consumer repository ever invoke it? **No.** Its entire subject is the boundary\n  between this repository and its consumers, the two catalogs *this* repository maintains, and the\n  registration gates *this* repository enforces. A repository that merely installs the harness has\n  one catalog, no model-selection table to regenerate, and no consumer of its own.\n- Verdict: `.agents\u002Fskills\u002Fscope-check\u002FSKILL.md`.\n\nPlacing it in `skills\u002F` would ship a skill about this repository's private authoring decisions into\nevery consumer's user-space catalog, where its advice is not merely useless but actively wrong —\ntelling an operator to weigh a `HARNESS.md`-versus-`AGENT_INSTRUCTIONS.md` split that does not exist\nin their repository. That is precisely the error Decision A exists to prevent, committed by the\nartifact meant to prevent it. It is recorded here as the worked example on purpose.\n\n### Cost of getting B wrong\n\n- **Local skill filed as shipped.** It installs into every consumer's `~\u002F.claude\u002Fskills` and\n  `~\u002F.agents\u002Fskills` on their next update, where a host agent can match its `description` and invoke\n  it against a repository whose layout it describes incorrectly. Removing it later is a breaking\n  change to installed state, not a revert.\n- **Shipped skill filed as local.** It never installs anywhere. No consumer can reach it, it gets no\n  model-table row, no `enforcement`\u002F`phase` declaration, and no provider audit — so it silently\n  accumulates provider-specific assumptions until promotion becomes a rewrite.\n\n---\n\n## 3. Decision C — is it provider-agnostic?\n\nEvery supported host must be able to do the thing. Nothing may work only on Claude or only on Codex.\n\n### Procedure\n\nAnswer each. Any YES in steps 1–3 requires the remedy in step 4 before the change lands.\n\n1. **Does it name a provider-specific path, environment variable, config file, or CLI flag?**\n   Examples that are provider-specific: `~\u002F.claude\u002Fskills`, `~\u002F.agents\u002Fskills`, `CLAUDE_CONFIG_DIR`,\n   `CODEX_HOME`, `.claude\u002Fsettings.local.json`, `.claude\u002Fskills\u002F`. Naming one is allowed; *relying*\n   on one without its counterpart is not.\n2. **Does it rely on a capability only one provider has?** Interactive slash commands, a specific\n   one host's subagent facility, a model-selection parameter, a settings key one host reads and the\n   other ignores.\n3. **Is there an equivalent seam on the other side?** If a seam exists, use both. If no seam exists,\n   the capability is genuinely unsupported on that host and must fail closed with a diagnostic that\n   names the selected provider and a recovery action — `HARNESS.md`'s unsupported-capability contract,\n   which `test\u002Ftest_provider_skill_contracts.sh` asserts. It must not silently degrade.\n4. **Remedy — scope, don't remove.** Provider mechanics stay; they get an explicit owner on the same\n   line. The house pattern, which the audit's own fixtures encode:\n\n   > Claude Code invokes `conduct` as `\u002Fconduct`; Codex invokes it as `$conduct`.\n\n   > Claude Code uses its Agent tool with a model parameter; other hosts use the selected host's\n   > available subagent facility.\n\n   The shared outcome and the shared gate are stated once, provider-neutrally, and only the\n   invocation mechanics fork.\n\n### What is already mechanized — point at it, do not restate it\n\n- `test\u002Ftest_provider_skill_contracts.sh` runs in the integrity suite. It does two things: it\n  pins required provider-neutral language in `HARNESS.md` and in the shipped skills, and it runs a\n  deterministic audit that rejects the specific ways an instruction accidentally becomes Claude-only\n  — an unscoped imperative slash command, an unscoped reference to Claude Code's Agent tool, an\n  unscoped model\n  parameter, unscoped Claude-subagent delegation, an unscoped interactive slash command. It also\n  carries fixtures proving each category fails for the right reason. Read it before writing new\n  prose about provider neutrality; it is the specification.\n- **Root instruction parity is structural, not editorial.** `CLAUDE.md` and `AGENTS.md` are both\n  symlinks to `AGENT_INSTRUCTIONS.md`, and integrity check 15 asserts exactly that. Claude reads\n  `CLAUDE.md`, Codex reads `AGENTS.md`; because both resolve to one file, a change to this\n  repository's agent instructions reaches both hosts by construction. **Never break that by\n  converting either into a regular file to hold host-specific text** — that is what makes them drift,\n  and it is the failure check 15 exists to catch. Host-specific guidance goes *inside* the shared\n  file, scoped on the line.\n- **The local catalog's parity mechanism is the symlink pair.** `.agents\u002Fskills\u002F` is already Codex's\n  native project-local location; the committed `.claude\u002Fskills\u002F\u003Cname>` symlink makes the identical\n  file reachable from Claude. One file, two discovery paths — the same construction as the root\n  instructions. A local skill that exists in only one of the two is reachable by only one host.\n  `test\u002Fcheck_local_skill_host_wiring.sh` (integrity check 2b) rejects a local skill without a\n  resolving `.claude\u002Fskills\u002F\u003Cname>` symlink and an orphaned `.claude\u002Fskills` entry;\n  `test\u002Fcheck_skill_invocation_policy.sh` (integrity check 2a) rejects a local skill without its\n  `agents\u002Fopenai.yaml` policy.\n\n### Real asymmetries this decision must catch\n\nThese are live in this repository. They are the shape of the trap, not hypotheticals.\n\n- **Discovery and invocation are separate host seams.** `bin\u002Finstall` enumerates `skills\u002F*\u002F`\n  containing a `SKILL.md` and symlinks the identical set into `~\u002F.claude\u002Fskills` and\n  `~\u002F.agents\u002Fskills`; it has no per-provider catalog filter. Invocation control is paired instead:\n  Claude reads `disable-model-invocation: true` from `SKILL.md`, while Codex reads\n  `policy.allow_implicit_invocation: false` from `agents\u002Fopenai.yaml`. Adding only one side recreates\n  the exact provider-parity failure Decision C exists to prevent. Engine-rendered `\u002Fskill` or `$skill`\n  prompts remain explicit and continue to work.\n- **`.claude\u002Fsettings.local.json` has no Codex counterpart.** That file carries a `permissions.allow[]`\n  array that Claude reads and Codex does not. Anything whose behavior depends on it — an allowed\n  command, a suppressed prompt — is Claude-only by construction, and will appear to work because the\n  operator tested it on Claude. Behavior that both hosts must share cannot live in one host's\n  settings file.\n- **The isolated provider home — a correct seam, and a real provider difference inside it.**\n  `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fself-host\u002Fprovider-home.ts` provisions a throwaway home and sets\n  `CLAUDE_CONFIG_DIR` for Claude or `CODEX_HOME` for Codex from a single `HOME_VARIABLE` map. That is\n  the shape to imitate: one seam, both sides named, and gated behind `isSelfBuild()` — literally\n  `daemon && selfHost` in `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fconductor.ts` — so every other repository's build\n  path is byte-for-byte unchanged. Note what the file had to absorb to stay symmetric: it **copies**\n  `skills\u002F` rather than symlinking it, because Codex's skill discovery writes `.system\u002F` bookkeeping\n  back through a live link into the git-tracked worktree; and it creates a Codex-only\n  `\u003Chome>\u002F.agents\u002Fskills → \u003Chome>\u002Fskills` link, because Codex discovers by that directory name while\n  Claude reads its config dir. Claude's parallel path is a different file entirely\n  (`self-host\u002Fsandbox-build-env.ts`, which symlinks). Same outcome, two mechanisms, both explicit —\n  that is what \"provider-agnostic\" means in practice. It does not mean identical code.\n- **Ambient credentials are not symmetric.** The same provisioning path deletes\n  `CLAUDE_CODE_OAUTH_TOKEN` from the child environment. It is a Claude-side variable with no Codex\n  equivalent; assuming a token variable exists on both sides is the same class of error in reverse.\n- **`~\u002F.codex\u002Fskills` is a legacy Codex location; `~\u002F.agents\u002Fskills` is the active one.** Installation\n  cleans up the former. A change that writes only one of the two user-space catalogs halves the\n  corpus for one host, and duplicate discovery across the legacy and active Codex directories is an\n  install failure, not a warning.\n\n### Cost of getting C wrong\n\nThe change works — for the operator who wrote it, on the provider they happened to be running. It\nfails for the other host at a time and place with no connection to the commit that caused it: a skill\nthat never triggers, an override that never applies, a catalog that is half-populated. Provider\nasymmetry does not produce errors; it produces absence, which is far harder to trace.\n\n---\n\n## 4. Output\n\nEmit the three verdicts explicitly before authoring, and carry them into the change description:\n\n```\nScope check\n  A. Audience:  harness-repo-only | consumer-facing   — \u003Cthe signal that decided it>\n  B. Catalog:   skills\u002F | .agents\u002Fskills\u002F | n\u002Fa       — \u003Cthe step that decided it>\n  C. Provider:  agnostic | scoped-with-both-seams | unsupported-and-fails-closed\n  Registration: \u003Cthe list this verdict requires, from §1 and §2>\n```\n\nIf A and B disagree — a consumer-facing rule paired with a local skill, or vice versa — that is not\na nuance to reconcile in prose. Re-run A; one of the two answers is wrong.\n\n---\n\n## Verification\n\n- [ ] Decision A run, with the specific signal that decided it named — not \"feels repo-specific\"\n- [ ] Rules landed in `HARNESS.md` (consumer-facing) or `AGENT_INSTRUCTIONS.md` (repo-only), never both by copy\n- [ ] A repo-only rule that narrows a shared convention carries the established\n      \"For consumer projects … remains unchanged\" sentence\n- [ ] Mixed-scope change split into its consumer-facing and repo-only halves, not averaged into one rule\n- [ ] Decision B run for every new skill, with its deciding step named\n- [ ] A `skills\u002F` addition declares `name`, `description`, `enforcement`, `phase`\n- [ ] A `skills\u002F` addition is registered via `src\u002Fconductor\u002Fsrc\u002Fengine\u002Fmodel-table-metadata.ts` and\n      `bin\u002Fgenerate-model-table` — `ARCHITECTURE.md`'s generated table is **not** hand-edited\n- [ ] A `.agents\u002Fskills\u002F` addition declares `name`, `description`, and\n      `disable-model-invocation: true`, and adds no other fields the local catalog does not use\n- [ ] A `.agents\u002Fskills\u002F` addition ships its `agents\u002Fopenai.yaml` interface block with\n      `policy.allow_implicit_invocation: false` and a committed\n      `.claude\u002Fskills\u002F\u003Cname>` symlink (git mode `120000`)\n- [ ] Decision C run; every provider-specific path, variable, or capability either has its\n      counterpart or is scoped to its host on the same line\n- [ ] `CLAUDE.md` and `AGENTS.md` remain symlinks to `AGENT_INSTRUCTIONS.md` — no host-specific text\n      was added by splitting them\n- [ ] `docs\u002Freference\u002Fskills.md` updated: the new skill's entry and the counts at the top of the file\n- [ ] Documentation upkeep satisfied per this repository's rule — the canonical affected page updated\n      in the same change\n- [ ] Changelog decision made deliberately: an entry under `[Unreleased]` only for a notable\n      reader-visible implementation change\n- [ ] `test\u002Ftest_harness_integrity.sh` passes, including check 5a (model-table drift), check 15\n      (root instruction parity), and the provider skill contract suite\n",{"name":5,"description":7,"disable-model-invocation":45},true,"main","136b34ec6792f53d0beba330dfa2dffad6c93484",".agents\u002Fskills\u002Fscope-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":54,"prompt":64,"zipAvailable":45},[55,58,61],{"tool":56,"command":57},"npx","npx skills add jstoup111\u002Fai-conductor --skill scope-check",{"tool":59,"command":60},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill scope-check",{"tool":62,"command":63},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill scope-check","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscope-check\u002FSKILL.md",[66],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"agents\u002Fopenai.yaml","REFERENCE","参考文档",358,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscope-check\u002Fagents\u002Fopenai.yaml",[73,92,131,156,175,191],{"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":40},"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,25,90,91],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","dependencies","license","judge","gating",{"skillNo":93,"name":94,"nameZh":6,"description":95,"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":111,"publishedAt":40},"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",[98,103,106],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":104,"categoryName":105,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,91,129,130],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","api","claims","directory","ui","framework","failing","phase","request",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":40},"01M6K3EHR0QQ1QY1S9RC6D1WTD","verify-claims","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",[],[138,124,139,140,141,142,143,144,25,145,33,34,146,147,148,149,150,151,152,153,154,91,155],"verify claims","verify","do","adr","for","decision","claim","mechanics","workflow","code","reports","plan","active","questions","about","spec","invoke","when",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":40},"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",[],[158,163,164,165,120,166,85,167,168,169,170,86,171,25,34,172,173,174,155,129],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":40},"01M6K3E6PEXBXYY2K8TSRTN1JT","stories","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",[],[177,182,140,142,37,183,184,25,33,34,122,185,186,187,124,188,139,189,150,190,154,91,155],"conduct","engineer","general","requirements","architecture","examples","artifact","requests","implementation",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":40},"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",[],[198,199,200,172,124,201,202,203,139,86,204,205,206,207,208,25,209,33,34,210,155,211],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation","advisory"]