[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SS5GFB99TZ2P8DDM9ESMD":3,"skill-same:01M71SS5GFB99TZ2P8DDM9ESMD":88},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":63,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M71SS5GFB99TZ2P8DDM9ESMD","prd-writing",null,"Author Product Requirements Documents (PRDs) from scratch — interview-driven, templated, published to docs\u002Fprds\u002FNNNN-*.md","HigorAlves\u002Forc","HigorAlves","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11262976?v=4","01M71S79EZEMHZ8PQSV0XQJHYY","Higor Alves","01M71S79FKKTCHCN1EDR8DSTWQ",7,"MIT","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fprd-writing\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"writing","prd","prd writing","driven","write a prd","docs","new feature","From Scratch","author","requirements","use","scratch","for","feature","interview","Product Requirements","write","product","documents","new","2026-11-10 13:02:02",false,"---\nname: prd-writing\ndescription: Author Product Requirements Documents (PRDs) from scratch — interview-driven, templated, published to docs\u002Fprds\u002FNNNN-*.md\nwhen_to_use: Use for \"write a PRD for X\", an unsettled new feature, or \u002Forc:prd.\n---\n\n# PRD Writing\n\n> **Defer to `orc:doc-writing`** for the shared scaffolding: the doc-type map (PRD vs TRD vs RFC vs ADR vs postmortem, and how PRD differs from `orc:to-prd`), the shared section outline, the `docs\u002F\u003Ctype>s\u002FNNNN-*.md` numbering & publication convention, and the review gates. This skill carries only the PRD-specific template, fields, and tone.\n\nA PRD is the contract between product intent and engineering execution. It captures **what we're building, for whom, and why now** — *before* anyone argues about architecture. A good PRD makes the design conversation that follows it 10× faster because half the questions are pre-answered.\n\n## When to write one\n\nWrite a PRD when **all** of these are true:\n\n- The work has a **user-facing outcome** — a behavior, capability, or experience changes for someone outside the team.\n- The intent is **non-obvious** — there's a real product question (which audience, which metric, which scope), not just an implementation question.\n- The work is **non-trivial** — multi-day effort, or coordination across product\u002Fdesign\u002Fengineering.\n\nDon't write a PRD for:\n\n- Pure refactors with no user-visible change → use `orc:rfc-writing` if architectural, or just a plan.\n- Tactical bug fixes → just fix it.\n- One-day features that have no audience question (e.g. \"add `--verbose` flag for engineers\") → a plan or issue is enough.\n- A decision that's already made and documented elsewhere → `orc:adr-writing` to record it.\n\n## Interview checklist (before drafting)\n\nIf the user hasn't already answered these in conversation, ask before drafting. Skip questions whose answers are already obvious from context — don't waste user time interviewing them on things they've already said.\n\n1. **Problem.** What user pain or business need triggered this? Quote a real signal — a support thread, a churn metric, a customer ask, a competitive feature, a regulatory deadline.\n2. **Audience.** Who specifically benefits? Single persona, multiple personas, internal team, all users? If \"all users,\" push back — usually it's a subset.\n3. **Success metric.** How will we know in 90 days that this worked? Pick one primary metric, optionally one or two secondaries. \"It feels better\" is not a metric.\n4. **In scope.** The smallest version of this that delivers the outcome.\n5. **Out of scope.** What we are explicitly NOT building (heads off scope creep in review).\n6. **Open questions.** What does the author *not yet know* but needs to before implementation?\n7. **Dependencies \u002F risks.** External teams, vendors, data, regulatory blockers, prior work that has to land first.\n\n## Template\n\nEvery PRD uses this shape. Delete sections that genuinely have no content; **never leave `TBD` or stub placeholder text.** A section that's empty is a lie about being thought through.\n\nTemplate body: [TEMPLATE.md](references\u002FTEMPLATE.md) — read it at step 4, when drafting.\n\n## What to do as the model\n\n1. **Confirm a PRD is warranted** — apply the \"all of these are true\" test above. If borderline, surface the call to the user (PRD \u002F smaller-issue \u002F nothing).\n2. **Run the interview** if input is sparse — go through the seven checklist questions, but skip any already answered in context. Batch into 2–3 `AskUserQuestion` calls; don't drip one at a time.\n3. **Find the next sequence number** in `docs\u002Fprds\u002F` (see the numbering convention in `orc:doc-writing`).\n4. **Draft from [TEMPLATE.md](references\u002FTEMPLATE.md).** Fill every section with real content. **Delete sections that genuinely have no content** (e.g. no counter-metric, no appendix) rather than writing `TBD`.\n5. **Show the draft to the user for review** before committing (review gates in `orc:doc-writing`).\n6. **Commit** via `orc:git-commit`. Suggested message: `docs(prd): NNNN — \u003Ckebab title>`.\n7. **Cross-link.** If the PRD relates to existing tickets, RFCs, ADRs — link FROM those to the PRD (the link is the entry point, not the reverse).\n\n## Tone\n\nPlain prose, written by a product-minded engineer for product-and-engineering readers. No marketing voice (\"delight\", \"seamless\", \"best-in-class\"). No \"obviously\" or \"trivially\" — if it were obvious, you wouldn't need a PRD. Cite real numbers when you can: support ticket counts, latency budgets, deadline dates, named stakeholders by role.\n\n## Anti-patterns\n\n- **Status: Draft** that never moves. Either get approval or archive — don't let a PRD rot in Draft.\n- **PRDs without success metrics.** \"We'll know it's good when we see it\" is a sign the author didn't think hard enough.\n- **PRDs written after the feature shipped.** The \"Why\" gets sanitized in hindsight; future-you can't tell what was real motivation vs. retrofitted justification.\n- **PRDs that read like specs.** If half the content is API shapes and database tables, you're writing a TRD or RFC — promote it accordingly.\n- **PRDs without \"Out of scope\".** Without explicit exclusions, every reviewer will paste in their pet feature and the work doubles.\n- **One-line problem statements.** \"Users want CSV export\" is not a problem statement; it's a solution. The PRD articulates *the problem CSV export solves*.\n","# PRD Writing\n\n> **Defer to `orc:doc-writing`** for the shared scaffolding: the doc-type map (PRD vs TRD vs RFC vs ADR vs postmortem, and how PRD differs from `orc:to-prd`), the shared section outline, the `docs\u002F\u003Ctype>s\u002FNNNN-*.md` numbering & publication convention, and the review gates. This skill carries only the PRD-specific template, fields, and tone.\n\nA PRD is the contract between product intent and engineering execution. It captures **what we're building, for whom, and why now** — *before* anyone argues about architecture. A good PRD makes the design conversation that follows it 10× faster because half the questions are pre-answered.\n\n## When to write one\n\nWrite a PRD when **all** of these are true:\n\n- The work has a **user-facing outcome** — a behavior, capability, or experience changes for someone outside the team.\n- The intent is **non-obvious** — there's a real product question (which audience, which metric, which scope), not just an implementation question.\n- The work is **non-trivial** — multi-day effort, or coordination across product\u002Fdesign\u002Fengineering.\n\nDon't write a PRD for:\n\n- Pure refactors with no user-visible change → use `orc:rfc-writing` if architectural, or just a plan.\n- Tactical bug fixes → just fix it.\n- One-day features that have no audience question (e.g. \"add `--verbose` flag for engineers\") → a plan or issue is enough.\n- A decision that's already made and documented elsewhere → `orc:adr-writing` to record it.\n\n## Interview checklist (before drafting)\n\nIf the user hasn't already answered these in conversation, ask before drafting. Skip questions whose answers are already obvious from context — don't waste user time interviewing them on things they've already said.\n\n1. **Problem.** What user pain or business need triggered this? Quote a real signal — a support thread, a churn metric, a customer ask, a competitive feature, a regulatory deadline.\n2. **Audience.** Who specifically benefits? Single persona, multiple personas, internal team, all users? If \"all users,\" push back — usually it's a subset.\n3. **Success metric.** How will we know in 90 days that this worked? Pick one primary metric, optionally one or two secondaries. \"It feels better\" is not a metric.\n4. **In scope.** The smallest version of this that delivers the outcome.\n5. **Out of scope.** What we are explicitly NOT building (heads off scope creep in review).\n6. **Open questions.** What does the author *not yet know* but needs to before implementation?\n7. **Dependencies \u002F risks.** External teams, vendors, data, regulatory blockers, prior work that has to land first.\n\n## Template\n\nEvery PRD uses this shape. Delete sections that genuinely have no content; **never leave `TBD` or stub placeholder text.** A section that's empty is a lie about being thought through.\n\nTemplate body: [TEMPLATE.md](references\u002FTEMPLATE.md) — read it at step 4, when drafting.\n\n## What to do as the model\n\n1. **Confirm a PRD is warranted** — apply the \"all of these are true\" test above. If borderline, surface the call to the user (PRD \u002F smaller-issue \u002F nothing).\n2. **Run the interview** if input is sparse — go through the seven checklist questions, but skip any already answered in context. Batch into 2–3 `AskUserQuestion` calls; don't drip one at a time.\n3. **Find the next sequence number** in `docs\u002Fprds\u002F` (see the numbering convention in `orc:doc-writing`).\n4. **Draft from [TEMPLATE.md](references\u002FTEMPLATE.md).** Fill every section with real content. **Delete sections that genuinely have no content** (e.g. no counter-metric, no appendix) rather than writing `TBD`.\n5. **Show the draft to the user for review** before committing (review gates in `orc:doc-writing`).\n6. **Commit** via `orc:git-commit`. Suggested message: `docs(prd): NNNN — \u003Ckebab title>`.\n7. **Cross-link.** If the PRD relates to existing tickets, RFCs, ADRs — link FROM those to the PRD (the link is the entry point, not the reverse).\n\n## Tone\n\nPlain prose, written by a product-minded engineer for product-and-engineering readers. No marketing voice (\"delight\", \"seamless\", \"best-in-class\"). No \"obviously\" or \"trivially\" — if it were obvious, you wouldn't need a PRD. Cite real numbers when you can: support ticket counts, latency budgets, deadline dates, named stakeholders by role.\n\n## Anti-patterns\n\n- **Status: Draft** that never moves. Either get approval or archive — don't let a PRD rot in Draft.\n- **PRDs without success metrics.** \"We'll know it's good when we see it\" is a sign the author didn't think hard enough.\n- **PRDs written after the feature shipped.** The \"Why\" gets sanitized in hindsight; future-you can't tell what was real motivation vs. retrofitted justification.\n- **PRDs that read like specs.** If half the content is API shapes and database tables, you're writing a TRD or RFC — promote it accordingly.\n- **PRDs without \"Out of scope\".** Without explicit exclusions, every reviewer will paste in their pet feature and the work doubles.\n- **One-line problem statements.** \"Users want CSV export\" is not a problem statement; it's a solution. The PRD articulates *the problem CSV export solves*.\n",{"name":5,"description":7,"when_to_use":57},"Use for \"write a PRD for X\", an unsettled new feature, or \u002Forc:prd.","main","7522fd7266944e30052204c2f6df287d8b5516be","orc\u002Fskills\u002Fprd-writing",0,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc","https:\u002F\u002Forc.novacstack.com\u002F","https:\u002F\u002Fgithub.com\u002FHigorAlves","higoralves.dev","Software Engineering","2026-11-07 07:26:38",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add HigorAlves\u002Forc --skill prd-writing",{"tool":74,"command":75},"bunx","bunx skills add HigorAlves\u002Forc --skill prd-writing",{"tool":77,"command":78},"pnpm","pnpm dlx skills add HigorAlves\u002Forc --skill prd-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fprd-writing\u002FSKILL.md",true,[82],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002FTEMPLATE.md","REFERENCE","参考文档",2547,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fprd-writing\u002Freferences\u002FTEMPLATE.md",[89,117,142,163,185,205],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":100,"publishedAt":52},"01M71SW40F9TAAEDKBYYBCM814","writing-plans","Write a comprehensive implementation plan of bite-sized TDD tasks that an engineer with zero codebase context could execute — exact files, code, tests, and verification steps","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[95,96,99],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":97,"categoryName":98,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},[32,101,102,103,104,105,106,107,108,109,110,111,112,48,113,114,115,44,116,42],"writing plans","plans","engineer","superpowers","implementation plan","files","when","you","code","tasks","verification","plan","steps","context","ZeRO","tests",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":128,"publishedAt":52},"01M71SW15KHE4MHJW9NEXV65X2","writing-for-agents","orc's doctrine layer for writing any document an agent consumes — skills, AGENTS.md\u002FCLAUDE.md, reference docs","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[123,124,127],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},[129,32,44,130,107,131,132,133,134,135,136,137,42,138,139,140,141,37],"writing for agents","matt pocock","inline","tuning","a skill","layer","doctrine","push","editing","document","github","https","reference",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":149,"publishedAt":52},"01M71SVYQKXT743HHHWGHT3G13","workspace-mode","Use when cwd is a parent dir holding multiple sibling git repos — defines repo auto-detection, --repos\u002F--repo\u002F--all-repos\u002F--this-repo precedence, per-repo dispatch, and linked-PR mechanics.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fworkspace-mode\u002FSKILL.md",[148],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},[150,151,152,153,154,107,155,156,157,158,42,159,160,161,162],"workspace mode","mode","workspace","mechanics","auto","repos","git","pr","repo","dispatch","auto-detection","detection","parent",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":170,"publishedAt":52},"01M71SVVP3BXS06G9395P2K0RH","wizard","Generate an interactive bash wizard walking a human through work only they can perform — credentials, secrets, one-off migrations","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwizard\u002FSKILL.md",[169],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},[165,171,172,173,174,130,107,175,176,177,178,179,180,113,181,182,44,42,183,184],"condition","never","provisioning infrastructure","only","Bash","work","credentials","generate","human","secrets","infrastructure","do","one","interactive",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":52},"01M71SVT4AR6NKAM5B077E7QSJ","wait-what","Stop and re-pitch — the last message did not land; say it again simply, in the project's own vocabulary.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[192,193,194,195,196,130,197,198,199,200,139,140,201,202,203,204],"wait what","wait","project","re","true","pitch","last","say","message","land","it","stop","vocabulary",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":215,"publishedAt":52},"01M71SVQVYRA9QBQ6G8MWR8G6F","vitest","Vitest fast unit testing framework powered by Vite with Jest-compatible API","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fvitest\u002FSKILL.md",[211,214],{"categoryNo":212,"categoryName":213,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":97,"categoryName":98,"taxonomyType":26,"taxonomyTypeDesc":27},[207,216,217,218,219,220,32,107,221,222,223,224,225,226,227,228,229,230,116,231],"coverage","unit","testing","testing framework","generated","api","jest","2026","at","scripts","unit testing","antfu","framework","vite","mocking","dev"]