[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JPDTSGY7P3CWS90WYVT2P8":3,"skill-same:01M6JPDTSGY7P3CWS90WYVT2P8":102},{"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":37,"publishedAt":58,"linkOnly":59,"markdownContent":60,"markdownBody":61,"frontMatter":62,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":14,"repositoryHtmlUrl":66,"repositoryHomepageUrl":6,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M6JPDTSGY7P3CWS90WYVT2P8","prd-writing",null,"Write lightweight agile PRDs and technical RFCs that align stakeholders before implementation. Triggers: PRD, product requirements, RFC, request for comments, technical design doc, design document, tech spec, write requirements, what are we building, spec this out. Produces the WHAT and WHY — feature-planning handles HOW.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fprd-writing\u002FSKILL.md",[18,23,26,29,34],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",{"categoryNo":35,"categoryName":36,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000036","内容创作者",[38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57],"writing","prd","prd writing","for","design","Product Requirements","tech","triggers","feature","technical design","align","write","tech spec","design doc","why","how","doc","product","planning","agile","2026-11-10 10:12:30",false,"---\nname: prd-writing\ndescription: \"Write lightweight agile PRDs and technical RFCs that align stakeholders before implementation. Triggers: PRD, product requirements, RFC, request for comments, technical design doc, design document, tech spec, write requirements, what are we building, spec this out. Produces the WHAT and WHY — feature-planning handles HOW.\"\n---\n\n# PRD & RFC Writing\n\nWrite lightweight requirements and design documents that align stakeholders without drowning in waterfall-style documentation. In agile, these documents are living artifacts — concise enough to write quickly, clear enough to prevent misalignment.\n\n## Two Document Types\n\n### Agile PRD (Product Requirements Document)\n**Audience**: Product, design, engineering, stakeholders\n**Purpose**: Define WHAT to build and WHY, from the user's perspective\n**When**: Before starting a significant feature or epic (more than a sprint of work)\n\n### Technical RFC (Request for Comments)\n**Audience**: Engineering team, tech leads, architects\n**Purpose**: Propose HOW to build something technically, gather feedback before committing\n**When**: Before implementing non-trivial technical work (new service, data migration, architecture change)\n\nMany features need both: a PRD from the product side and an RFC from the engineering side. Some only need one.\n\n## Workflow: Agile PRD\n\n### Step 1: Start with the Problem\n\nEvery PRD begins with a crystal-clear problem statement:\n\n- What user pain or business need does this address?\n- Who specifically has this problem? (Define the persona)\n- How big is this problem? (Frequency, severity, number of users affected)\n- What do users do today to work around it?\n\nIf you can't articulate the problem, you're not ready to write requirements.\n\n### Step 2: Define Goals and Non-Goals\n\n**Goals**: What this project will achieve (tied to metrics when possible)\n**Non-goals**: What this project explicitly will NOT do (prevents scope creep)\n\nNon-goals are just as important as goals. They're the guardrails that keep the project focused.\n\n### Step 3: Write User Stories\n\nExpress requirements as user stories:\n\n```\nAs a [user persona],\nI want to [action\u002Fcapability],\nso that [benefit\u002Foutcome].\n```\n\nGroup stories by priority using MoSCoW:\n- **Must have**: Project fails without these\n- **Should have**: Important but not launch-blocking\n- **Could have**: Nice to have if time allows\n- **Won't have (this time)**: Explicitly deferred\n\n### Step 4: Define Acceptance Criteria and Constraints\n\nFor each must-have story, define acceptance criteria (use feature-planning's Given\u002FWhen\u002FThen format).\n\nDocument constraints: performance requirements, accessibility requirements, platform support, backwards compatibility, regulatory compliance.\n\n### Step 5: Include Design Context\n\nIf mockups, wireframes, or user flows exist, link them. If not, describe the intended user experience in enough detail that a designer can start.\n\n### Step 6: Produce the PRD\n\nUse the template at [templates\u002Fprd.md](templates\u002Fprd.md). Keep it under 3 pages. Link to detailed resources rather than embedding everything.\n\n## Workflow: Technical RFC\n\n### Step 1: State the Problem and Context\n\nSame discipline as the PRD — start with why, not what. Include:\n- What triggered this RFC (feature requirement, scaling issue, tech debt)\n- Current state of the system\n- Constraints (timeline, backward compatibility, team expertise)\n\n### Step 2: Propose the Solution\n\nDescribe the technical approach clearly. Include:\n- High-level architecture or design\n- Key components and their interactions\n- Data model changes (link to `data-modeling` if needed)\n- API changes (link to `api-design` if needed)\n\n### Step 3: Present Alternatives\n\nList 2-3 alternatives considered with tradeoffs. This proves you've thought beyond the first idea.\n\n### Step 4: Identify Open Questions\n\nList questions that need answering during or after the review process. This invites targeted feedback.\n\n### Step 5: Produce the RFC\n\nUse the template at [templates\u002Frfc.md](templates\u002Frfc.md). Circulate for review with a clear deadline.\n\n## Principles Applied\n\n- **Agile over waterfall**: These documents are living drafts, not contracts. Update as understanding evolves.\n- **KISS**: If it takes more than an afternoon to write, the scope is too large — split it.\n- **Working software over comprehensive documentation**: Write just enough to align. The code is the real spec.\n","# PRD & RFC Writing\n\nWrite lightweight requirements and design documents that align stakeholders without drowning in waterfall-style documentation. In agile, these documents are living artifacts — concise enough to write quickly, clear enough to prevent misalignment.\n\n## Two Document Types\n\n### Agile PRD (Product Requirements Document)\n**Audience**: Product, design, engineering, stakeholders\n**Purpose**: Define WHAT to build and WHY, from the user's perspective\n**When**: Before starting a significant feature or epic (more than a sprint of work)\n\n### Technical RFC (Request for Comments)\n**Audience**: Engineering team, tech leads, architects\n**Purpose**: Propose HOW to build something technically, gather feedback before committing\n**When**: Before implementing non-trivial technical work (new service, data migration, architecture change)\n\nMany features need both: a PRD from the product side and an RFC from the engineering side. Some only need one.\n\n## Workflow: Agile PRD\n\n### Step 1: Start with the Problem\n\nEvery PRD begins with a crystal-clear problem statement:\n\n- What user pain or business need does this address?\n- Who specifically has this problem? (Define the persona)\n- How big is this problem? (Frequency, severity, number of users affected)\n- What do users do today to work around it?\n\nIf you can't articulate the problem, you're not ready to write requirements.\n\n### Step 2: Define Goals and Non-Goals\n\n**Goals**: What this project will achieve (tied to metrics when possible)\n**Non-goals**: What this project explicitly will NOT do (prevents scope creep)\n\nNon-goals are just as important as goals. They're the guardrails that keep the project focused.\n\n### Step 3: Write User Stories\n\nExpress requirements as user stories:\n\n```\nAs a [user persona],\nI want to [action\u002Fcapability],\nso that [benefit\u002Foutcome].\n```\n\nGroup stories by priority using MoSCoW:\n- **Must have**: Project fails without these\n- **Should have**: Important but not launch-blocking\n- **Could have**: Nice to have if time allows\n- **Won't have (this time)**: Explicitly deferred\n\n### Step 4: Define Acceptance Criteria and Constraints\n\nFor each must-have story, define acceptance criteria (use feature-planning's Given\u002FWhen\u002FThen format).\n\nDocument constraints: performance requirements, accessibility requirements, platform support, backwards compatibility, regulatory compliance.\n\n### Step 5: Include Design Context\n\nIf mockups, wireframes, or user flows exist, link them. If not, describe the intended user experience in enough detail that a designer can start.\n\n### Step 6: Produce the PRD\n\nUse the template at [templates\u002Fprd.md](templates\u002Fprd.md). Keep it under 3 pages. Link to detailed resources rather than embedding everything.\n\n## Workflow: Technical RFC\n\n### Step 1: State the Problem and Context\n\nSame discipline as the PRD — start with why, not what. Include:\n- What triggered this RFC (feature requirement, scaling issue, tech debt)\n- Current state of the system\n- Constraints (timeline, backward compatibility, team expertise)\n\n### Step 2: Propose the Solution\n\nDescribe the technical approach clearly. Include:\n- High-level architecture or design\n- Key components and their interactions\n- Data model changes (link to `data-modeling` if needed)\n- API changes (link to `api-design` if needed)\n\n### Step 3: Present Alternatives\n\nList 2-3 alternatives considered with tradeoffs. This proves you've thought beyond the first idea.\n\n### Step 4: Identify Open Questions\n\nList questions that need answering during or after the review process. This invites targeted feedback.\n\n### Step 5: Produce the RFC\n\nUse the template at [templates\u002Frfc.md](templates\u002Frfc.md). Circulate for review with a clear deadline.\n\n## Principles Applied\n\n- **Agile over waterfall**: These documents are living drafts, not contracts. Update as understanding evolves.\n- **KISS**: If it takes more than an afternoon to write, the scope is too large — split it.\n- **Working software over comprehensive documentation**: Write just enough to align. The code is the real spec.\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fem\u002Fskills\u002Fprd-writing","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-11 09:15:32",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill prd-writing",{"tool":76,"command":77},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill prd-writing",{"tool":79,"command":80},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill prd-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fprd-writing\u002FSKILL.md",true,[84,90,94,98],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Fevals.json","REFERENCE","参考文档",3072,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fprd-writing\u002Fevals\u002Fevals.json",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fprd-examples.md",5777,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fprd-writing\u002Freferences\u002Fprd-examples.md",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"templates\u002Fprd.md",1781,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fprd-writing\u002Ftemplates\u002Fprd.md",{"path":99,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":100,"sourceHtmlUrl":101},"templates\u002Frfc.md",1771,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fprd-writing\u002Ftemplates\u002Frfc.md",[103,136,162,186,216,246],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":118,"publishedAt":58},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[109,112,113,114,115],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":35,"categoryName":36,"taxonomyType":32,"taxonomyTypeDesc":33},{"categoryNo":116,"categoryName":117,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000040","财务",[38,119,120,121,49,122,123,124,125,126,127,128,45,129,130,131,132,133,134,135],"writing skills","testing","eval","edit","Budget","authoring","new skill","library","frontmatter","editing","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":143,"publishedAt":58},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[142],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[144,145,146,147,148,149,150,151,53,152,153,154,155,156,157,158,159,160,45,161],"working agreement","project","definition of done","done","milestone","documentation","work","progress","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":169,"publishedAt":58},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[168],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[170,171,172,173,174,175,38,176,147,177,178,179,150,180,153,181,182,183,184,185],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":197,"publishedAt":58},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[192,193,194],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":195,"categoryName":196,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师",[42,198,199,200,201,202,203,204,205,206,207,208,53,209,210,211,212,213,214,215],"ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":220,"categories":221,"keywords":226,"publishedAt":58},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[222,223],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":224,"categoryName":225,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师",[227,228,229,230,231,232,42,233,234,235,236,237,238,239,240,241,242,243,244,245],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":247,"name":248,"nameZh":6,"description":249,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":250,"categories":251,"keywords":257,"publishedAt":58},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[252,253,254,255,256],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":224,"categoryName":225,"taxonomyType":32,"taxonomyTypeDesc":33},{"categoryNo":195,"categoryName":196,"taxonomyType":32,"taxonomyTypeDesc":33},[42,258,259,260,261,262,120,263,264,176,236,265,266,49,267,268,158,269,41,45],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan"]