[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X3JGCGFN8APT841146PKY1":3,"skill-same:01M6X3JGCGFN8APT841146PKY1":99},{"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":78,"commitSha":79,"skillDirectory":80,"forksCount":14,"repositoryHtmlUrl":81,"repositoryHomepageUrl":82,"ownerHtmlUrl":83,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":84,"install":85,"resources":98},"01M6X3JGCGFN8APT841146PKY1","prd-writing",null,"Write a Product Requirements Document structured with problem statement, goals, user stories, scope, and success metrics.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.1\u002Fcontext\u002Fskills\u002Fproduct\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],"prd","prd writing","writing","document","user stories","problem statement","Product Requirements","problem","scope","project","artifact","backlog","wed","write","work","decision","open","metrics","product","workitem","2026-11-10 10:12:30",false,"---\nname: prd-writing\ndescription: >\n  Write a Product Requirements Document structured with problem\n  statement, goals, user stories, scope, and success metrics.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-prd-writing\n    version: \"1.1.0\"\n    created: 2026-04-08T00:00:00Z\n    category: product\n    layer: 2\n    uses:\n      - skill: workitem-management\n        purpose: Link requirements to WorkItems in the project backlog.\n      - skill: decision-record\n        purpose: Reference DecisionRecords that motivated requirements\n          or resolved open questions.\n    provides:\n      primitives: [Artifact]\n      mcp_tools: []\n      assets: []\n      processes: [prd-writing]\n---\n\n# PRD Writing\n\n## Intro\n\nA PRD (Product Requirements Document) aligns the team on what to\nbuild, why, and how to know when it's done. It is not a design\nspec, not a technical spec, and not a project plan — it is the\nbridge between user need and team execution. A good PRD can be read\nin 15 minutes and leave no major questions unanswered.\n\n## Overview\n\n### Feature PRD vs. product\u002Fvision PRD\n\nprocesskit distinguishes two PRD variants:\n\n**Feature PRD** — scopes a single feature or change. Audience: the\nimmediate delivery team. Contains: problem statement, use cases with\nacceptance criteria, functional + non-functional requirements,\nsuccess metrics. Template: see `### Feature PRD template` below.\n\n**Product\u002Fvision PRD** — defines the product itself: what it is, who\nit serves, what it must do, and how success is measured. Audience:\ncontributors, stakeholders, and agents picking up the project cold.\nContains: vision, target users, component map, core requirements,\nnon-goals, success metrics, milestones, glossary, open questions.\nTemplate: see `### Product PRD template` below.\n\n### Feature PRD template\n\n```markdown\n# [Feature Name] — Product Requirements\n\n**Status:** Draft | Review | Approved  \n**Owner:** [PM name]  \n**Target release:** [Version \u002F Quarter]  \n**Last updated:** [Date]\n\n---\n\n## Problem statement\n\n[2-3 sentences: what user problem is this solving? What evidence\nconfirms it's real? Why now?]\n\n## Goals\n\n**Primary goal:** [The single most important outcome — one sentence]\n\n**Secondary goals:**\n- [Additional measurable outcome]\n- [Additional measurable outcome]\n\n**Non-goals (explicitly out of scope):**\n- [What we are NOT building in this version]\n- [What we will address in a future iteration]\n\n## Users and use cases\n\n**Primary user:** [Role \u002F persona, with 1-sentence description]\n\n### Use cases\n\n**Use case 1: [Name]**\n> As a [user type], I want to [action] so that [benefit].\n\n- **Current experience:** [How users solve this today, or don't]\n- **Desired experience:** [What the new experience looks like]\n- **Acceptance criteria:**\n  - [ ] [Specific, testable criterion]\n  - [ ] [Specific, testable criterion]\n\n**Use case 2: [Name]**\n[Same structure]\n\n## Requirements\n\n### Functional requirements\n\n| ID | Requirement | Priority | Notes |\n|---|---|---|---|\n| REQ-001 | [Capability the product must have] | Must | |\n| REQ-002 | [Capability the product must have] | Should | |\n| REQ-003 | [Capability nice to have] | Could | |\n\nUse MoSCoW: Must \u002F Should \u002F Could \u002F Won't.\n\n### Non-functional requirements\n\n- **Performance:** [e.g., \"p99 response \u003C 500ms under 1000 concurrent users\"]\n- **Availability:** [e.g., \"99.9% uptime\"]\n- **Security:** [e.g., \"data encrypted at rest and in transit\"]\n- **Accessibility:** [e.g., \"WCAG 2.1 AA compliance\"]\n\n## Success metrics\n\n| Metric | Baseline | Target | Timeframe | How measured |\n|---|---|---|---|---|\n| [Primary metric] | [Current value] | [Goal] | [e.g., 90 days post-launch] | [Data source] |\n| [Secondary metric] | | | | |\n\n**Counter-metrics** (watch for regressions):\n- [Metric that should not worsen]\n\n## Dependencies and constraints\n\n- **Technical dependencies:** [APIs, infrastructure, other teams' work]\n- **Design dependency:** [Design work required before development]\n- **Timeline constraint:** [Hard deadlines and their reason]\n- **Regulatory constraint:** [Compliance requirements]\n\n## Open questions\n\n| Question | Owner | Due by | Status |\n|---|---|---|---|\n| [Decision needed] | [Name] | [Date] | Open |\n\n## Appendix\n\n[Links to: user research, design mockups, competitive analysis,\nanalytics data, technical feasibility notes]\n```\n\n### Product PRD template\n\nFor product-level or vision-level PRDs:\n\n~~~markdown\n# [Product Name] — Product Requirements\n\n**Status:** Draft | Review | Approved\n**Owner:** [name or team]\n**Last updated:** [YYYY-MM-DD]\n\n---\n\n## Vision\n\n[2-4 sentences: what is this product, who is it for, and why does\nit exist? Distinct from goals — this is the directional statement.]\n\n## Problem statement\n\n[What problem does this product solve? What evidence confirms it is\nreal? Why is this the right solution?]\n\n## Goals\n\n**Primary goal:** [The single most important outcome.]\n\n**Secondary goals:**\n- [Measurable secondary outcome]\n\n**Non-goals:** See Non-goals section.\n\n## Target users\n\n| User | What they get |\n|---|---|\n| [Role] | [Value] |\n\n## Component map\n\n[ASCII diagram or description of how major components relate.]\n\n## Core requirements\n\n### R1 — [Requirement name]\n\n[Requirement description. Reference the format spec or schema where\napplicable rather than reproducing it inline.]\n\n### R2 — ...\n\n## Non-functional requirements\n\n- **Portability:** ...\n- **Offline capability:** ...\n- **Backward compatibility:** ...\n\n## Non-goals\n\n- [Explicitly out of scope]\n\n## Success metrics\n\n| Metric | Status | Target |\n|---|---|---|\n| [Metric] | [Current] | [Goal] |\n\n## Milestones\n\n[What has shipped. What v1.0 \u002F next milestone requires. No date\ncommitments unless hard deadlines exist.]\n\n## Glossary\n\n| Term | Definition |\n|---|---|\n| [Term] | [One-line definition] |\n\n## Open questions and constraints\n\n**Technical constraints:**\n- [Hard constraint]\n\n**Open design decisions:**\n- [Decision not yet made]\n\n## Appendix\n\n- [Link to canonical spec files, related decisions, research]\n~~~\n\n### Before writing — gather the inputs\n\nA PRD written without evidence is advocacy, not requirements. Gather\nfirst:\n\n1. **User pain**: interviews, support tickets, NPS feedback, usage\n   data showing the gap\n2. **Business case**: why this over other options? Revenue impact,\n   churn risk, strategic fit\n3. **Technical feasibility**: rough signal from engineering that\n   the approach is buildable in the target timeframe\n4. **Competitive context**: how do alternatives solve this?\n\n### Scoping: non-goals are as important as goals\n\nEvery PRD should explicitly list what is NOT in scope. Non-goals:\n- Prevent scope creep during development\n- Let the team build faster (smaller, clearer target)\n- Force the PM to actually choose priorities\n\nIf every obvious extension is in-scope, the PRD is not prioritized.\n\n### Writing acceptance criteria\n\nEach use case must have testable acceptance criteria — not \"works\nwell\" but \"the user can complete [task] without [error]\".\n\n**Bad:** \"The export works correctly.\"  \n**Good:**\n- [ ] User can export up to 10,000 rows as CSV in \u003C 5 seconds\n- [ ] Export includes all columns visible on the current filter\n- [ ] Filename defaults to `[report-name]-[YYYY-MM-DD].csv`\n\n### Keeping the PRD current\n\nA PRD that is written once and never updated becomes a liability.\nMark decisions made, questions answered, and requirements changed.\nA \"Status: Approved\" PRD with open questions that were resolved\nwithout updating the document causes downstream confusion.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Writing solution first, problem second.** A PRD that opens with \"We will build a dashboard\" skips the why — it's a solution looking for a problem. Always lead with the user problem and the evidence that it's real. The solution follows from the problem, not the other way around.\n- **Writing acceptance criteria that are not testable.** \"The UI is intuitive\" is not an acceptance criterion — it cannot be verified. \"A new user can complete the primary task in under 2 minutes without asking for help\" is testable. Each acceptance criterion must have a binary pass\u002Ffail.\n- **Omitting non-goals.** Without explicit non-goals, the team will build the obvious extensions and the feature will take 3× as long. Non-goals force a prioritization decision and give the team permission to say \"that's out of scope\" during development.\n- **Writing requirements that prescribe implementation instead of behavior.** \"Use a dropdown\" is an implementation decision; \"the user selects a single option from the list\" is a requirement. PRDs should describe what the product does, not how it's built — that's the team's decision.\n- **Skipping success metrics.** A PRD without success metrics produces a feature you can ship but never evaluate. If you cannot define what \"success\" looks like before building, you cannot tell after shipping whether the investment was worth it.\n- **Leaving open questions open at launch.** Questions that are open at PRD approval must be answered before development starts. A PRD with open architecture questions or unresolved design decisions is not ready for development — it will be decided ad-hoc during implementation, usually badly.\n- **Making the PRD too long.** A PRD that takes 2 hours to read will not be read by the team before development starts. Keep it to one focused session (15-30 min) — the full detail belongs in linked design docs, technical specs, and research reports, not in the PRD itself.\n- **Writing a PRD without loading this skill first.** The trigger\n  phrase \"PRD\" or \"product requirements\" should load this skill\n  before any writing begins. Writing from general knowledge produces\n  a document that may look correct but misses processkit-specific\n  conventions (Artifact storage, workitem linking, feature vs.\n  product PRD distinction).\n\n## Full reference\n\n### PRD vs. technical spec vs. design spec\n\n| Document | Owner | Answers | When written |\n|---|---|---|---|\n| PRD | Product manager | What and why | Before design and eng start |\n| Design spec | Designer | How it looks and feels | After PRD approval |\n| Technical spec | Engineering | How it's built | After design spec |\n\nThe PRD is the source of truth for requirements. Design and technical\nspecs are downstream — they should be consistent with the PRD, and\ncontradictions should trigger a PRD update, not a silent departure.\n\n### MoSCoW prioritization\n\n| Priority | Meaning | Implication |\n|---|---|---|\n| **Must** | The feature cannot ship without this | Block release if missing |\n| **Should** | High value but can be worked around temporarily | Include if time allows; don't block |\n| **Could** | Nice to have, low risk if cut | Cuts first when scope must shrink |\n| **Won't** | Explicitly out of scope for this version | Documents a conscious choice |\n\n### Linking to processkit context\n\nWhen the project uses processkit, link the PRD to:\n- The WorkItem(s) it spawns (list BACK-NNN IDs in the appendix)\n- Relevant decisions (`context\u002Fdecisions\u002F` or DECISIONS.md)\n- Research notes (Note entities with `type: reference`)\n\nSave the PRD as `context\u002Fartifacts\u002Fprd-[feature-name]-[date].md` or\nlink it as an Artifact entity in the index.\n\nThe PRD itself should be stored as an `Artifact` entity under\n`context\u002Fartifacts\u002Fprd-\u003Cproduct-or-feature>-\u003Cdate>.md` so it is\nindexed and queryable. Create the entity with:\n\n    spec:\n      name: \u003Cdescriptive name>\n      kind: document\n      location: context\u002Fartifacts\u002Fprd-\u003Cname>-\u003Cdate>.md\n      format: markdown\n      tags: [prd]\n","# PRD Writing\n\n## Intro\n\nA PRD (Product Requirements Document) aligns the team on what to\nbuild, why, and how to know when it's done. It is not a design\nspec, not a technical spec, and not a project plan — it is the\nbridge between user need and team execution. A good PRD can be read\nin 15 minutes and leave no major questions unanswered.\n\n## Overview\n\n### Feature PRD vs. product\u002Fvision PRD\n\nprocesskit distinguishes two PRD variants:\n\n**Feature PRD** — scopes a single feature or change. Audience: the\nimmediate delivery team. Contains: problem statement, use cases with\nacceptance criteria, functional + non-functional requirements,\nsuccess metrics. Template: see `### Feature PRD template` below.\n\n**Product\u002Fvision PRD** — defines the product itself: what it is, who\nit serves, what it must do, and how success is measured. Audience:\ncontributors, stakeholders, and agents picking up the project cold.\nContains: vision, target users, component map, core requirements,\nnon-goals, success metrics, milestones, glossary, open questions.\nTemplate: see `### Product PRD template` below.\n\n### Feature PRD template\n\n```markdown\n# [Feature Name] — Product Requirements\n\n**Status:** Draft | Review | Approved  \n**Owner:** [PM name]  \n**Target release:** [Version \u002F Quarter]  \n**Last updated:** [Date]\n\n---\n\n## Problem statement\n\n[2-3 sentences: what user problem is this solving? What evidence\nconfirms it's real? Why now?]\n\n## Goals\n\n**Primary goal:** [The single most important outcome — one sentence]\n\n**Secondary goals:**\n- [Additional measurable outcome]\n- [Additional measurable outcome]\n\n**Non-goals (explicitly out of scope):**\n- [What we are NOT building in this version]\n- [What we will address in a future iteration]\n\n## Users and use cases\n\n**Primary user:** [Role \u002F persona, with 1-sentence description]\n\n### Use cases\n\n**Use case 1: [Name]**\n> As a [user type], I want to [action] so that [benefit].\n\n- **Current experience:** [How users solve this today, or don't]\n- **Desired experience:** [What the new experience looks like]\n- **Acceptance criteria:**\n  - [ ] [Specific, testable criterion]\n  - [ ] [Specific, testable criterion]\n\n**Use case 2: [Name]**\n[Same structure]\n\n## Requirements\n\n### Functional requirements\n\n| ID | Requirement | Priority | Notes |\n|---|---|---|---|\n| REQ-001 | [Capability the product must have] | Must | |\n| REQ-002 | [Capability the product must have] | Should | |\n| REQ-003 | [Capability nice to have] | Could | |\n\nUse MoSCoW: Must \u002F Should \u002F Could \u002F Won't.\n\n### Non-functional requirements\n\n- **Performance:** [e.g., \"p99 response \u003C 500ms under 1000 concurrent users\"]\n- **Availability:** [e.g., \"99.9% uptime\"]\n- **Security:** [e.g., \"data encrypted at rest and in transit\"]\n- **Accessibility:** [e.g., \"WCAG 2.1 AA compliance\"]\n\n## Success metrics\n\n| Metric | Baseline | Target | Timeframe | How measured |\n|---|---|---|---|---|\n| [Primary metric] | [Current value] | [Goal] | [e.g., 90 days post-launch] | [Data source] |\n| [Secondary metric] | | | | |\n\n**Counter-metrics** (watch for regressions):\n- [Metric that should not worsen]\n\n## Dependencies and constraints\n\n- **Technical dependencies:** [APIs, infrastructure, other teams' work]\n- **Design dependency:** [Design work required before development]\n- **Timeline constraint:** [Hard deadlines and their reason]\n- **Regulatory constraint:** [Compliance requirements]\n\n## Open questions\n\n| Question | Owner | Due by | Status |\n|---|---|---|---|\n| [Decision needed] | [Name] | [Date] | Open |\n\n## Appendix\n\n[Links to: user research, design mockups, competitive analysis,\nanalytics data, technical feasibility notes]\n```\n\n### Product PRD template\n\nFor product-level or vision-level PRDs:\n\n~~~markdown\n# [Product Name] — Product Requirements\n\n**Status:** Draft | Review | Approved\n**Owner:** [name or team]\n**Last updated:** [YYYY-MM-DD]\n\n---\n\n## Vision\n\n[2-4 sentences: what is this product, who is it for, and why does\nit exist? Distinct from goals — this is the directional statement.]\n\n## Problem statement\n\n[What problem does this product solve? What evidence confirms it is\nreal? Why is this the right solution?]\n\n## Goals\n\n**Primary goal:** [The single most important outcome.]\n\n**Secondary goals:**\n- [Measurable secondary outcome]\n\n**Non-goals:** See Non-goals section.\n\n## Target users\n\n| User | What they get |\n|---|---|\n| [Role] | [Value] |\n\n## Component map\n\n[ASCII diagram or description of how major components relate.]\n\n## Core requirements\n\n### R1 — [Requirement name]\n\n[Requirement description. Reference the format spec or schema where\napplicable rather than reproducing it inline.]\n\n### R2 — ...\n\n## Non-functional requirements\n\n- **Portability:** ...\n- **Offline capability:** ...\n- **Backward compatibility:** ...\n\n## Non-goals\n\n- [Explicitly out of scope]\n\n## Success metrics\n\n| Metric | Status | Target |\n|---|---|---|\n| [Metric] | [Current] | [Goal] |\n\n## Milestones\n\n[What has shipped. What v1.0 \u002F next milestone requires. No date\ncommitments unless hard deadlines exist.]\n\n## Glossary\n\n| Term | Definition |\n|---|---|\n| [Term] | [One-line definition] |\n\n## Open questions and constraints\n\n**Technical constraints:**\n- [Hard constraint]\n\n**Open design decisions:**\n- [Decision not yet made]\n\n## Appendix\n\n- [Link to canonical spec files, related decisions, research]\n~~~\n\n### Before writing — gather the inputs\n\nA PRD written without evidence is advocacy, not requirements. Gather\nfirst:\n\n1. **User pain**: interviews, support tickets, NPS feedback, usage\n   data showing the gap\n2. **Business case**: why this over other options? Revenue impact,\n   churn risk, strategic fit\n3. **Technical feasibility**: rough signal from engineering that\n   the approach is buildable in the target timeframe\n4. **Competitive context**: how do alternatives solve this?\n\n### Scoping: non-goals are as important as goals\n\nEvery PRD should explicitly list what is NOT in scope. Non-goals:\n- Prevent scope creep during development\n- Let the team build faster (smaller, clearer target)\n- Force the PM to actually choose priorities\n\nIf every obvious extension is in-scope, the PRD is not prioritized.\n\n### Writing acceptance criteria\n\nEach use case must have testable acceptance criteria — not \"works\nwell\" but \"the user can complete [task] without [error]\".\n\n**Bad:** \"The export works correctly.\"  \n**Good:**\n- [ ] User can export up to 10,000 rows as CSV in \u003C 5 seconds\n- [ ] Export includes all columns visible on the current filter\n- [ ] Filename defaults to `[report-name]-[YYYY-MM-DD].csv`\n\n### Keeping the PRD current\n\nA PRD that is written once and never updated becomes a liability.\nMark decisions made, questions answered, and requirements changed.\nA \"Status: Approved\" PRD with open questions that were resolved\nwithout updating the document causes downstream confusion.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Writing solution first, problem second.** A PRD that opens with \"We will build a dashboard\" skips the why — it's a solution looking for a problem. Always lead with the user problem and the evidence that it's real. The solution follows from the problem, not the other way around.\n- **Writing acceptance criteria that are not testable.** \"The UI is intuitive\" is not an acceptance criterion — it cannot be verified. \"A new user can complete the primary task in under 2 minutes without asking for help\" is testable. Each acceptance criterion must have a binary pass\u002Ffail.\n- **Omitting non-goals.** Without explicit non-goals, the team will build the obvious extensions and the feature will take 3× as long. Non-goals force a prioritization decision and give the team permission to say \"that's out of scope\" during development.\n- **Writing requirements that prescribe implementation instead of behavior.** \"Use a dropdown\" is an implementation decision; \"the user selects a single option from the list\" is a requirement. PRDs should describe what the product does, not how it's built — that's the team's decision.\n- **Skipping success metrics.** A PRD without success metrics produces a feature you can ship but never evaluate. If you cannot define what \"success\" looks like before building, you cannot tell after shipping whether the investment was worth it.\n- **Leaving open questions open at launch.** Questions that are open at PRD approval must be answered before development starts. A PRD with open architecture questions or unresolved design decisions is not ready for development — it will be decided ad-hoc during implementation, usually badly.\n- **Making the PRD too long.** A PRD that takes 2 hours to read will not be read by the team before development starts. Keep it to one focused session (15-30 min) — the full detail belongs in linked design docs, technical specs, and research reports, not in the PRD itself.\n- **Writing a PRD without loading this skill first.** The trigger\n  phrase \"PRD\" or \"product requirements\" should load this skill\n  before any writing begins. Writing from general knowledge produces\n  a document that may look correct but misses processkit-specific\n  conventions (Artifact storage, workitem linking, feature vs.\n  product PRD distinction).\n\n## Full reference\n\n### PRD vs. technical spec vs. design spec\n\n| Document | Owner | Answers | When written |\n|---|---|---|---|\n| PRD | Product manager | What and why | Before design and eng start |\n| Design spec | Designer | How it looks and feels | After PRD approval |\n| Technical spec | Engineering | How it's built | After design spec |\n\nThe PRD is the source of truth for requirements. Design and technical\nspecs are downstream — they should be consistent with the PRD, and\ncontradictions should trigger a PRD update, not a silent departure.\n\n### MoSCoW prioritization\n\n| Priority | Meaning | Implication |\n|---|---|---|\n| **Must** | The feature cannot ship without this | Block release if missing |\n| **Should** | High value but can be worked around temporarily | Include if time allows; don't block |\n| **Could** | Nice to have, low risk if cut | Cuts first when scope must shrink |\n| **Won't** | Explicitly out of scope for this version | Documents a conscious choice |\n\n### Linking to processkit context\n\nWhen the project uses processkit, link the PRD to:\n- The WorkItem(s) it spawns (list BACK-NNN IDs in the appendix)\n- Relevant decisions (`context\u002Fdecisions\u002F` or DECISIONS.md)\n- Research notes (Note entities with `type: reference`)\n\nSave the PRD as `context\u002Fartifacts\u002Fprd-[feature-name]-[date].md` or\nlink it as an Artifact entity in the index.\n\nThe PRD itself should be stored as an `Artifact` entity under\n`context\u002Fartifacts\u002Fprd-\u003Cproduct-or-feature>-\u003Cdate>.md` so it is\nindexed and queryable. Create the entity with:\n\n    spec:\n      name: \u003Cdescriptive name>\n      kind: document\n      location: context\u002Fartifacts\u002Fprd-\u003Cname>-\u003Cdate>.md\n      format: markdown\n      tags: [prd]\n",{"name":5,"metadata":57,"description":77},{"processkit":58},{"id":59,"uses":60,"layer":67,"created":68,"version":69,"category":50,"provides":70,"apiVersion":76},"SKILL-prd-writing",[61,64],{"skill":62,"purpose":63},"workitem-management","Link requirements to WorkItems in the project backlog.",{"skill":65,"purpose":66},"decision-record","Reference DecisionRecords that motivated requirements or resolved open questions.",2,1775606400000,"1.1.0",{"assets":71,"mcp_tools":72,"processes":73,"primitives":74},[],[],[5],[75],"Artifact","processkit.projectious.work\u002Fv1","Write a Product Requirements Document structured with problem statement, goals, user stories, scope, and success metrics.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.1\u002Fcontext\u002Fskills\u002Fproduct\u002Fprd-writing","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":86,"prompt":96,"zipAvailable":97},[87,90,93],{"tool":88,"command":89},"npx","npx skills add projectious-work\u002Fprocesskit --skill prd-writing",{"tool":91,"command":92},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill prd-writing",{"tool":94,"command":95},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill prd-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.1\u002Fcontext\u002Fskills\u002Fproduct\u002Fprd-writing\u002FSKILL.md",true,[],[100,125,144,165,182,199],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":109,"publishedAt":52},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[110,111,112,113,114,115,46,116,117,118,102,119,120,121,122,123,124],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":52},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[131],{"categoryNo":107,"categoryName":108,"taxonomyType":21,"taxonomyTypeDesc":22},[110,133,134,135,136,137,115,46,138,139,117,140,44,141,119,142,143],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","deterministic","contract","mode",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":52},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[110,151,152,112,113,153,115,46,154,155,156,157,119,158,159,160,161,162,163,164],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":52},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[110,118,172,112,115,173,174,138,175,154,117,176,177,119,178,179,159,180,122,181],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":52},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[189,190,191,192,115,48,193,194,46,195,196,197,198],"okf","compatibility","okf compatibility","validate","knowledge","format","export","bundles","bundle","import",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":52},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[110,206,207,112,113,153,115,173,46,116,154,208,117,156,119,179,159,160,209,124],"capability","capability management","queries","changes"]