[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K3D9QMEFHF78J9119P25S9":3,"skill-same:01M6K3D9QMEFHF78J9119P25S9":86},{"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":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":75},"01M6K3D9QMEFHF78J9119P25S9","prd",null,"Use only within active engineer\u002Fconduct DECIDE after explore confirmed the product track, when a committed product requirements document is required. Do not invoke for technical-track work, ordinary specifications, or general product discussion.","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\u002Fprd\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"when","product","invoke","gating","conduct","track","for","claims","true","requirements","active","do","document","general","engineer","only","use","decide","technical","work","explore","verify","2026-11-10 10:12:30",false,"---\nname: prd\nimplicit_invocation: required\ndescription: \"Use only within active engineer\u002Fconduct DECIDE after explore confirmed the product track, when a committed product requirements document is required. Do not invoke for technical-track work, ordinary specifications, or general product discussion.\"\nmodel: opus\nenforcement: gating\nphase: decide\nstandalone: true\nrequires: [verify-claims]\n---\n\n## Purpose\n\nAuthor the **product requirements document** for a product-track feature: the *what* and *why*,\nenumerated as testable functional requirements that stories extract from directly. Runs only when\n`\u002Fexplore` set `Track: product`; technical-track features skip this step entirely.\n\n**Correctness gate:** functional requirements are load-bearing — stories extract from them directly.\nApply the `\u002Fverify-claims` protocol before locking FRs: any FR resting on an assumption about user\nneed, scope, or existing behavior must be flagged with its confidence and HARD-BLOCKED for operator\napproval (or HALTed if autonomous) — never lock an FR on an unconfirmed assumption.\n\n## Boundaries\n\n`prd` produces a single artifact — a design doc in `.docs\u002Fspecs\u002F` — and nothing else.\n\nDo NOT:\n- Write code, migrations, configs, tests, stubs, plans, or stories\n- Create files outside `.docs\u002Fspecs\u002F`\n- Invoke `\u002Fplan`, `\u002Fstories`, or any other skill\n\n### Product-only — the hard rule\n\nA PRD states goals and requirements. It MUST NOT name the **new internal mechanism** by which\n*this* feature is built. These are leaks no matter how convenient:\n- command names, subcommands, or CLI flags\n- file paths, directory layouts, config-file names, or config keys\n- function \u002F class \u002F module \u002F type names, signatures, or pseudocode\n- the library \u002F protocol \u002F service \u002F mechanism chosen for this feature (e.g. \"via an MCP server\",\n  \"a symlink\", \"SQLite\", \"a post-checkout hook\", a named algorithm)\n- data schemas, table\u002Fcolumn names, wire formats, ports\n\nName the **capability or behavior** (\"the operator can adopt a platform in one action\"), never the\nmechanism. **Carve-out:** a *pre-existing external* constraint or dependency the feature must live\nwithin (an existing API it must call, \"must run offline\", a mandated datastore) MAY be named as a\nrequirement under **Dependencies** or **Non-Functional Requirements** — that is product reality, not\na leaked internal mechanism. The distinction: *choosing a new internal mechanism* = leak; *stating an\nexternal constraint we don't control* = requirement.\n\n**Where the \"how\" goes:** if a load-bearing technical choice surfaces, record it as a one-line\n**Open Questions** entry framed as a trade-off for `\u002Farchitecture-review` to weigh and capture as an\nADR — never as a decided mechanism in the PRD.\n\nAfter the design doc is saved and approved, **exit the session immediately** — the conductor handles\nthe handoff.\n\n**Path resolution:** every `templates\u002F*.template` path below is relative to this skill's own\ndirectory (`prd\u002Ftemplates\u002F`).\n\n## Practices\n\n### 1. Write the Design Document\n\nUsing `templates\u002Fdesign-doc.md.template`, write a **PRD-grade** doc, clear enough that stories extract\ndirectly from it. Required sections: Problem\u002FBackground, Goals & Non-Goals, Users\u002FPersonas,\n**Functional Requirements (enumerated `FR-1, FR-2, …` — each atomic and testable, including the\nnegative\u002Fedge behavior)**, Non-Functional Requirements (only those that apply), Acceptance Criteria \u002F\nSuccess Metrics, Scope (In\u002FOut), Key Decisions & Rationale (product decisions only), Dependencies,\nOpen Questions.\n\nThe enumerated `FR-N` are the hinge: stories extract granular scenarios per FR. Keep each FR to a\nsingle verifiable capability.\n\nSave to `.docs\u002Fspecs\u002FYYYY-MM-DD-\u003Ctopic>.md`. After writing, verify the file exists (`ls`). Archive any\nprior design doc for the same feature by prepending `SUPERSEDED-`.\n\n### 2. Product-Only Audit (GATE — before presenting for approval)\n\nRe-read the draft and scan every section — especially Functional Requirements and Key Decisions — for\nthe technical \"hows\" listed in Boundaries. For each one found: either **restate it as a\ncapability\u002Fbehavior**, or **move it to Open Questions** as a trade-off for architecture-review (unless\nit is a pre-existing external constraint, which may stay under Dependencies\u002FNFR per the carve-out). A\nPRD that names a new internal mechanism has FAILED this gate — fix it before presenting. (If the\noperator says the PRD is leaking technical detail, this gate was skipped — re-run it.)\n\n### 3. Scope Check\n\nCompare the design against the user's **original request**. Count models\u002Fendpoints\u002Ffeatures; if the\ndesign significantly exceeds the request, surface it explicitly and get confirmation. Do NOT silently\nexpand scope.\n\n### 4. Get Approval, Then Exit\n\nPresent the design doc; do not proceed until the user explicitly approves (\"looks good\"\u002F\"yes\" counts).\nOn approval: set Status to \"Approved\" and **exit immediately** — do not suggest any other skill.\n\n### 5. API Contract (API Projects Only)\n\nIf the project exposes an API, ensure `.docs\u002Fdecisions\u002Fapi-response-contract.md` exists (generate from\n`templates\u002Fapi-response-contract.md.template` if not), present it for review, and save the approved\ncontract. This MUST happen before stories — stories reference it for response-format assertions.\n\n## Constraints\n\n- **HARD CONSTRAINT: `prd` MUST NEVER call `ExitPlanMode`.** It produces a design document, not an\n  implementation plan; calling it makes `\u002Fconduct` mark the step failed. Write the doc and return.\n\n### Memory Checkpoint\n\nAfter approval, persist to `.memory\u002Fdecisions\u002F` only a non-obvious product trade-off not apparent from\nthe doc itself. Do NOT persist the design-doc contents.\n\n## Verification\n\n- [ ] Design document written with all required sections, saved to `.docs\u002Fspecs\u002F`\n- [ ] **Product-only audit passed — NO new-internal-mechanism \"hows\"** (commands\u002Fflags, paths, config\n      keys, function\u002Ftype names, library\u002Fprotocol\u002Fmechanism choices, schemas); every requirement is a\n      capability\u002Fbehavior, load-bearing technical choices deferred to architecture-review under Open\n      Questions; external constraints allowed only under Dependencies\u002FNFR\n- [ ] **No files written outside `.docs\u002Fspecs\u002F`**; no code, plans, stories, or migrations produced\n- [ ] Scope checked against the original request\n- [ ] User explicitly approved; Status set to \"Approved\"\n- [ ] `ExitPlanMode` was NOT called; session exited immediately after approval\n","## Purpose\n\nAuthor the **product requirements document** for a product-track feature: the *what* and *why*,\nenumerated as testable functional requirements that stories extract from directly. Runs only when\n`\u002Fexplore` set `Track: product`; technical-track features skip this step entirely.\n\n**Correctness gate:** functional requirements are load-bearing — stories extract from them directly.\nApply the `\u002Fverify-claims` protocol before locking FRs: any FR resting on an assumption about user\nneed, scope, or existing behavior must be flagged with its confidence and HARD-BLOCKED for operator\napproval (or HALTed if autonomous) — never lock an FR on an unconfirmed assumption.\n\n## Boundaries\n\n`prd` produces a single artifact — a design doc in `.docs\u002Fspecs\u002F` — and nothing else.\n\nDo NOT:\n- Write code, migrations, configs, tests, stubs, plans, or stories\n- Create files outside `.docs\u002Fspecs\u002F`\n- Invoke `\u002Fplan`, `\u002Fstories`, or any other skill\n\n### Product-only — the hard rule\n\nA PRD states goals and requirements. It MUST NOT name the **new internal mechanism** by which\n*this* feature is built. These are leaks no matter how convenient:\n- command names, subcommands, or CLI flags\n- file paths, directory layouts, config-file names, or config keys\n- function \u002F class \u002F module \u002F type names, signatures, or pseudocode\n- the library \u002F protocol \u002F service \u002F mechanism chosen for this feature (e.g. \"via an MCP server\",\n  \"a symlink\", \"SQLite\", \"a post-checkout hook\", a named algorithm)\n- data schemas, table\u002Fcolumn names, wire formats, ports\n\nName the **capability or behavior** (\"the operator can adopt a platform in one action\"), never the\nmechanism. **Carve-out:** a *pre-existing external* constraint or dependency the feature must live\nwithin (an existing API it must call, \"must run offline\", a mandated datastore) MAY be named as a\nrequirement under **Dependencies** or **Non-Functional Requirements** — that is product reality, not\na leaked internal mechanism. The distinction: *choosing a new internal mechanism* = leak; *stating an\nexternal constraint we don't control* = requirement.\n\n**Where the \"how\" goes:** if a load-bearing technical choice surfaces, record it as a one-line\n**Open Questions** entry framed as a trade-off for `\u002Farchitecture-review` to weigh and capture as an\nADR — never as a decided mechanism in the PRD.\n\nAfter the design doc is saved and approved, **exit the session immediately** — the conductor handles\nthe handoff.\n\n**Path resolution:** every `templates\u002F*.template` path below is relative to this skill's own\ndirectory (`prd\u002Ftemplates\u002F`).\n\n## Practices\n\n### 1. Write the Design Document\n\nUsing `templates\u002Fdesign-doc.md.template`, write a **PRD-grade** doc, clear enough that stories extract\ndirectly from it. Required sections: Problem\u002FBackground, Goals & Non-Goals, Users\u002FPersonas,\n**Functional Requirements (enumerated `FR-1, FR-2, …` — each atomic and testable, including the\nnegative\u002Fedge behavior)**, Non-Functional Requirements (only those that apply), Acceptance Criteria \u002F\nSuccess Metrics, Scope (In\u002FOut), Key Decisions & Rationale (product decisions only), Dependencies,\nOpen Questions.\n\nThe enumerated `FR-N` are the hinge: stories extract granular scenarios per FR. Keep each FR to a\nsingle verifiable capability.\n\nSave to `.docs\u002Fspecs\u002FYYYY-MM-DD-\u003Ctopic>.md`. After writing, verify the file exists (`ls`). Archive any\nprior design doc for the same feature by prepending `SUPERSEDED-`.\n\n### 2. Product-Only Audit (GATE — before presenting for approval)\n\nRe-read the draft and scan every section — especially Functional Requirements and Key Decisions — for\nthe technical \"hows\" listed in Boundaries. For each one found: either **restate it as a\ncapability\u002Fbehavior**, or **move it to Open Questions** as a trade-off for architecture-review (unless\nit is a pre-existing external constraint, which may stay under Dependencies\u002FNFR per the carve-out). A\nPRD that names a new internal mechanism has FAILED this gate — fix it before presenting. (If the\noperator says the PRD is leaking technical detail, this gate was skipped — re-run it.)\n\n### 3. Scope Check\n\nCompare the design against the user's **original request**. Count models\u002Fendpoints\u002Ffeatures; if the\ndesign significantly exceeds the request, surface it explicitly and get confirmation. Do NOT silently\nexpand scope.\n\n### 4. Get Approval, Then Exit\n\nPresent the design doc; do not proceed until the user explicitly approves (\"looks good\"\u002F\"yes\" counts).\nOn approval: set Status to \"Approved\" and **exit immediately** — do not suggest any other skill.\n\n### 5. API Contract (API Projects Only)\n\nIf the project exposes an API, ensure `.docs\u002Fdecisions\u002Fapi-response-contract.md` exists (generate from\n`templates\u002Fapi-response-contract.md.template` if not), present it for review, and save the approved\ncontract. This MUST happen before stories — stories reference it for response-format assertions.\n\n## Constraints\n\n- **HARD CONSTRAINT: `prd` MUST NEVER call `ExitPlanMode`.** It produces a design document, not an\n  implementation plan; calling it makes `\u002Fconduct` mark the step failed. Write the doc and return.\n\n### Memory Checkpoint\n\nAfter approval, persist to `.memory\u002Fdecisions\u002F` only a non-obvious product trade-off not apparent from\nthe doc itself. Do NOT persist the design-doc contents.\n\n## Verification\n\n- [ ] Design document written with all required sections, saved to `.docs\u002Fspecs\u002F`\n- [ ] **Product-only audit passed — NO new-internal-mechanism \"hows\"** (commands\u002Fflags, paths, config\n      keys, function\u002Ftype names, library\u002Fprotocol\u002Fmechanism choices, schemas); every requirement is a\n      capability\u002Fbehavior, load-bearing technical choices deferred to architecture-review under Open\n      Questions; external constraints allowed only under Dependencies\u002FNFR\n- [ ] **No files written outside `.docs\u002Fspecs\u002F`**; no code, plans, stories, or migrations produced\n- [ ] Scope checked against the original request\n- [ ] User explicitly approved; Status set to \"Approved\"\n- [ ] `ExitPlanMode` was NOT called; session exited immediately after approval\n",{"name":5,"model":51,"phase":41,"requires":52,"standalone":54,"description":7,"enforcement":27,"implicit_invocation":55},"opus",[53],"verify-claims",true,"required","main","136b34ec6792f53d0beba330dfa2dffad6c93484","skills\u002Fprd",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 22:26:29",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":54},[65,68,71],{"tool":66,"command":67},"npx","npx skills add jstoup111\u002Fai-conductor --skill prd",{"tool":69,"command":70},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill prd",{"tool":72,"command":73},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill prd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fprd\u002FSKILL.md",[76,82],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"templates\u002Fapi-response-contract.md.template","OTHER","其他",1934,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fprd\u002Ftemplates\u002Fapi-response-contract.md.template",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"templates\u002Fdesign-doc.md.template",2005,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fprd\u002Ftemplates\u002Fdesign-doc.md.template",[87,105,141,159,178,190],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":46},"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",[],[94,95,96,97,98,99,100,101,102,103,32,104,27],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","dependencies","license","judge",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":122,"publishedAt":46},"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",[111,116,119],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":117,"categoryName":118,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":120,"categoryName":121,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[123,124,125,126,127,128,129,130,131,132,133,134,31,135,136,137,138,27,139,140],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","api","directory","ui","framework","failing","phase","request",{"skillNo":142,"name":53,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":46},"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",[],[147,31,45,35,148,30,149,150,32,151,39,40,152,153,154,155,34,156,157,158,26,27,24],"verify claims","adr","decision","claim","mechanics","workflow","code","reports","plan","questions","about","spec",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":46},"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",[],[161,166,167,168,131,169,99,170,171,172,173,100,174,32,40,175,176,177,24,139],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":46},"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",[],[180,28,35,30,41,38,37,32,39,40,133,33,185,186,31,187,45,188,34,189,26,27,24],"architecture","examples","artifact","requests","implementation",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":46},"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",[],[197,198,199,175,31,200,201,202,45,100,203,204,205,206,207,32,208,39,40,209,24,210],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation","advisory"]