[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7DH640HDJ2DQ0P2RH5F5A3C":3,"skill-same:01M7DH640HDJ2DQ0P2RH5F5A3C":47},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M7DH640HDJ2DQ0P2RH5F5A3C","spec-validate",null,"Dispatch a fresh-context code-reviewer to validate spec files against the codebase, the master spec, the invariants and the authoring rules, and return a structured verdict","turbokast\u002Fmythhelm","turbokast","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F335585049?v=4","01M7DGYYSHNA1BW1Y9GJFN6DVC","TurboKast","01M7DGYYT6GTPCFADDKS5ZXM1Y",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspec-validate\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: spec-validate\ndescription: Dispatch a fresh-context code-reviewer to validate spec files against the codebase, the master spec, the invariants and the authoring rules, and return a structured verdict\nargument-hint: \"\u003Cspec-name>[,\u003Cspec-name>...]\"\n---\n\n# Spec Validate\n\nPhase 4 of `\u002Fspec`. The author of a spec cannot review it: they read what they meant, not what they wrote. So validation is a dispatched `code-reviewer` that sees only the spec paths and this checklist, never the investigation, the scope reasoning or the design justifications.\n\n## Input\n\n`$ARGUMENTS`: one spec name, or for an epic, the plan's name and every sub-spec name, comma-separated.\n\n## Invocation contexts\n\n- **Slash command**: dispatches the validator and prints its report.\n- **Model-invoked**: the same, normally from `\u002Fspec`.\n- **Non-interactive**: the same. It edits nothing; fixing is `\u002Fspec-fix-and-report`'s job.\n\n## Steps\n\n1. **Resolve** each name with `scripts\u002Fharness\u002Fspec-lifecycle.sh resolve \u003Cname>` (`.claude\u002Fskills\u002Fspec-resolution\u002FSKILL.md`).\n2. **Run the mechanical gate** yourself: `scripts\u002Fci\u002Flint-agent-harness.sh --only specs`. Keep its exit code and findings for the report; the validator judges what the lint cannot.\n3. **Dry-match embedded test selectors.** Collect every `go test … -run \u003Cselector>` command embedded in the spec's task text, in both `-run \u003Cselector>` and `-run=\u003Cselector>` forms. For each, resolve the selector statically — never by running it — against the base tree plus the test names the task's own text declares it will introduce, and fail validation when it matches zero tests, naming the task and the selector. Match the top-level element by parsing the package's test files for `func Test\u003CName>`, `func Fuzz\u003CName>` and `func Example\u003CName>` declarations — `-run` selects fuzz tests and examples too (never `go test -list`: listing starts the test binary, running package init and `TestMain`); verify each subtest suffix against the `t.Run` names nested beneath the matched parent, not anywhere in the package. Follow `-run` semantics for slash-separated selectors (e.g. `TestDecodeFixture\u002Frecorded`). Apply the embedded command's package selection and build constraints (GOOS\u002FGOARCH, `-tags`, constrained filenames) before counting declarations; fail closed when that context cannot be resolved. Fail closed: unparseable command extraction, a match error, a match timeout, a suffix matching no name beneath its parent, or a dynamically named parent whose suffix cannot be checked statically blocks validation exactly like a zero-match selector. A failed dry-match fails validation: report it as a blocking finding and stop before dispatch.\n4. **Dispatch** one validator for a single spec, or one for the whole epic (so it can check cross-spec consistency):\n\n   ```text\n   Agent(subagent_type: \"code-reviewer\", description: \"Validate spec \u003Cname>\", prompt: \u003Cthe prompt below, with the paths filled in>)\n   ```\n\n   Record `dispatched=1` before reading the result; a validator that returns nothing is `failed=1`, and no verdict is reported.\n5. **Optional second reviewer** (advisory): when a vendor is available, run `\u002Fvendor-consult` with the `spec-validate` stage on the spec files (`knowledge\u002Fvendors.md`). Open each of its findings at its anchor; a confirmed one joins the report tagged `[vendor]`, a rejected one is dropped with its reason. It never changes the verdict on its own and never gates; an `unavailable` result is recorded and skipped.\n\n## Validator prompt\n\nPass this with `\u003CSPEC_PATHS>` filled in, and nothing else:\n\n````markdown\nYou are validating spec(s) before implementation: \u003CSPEC_PATHS>. You have no context from their authoring; judge only what is written and what the repository contains. Edit nothing.\n\nRead first: `knowledge\u002Fspec-authoring.md`, `.claude\u002Frules\u002Fspec-authoring.md`, `.claude\u002Frules\u002Fspec-premise-grounding.md`, `knowledge\u002Finvariants.md`, `knowledge\u002Fdomains.md`, and the specification index (`docs\u002Fspec\u002FREADME.md`) and every section of the named master revision the spec cites. New product specs use v2; historical section numbers and audit IDs stay pinned to their original revision. Then read every file in each spec directory.\n\nFor each spec, check:\n\n1. **References.** Every path in design.md and tasks.md exists, or is a new file in an existing directory created by a task. Every cited `file:line`, function and signature matches the code: open each one. Every count or absence claim is grounded structurally, not by a keyword search.\n2. **Requirements.** IDs are numbered (O, N, FR, AC-N.M) with no gaps or reuse. Every acceptance criterion is in EARS form with concrete values and tagged with invariant, gate or section IDs that exist in the master spec. Every non-goal says what still binds. The Definition of Done covers every FR.\n3. **Design.** The current state is cited. Every interface a task consumes has an exact signature, failure cases included. Every choice with an alternative is in the decisions table. The honesty register lists every master-spec demand the spec cites or reaches but does not fully meet; an unlisted gap is a finding. The design follows the conventions for its domain (`.claude\u002Frules\u002Fgo-conventions.md` for Go, `.claude\u002Frules\u002Fgithub-workflows.md` for workflows, `.claude\u002Frules\u002Fharness-scripts.md` for scripts).\n4. **Tasks.** Each task is one logical change in one domain with the right agent; 8 files or fewer unless justified; ordered contract-first with no dependency on a later task; `Produces` exact where consumed; Files complete against its acceptance items; Budget plausible (`.claude\u002Fskills\u002Fspec-decomposition\u002FSKILL.md`). Each acceptance item names its test or command and a state in which it fails; flag every defect shape in `knowledge\u002Fspec-authoring.md` § Patterns that make criteria checkable. Invariants touched are correct and complete for the task's code.\n5. **Conflicts.** No spec in `specs\u002Fin-progress\u002F` or `specs\u002Ftodo\u002F` edits the same files without a note on ordering. No requirement contradicts another, a non-goal or the design.\n6. **Epic only.** The plan's Work Streams name exactly the sub-specs given; the dependency graph between specs is acyclic; cross-references are bidirectional; the sub-specs cover the plan's scope with no gap and no unexplained file overlap.\n\nRules for findings: anchor every finding to a check number above and a location (`file:line`, FR or task ID). Zero findings is a valid result; never invent one. No style-only findings. Mark each finding **blocking** (the spec cannot be implemented correctly as written) or **advisory**.\n\nOutput, per spec:\n\n### Spec review: \u003Cname>\nVerdict: Ready for implementation | Needs revision\n| Check | Result | Findings |\n|---|---|---|\n| 1 References | PASS\u002FFAIL | … |\n| 2 Requirements | PASS\u002FFAIL | … |\n| 3 Design | PASS\u002FFAIL | … |\n| 4 Tasks | PASS\u002FFAIL | … |\n| 5 Conflicts | PASS\u002FFAIL | … |\n| 6 Epic | PASS\u002FFAIL\u002Fn\u002Fa | … |\n#### Findings\n1. [blocking|advisory] \u003Ccheck> \u003Clocation>: \u003Cwhat is wrong> — \u003Cthe concrete fix, or the question only a person can answer>\n````\n\n## Output\n\n```text\ndispatched=1 returned=\u003C0|1> failed=\u003C0|1>\nLint (specs): exit \u003Ccode>; \u003Cfindings or \"clean\">\nVendor (spec-validate): \u003Ccompleted, N confirmed \u002F M rejected | unavailable (\u003Creason>) | not run>\n\u003Cthe validator's report, verbatim, plus any confirmed [vendor] findings>\n```\n","# Spec Validate\n\nPhase 4 of `\u002Fspec`. The author of a spec cannot review it: they read what they meant, not what they wrote. So validation is a dispatched `code-reviewer` that sees only the spec paths and this checklist, never the investigation, the scope reasoning or the design justifications.\n\n## Input\n\n`$ARGUMENTS`: one spec name, or for an epic, the plan's name and every sub-spec name, comma-separated.\n\n## Invocation contexts\n\n- **Slash command**: dispatches the validator and prints its report.\n- **Model-invoked**: the same, normally from `\u002Fspec`.\n- **Non-interactive**: the same. It edits nothing; fixing is `\u002Fspec-fix-and-report`'s job.\n\n## Steps\n\n1. **Resolve** each name with `scripts\u002Fharness\u002Fspec-lifecycle.sh resolve \u003Cname>` (`.claude\u002Fskills\u002Fspec-resolution\u002FSKILL.md`).\n2. **Run the mechanical gate** yourself: `scripts\u002Fci\u002Flint-agent-harness.sh --only specs`. Keep its exit code and findings for the report; the validator judges what the lint cannot.\n3. **Dry-match embedded test selectors.** Collect every `go test … -run \u003Cselector>` command embedded in the spec's task text, in both `-run \u003Cselector>` and `-run=\u003Cselector>` forms. For each, resolve the selector statically — never by running it — against the base tree plus the test names the task's own text declares it will introduce, and fail validation when it matches zero tests, naming the task and the selector. Match the top-level element by parsing the package's test files for `func Test\u003CName>`, `func Fuzz\u003CName>` and `func Example\u003CName>` declarations — `-run` selects fuzz tests and examples too (never `go test -list`: listing starts the test binary, running package init and `TestMain`); verify each subtest suffix against the `t.Run` names nested beneath the matched parent, not anywhere in the package. Follow `-run` semantics for slash-separated selectors (e.g. `TestDecodeFixture\u002Frecorded`). Apply the embedded command's package selection and build constraints (GOOS\u002FGOARCH, `-tags`, constrained filenames) before counting declarations; fail closed when that context cannot be resolved. Fail closed: unparseable command extraction, a match error, a match timeout, a suffix matching no name beneath its parent, or a dynamically named parent whose suffix cannot be checked statically blocks validation exactly like a zero-match selector. A failed dry-match fails validation: report it as a blocking finding and stop before dispatch.\n4. **Dispatch** one validator for a single spec, or one for the whole epic (so it can check cross-spec consistency):\n\n   ```text\n   Agent(subagent_type: \"code-reviewer\", description: \"Validate spec \u003Cname>\", prompt: \u003Cthe prompt below, with the paths filled in>)\n   ```\n\n   Record `dispatched=1` before reading the result; a validator that returns nothing is `failed=1`, and no verdict is reported.\n5. **Optional second reviewer** (advisory): when a vendor is available, run `\u002Fvendor-consult` with the `spec-validate` stage on the spec files (`knowledge\u002Fvendors.md`). Open each of its findings at its anchor; a confirmed one joins the report tagged `[vendor]`, a rejected one is dropped with its reason. It never changes the verdict on its own and never gates; an `unavailable` result is recorded and skipped.\n\n## Validator prompt\n\nPass this with `\u003CSPEC_PATHS>` filled in, and nothing else:\n\n````markdown\nYou are validating spec(s) before implementation: \u003CSPEC_PATHS>. You have no context from their authoring; judge only what is written and what the repository contains. Edit nothing.\n\nRead first: `knowledge\u002Fspec-authoring.md`, `.claude\u002Frules\u002Fspec-authoring.md`, `.claude\u002Frules\u002Fspec-premise-grounding.md`, `knowledge\u002Finvariants.md`, `knowledge\u002Fdomains.md`, and the specification index (`docs\u002Fspec\u002FREADME.md`) and every section of the named master revision the spec cites. New product specs use v2; historical section numbers and audit IDs stay pinned to their original revision. Then read every file in each spec directory.\n\nFor each spec, check:\n\n1. **References.** Every path in design.md and tasks.md exists, or is a new file in an existing directory created by a task. Every cited `file:line`, function and signature matches the code: open each one. Every count or absence claim is grounded structurally, not by a keyword search.\n2. **Requirements.** IDs are numbered (O, N, FR, AC-N.M) with no gaps or reuse. Every acceptance criterion is in EARS form with concrete values and tagged with invariant, gate or section IDs that exist in the master spec. Every non-goal says what still binds. The Definition of Done covers every FR.\n3. **Design.** The current state is cited. Every interface a task consumes has an exact signature, failure cases included. Every choice with an alternative is in the decisions table. The honesty register lists every master-spec demand the spec cites or reaches but does not fully meet; an unlisted gap is a finding. The design follows the conventions for its domain (`.claude\u002Frules\u002Fgo-conventions.md` for Go, `.claude\u002Frules\u002Fgithub-workflows.md` for workflows, `.claude\u002Frules\u002Fharness-scripts.md` for scripts).\n4. **Tasks.** Each task is one logical change in one domain with the right agent; 8 files or fewer unless justified; ordered contract-first with no dependency on a later task; `Produces` exact where consumed; Files complete against its acceptance items; Budget plausible (`.claude\u002Fskills\u002Fspec-decomposition\u002FSKILL.md`). Each acceptance item names its test or command and a state in which it fails; flag every defect shape in `knowledge\u002Fspec-authoring.md` § Patterns that make criteria checkable. Invariants touched are correct and complete for the task's code.\n5. **Conflicts.** No spec in `specs\u002Fin-progress\u002F` or `specs\u002Ftodo\u002F` edits the same files without a note on ordering. No requirement contradicts another, a non-goal or the design.\n6. **Epic only.** The plan's Work Streams name exactly the sub-specs given; the dependency graph between specs is acyclic; cross-references are bidirectional; the sub-specs cover the plan's scope with no gap and no unexplained file overlap.\n\nRules for findings: anchor every finding to a check number above and a location (`file:line`, FR or task ID). Zero findings is a valid result; never invent one. No style-only findings. Mark each finding **blocking** (the spec cannot be implemented correctly as written) or **advisory**.\n\nOutput, per spec:\n\n### Spec review: \u003Cname>\nVerdict: Ready for implementation | Needs revision\n| Check | Result | Findings |\n|---|---|---|\n| 1 References | PASS\u002FFAIL | … |\n| 2 Requirements | PASS\u002FFAIL | … |\n| 3 Design | PASS\u002FFAIL | … |\n| 4 Tasks | PASS\u002FFAIL | … |\n| 5 Conflicts | PASS\u002FFAIL | … |\n| 6 Epic | PASS\u002FFAIL\u002Fn\u002Fa | … |\n#### Findings\n1. [blocking|advisory] \u003Ccheck> \u003Clocation>: \u003Cwhat is wrong> — \u003Cthe concrete fix, or the question only a person can answer>\n````\n\n## Output\n\n```text\ndispatched=1 returned=\u003C0|1> failed=\u003C0|1>\nLint (specs): exit \u003Ccode>; \u003Cfindings or \"clean\">\nVendor (spec-validate): \u003Ccompleted, N confirmed \u002F M rejected | unavailable (\u003Creason>) | not run>\n\u003Cthe validator's report, verbatim, plus any confirmed [vendor] findings>\n```\n",{"name":5,"description":7,"argument-hint":24},"\u003Cspec-name>[,\u003Cspec-name>...]","main","6e250ec86158119da148ddc017b960ed3b2bee2b",".claude\u002Fskills\u002Fspec-validate",1,"https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm","https:\u002F\u002Fgithub.com\u002Fturbokast","https:\u002F\u002Fturbokast.com","2026-11-10 17:37:03",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add turbokast\u002Fmythhelm --skill spec-validate",{"tool":39,"command":40},"bunx","bunx skills add turbokast\u002Fmythhelm --skill spec-validate",{"tool":42,"command":43},"pnpm","pnpm dlx skills add turbokast\u002Fmythhelm --skill spec-validate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspec-validate\u002FSKILL.md",true,[],[48,55,62,69,76,83],{"skillNo":49,"name":50,"nameZh":6,"description":51,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":19},"01M7DH77QH78C95S7A5V1GFKKF","mythhelm-deliver-backlog","Coordinate a MYTHHELM backlog run with the shared stage checks and maintainer checkpoints.","https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm\u002Fblob\u002Fmain\u002F.grok\u002Fskills\u002Fmythhelm-deliver-backlog\u002FSKILL.md",[],[],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":19},"01M7DH748EXYG9RVBWPBJ73M27","mythhelm-bootstrap","Orient a Grok Build session in the MYTHHELM repository before task or spec work.","https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm\u002Fblob\u002Fmain\u002F.grok\u002Fskills\u002Fmythhelm-bootstrap\u002FSKILL.md",[],[],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M7DH70XJE0DZA4T5DYR1TWKZ","vendor-consult","Run one advisory stage consult (premise-ground, spec-validate, task-review, change-review, stuck-oracle, dossier) with an optional external vendor, then adjudicate the answer at its anchors","https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fvendor-consult\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M7DH6X9HSQ308P5FNDSKYR5R","update-docs","Bring README, docs\u002F, knowledge\u002F, WORKFLOW.md and CLAUDE.md in line with what a shipped spec or a merged change actually did — find every statement the change made stale, fix it where readers look, and add only the new facts they need","https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fupdate-docs\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7DH6T82XR40XQFNRTN4AHGN","triage","Score an idea or a GitHub issue against the master spec's stages, gates and commitments, check it for duplicates, and recommend whether it becomes a backlog card; read-only","https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftriage\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7DH6Q17PM4ESX978QYFV6H6","test-driven-development","Red-green-refactor for Go — use when implementing any feature, bug fix or behaviour change, before writing implementation code","https:\u002F\u002Fgithub.com\u002Fturbokast\u002Fmythhelm\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[],[]]