[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71PAXFM488X9ARXK0T04TF5":3,"skill-same:01M71PAXFM488X9ARXK0T04TF5":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M71PAXFM488X9ARXK0T04TF5","write-spec",null,"Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"write spec","spec","write","document","use","problem statement","feature","metrics","idea","scoping","request","product","work","vague","ask","when","acceptance","knowledge","problem","user request","2026-11-10 13:02:02",false,"---\nname: write-spec\ndescription: \"Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.\"\ntags: []\ntools: []\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\nsource_path: \"product-management\u002Fskills\u002Fwrite-spec\"\nsource_commit: 8444efcd48f7012f09797778a36a33e73d0861f4\n---\n# Write Spec\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](..\u002F..\u002FCONNECTORS.md).\n\nWrite a feature specification or product requirements document (PRD).\n\n## Usage\n\n```\n\u002Fwrite-spec $ARGUMENTS\n```\n\n## Workflow\n\n### 1. Understand the Feature\n\nAsk the user what they want to spec. Accept any of:\n- A feature name (\"SSO support\")\n- A problem statement (\"Enterprise customers keep asking for centralized auth\")\n- A user request (\"Users want to export their data as CSV\")\n- A vague idea (\"We should do something about onboarding drop-off\")\n\n### 2. Gather Context\n\nAsk the user for the following. Be conversational — do not dump all questions at once. Ask the most important ones first and fill in gaps as you go:\n\n- **User problem**: What problem does this solve? Who experiences it?\n- **Target users**: Which user segment(s) does this serve?\n- **Success metrics**: How will we know this worked?\n- **Constraints**: Technical constraints, timeline, regulatory requirements, dependencies\n- **Prior art**: Has this been attempted before? Are there existing solutions?\n\n### 3. Pull Context from Connected Tools\n\nIf **~~project tracker** is connected:\n- Search for related tickets, epics, or features\n- Pull in any existing requirements or acceptance criteria\n- Identify dependencies on other work items\n\nIf **~~knowledge base** is connected:\n- Search for related research documents, prior specs, or design docs\n- Pull in relevant user research findings\n- Find related meeting notes or decision records\n\nIf **~~design** is connected:\n- Pull related mockups, wireframes, or design explorations\n- Search for design system components relevant to the feature\n\nIf these tools are not connected, work entirely from what the user provides. Do not ask the user to connect tools — just proceed with available information.\n\n### 4. Generate the PRD\n\nProduce a structured PRD with these sections. See **PRD Structure** below for detailed guidance on what each section should contain.\n\n- **Problem Statement**: The user problem, who is affected, and impact of not solving it (2-3 sentences)\n- **Goals**: 3-5 specific, measurable outcomes tied to user or business metrics\n- **Non-Goals**: 3-5 things explicitly out of scope, with brief rationale for each\n- **User Stories**: Standard format (\"As a [user type], I want [capability] so that [benefit]\"), grouped by persona\n- **Requirements**: Categorized as Must-Have (P0), Nice-to-Have (P1), and Future Considerations (P2), each with acceptance criteria\n- **Success Metrics**: Leading indicators (change quickly) and lagging indicators (change over time), with specific targets\n- **Open Questions**: Unresolved questions tagged with who needs to answer (engineering, design, legal, data)\n- **Timeline Considerations**: Hard deadlines, dependencies, and phasing\n\n### 5. Review and Iterate\n\nAfter generating the PRD:\n- Ask the user if any sections need adjustment\n- Offer to expand on specific sections\n- Offer to create follow-up artifacts (design brief, engineering ticket breakdown, stakeholder pitch)\n\n## PRD Structure\n\n### Problem Statement\n- Describe the user problem in 2-3 sentences\n- Who experiences this problem and how often\n- What is the cost of not solving it (user pain, business impact, competitive risk)\n- Ground this in evidence: user research, support data, metrics, or customer feedback\n\n### Goals\n- 3-5 specific, measurable outcomes this feature should achieve\n- Each goal should answer: \"How will we know this succeeded?\"\n- Distinguish between user goals (what users get) and business goals (what the company gets)\n- Goals should be outcomes, not outputs (\"reduce time to first value by 50%\" not \"build onboarding wizard\")\n\n### Non-Goals\n- 3-5 things this feature explicitly will NOT do\n- Adjacent capabilities that are out of scope for this version\n- For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)\n- Non-goals prevent scope creep during implementation and set expectations with stakeholders\n\n### User Stories\nWrite user stories in standard format: \"As a [user type], I want [capability] so that [benefit]\"\n\nGuidelines:\n- The user type should be specific enough to be meaningful (\"enterprise admin\" not just \"user\")\n- The capability should describe what they want to accomplish, not how\n- The benefit should explain the \"why\" — what value does this deliver\n- Include edge cases: error states, empty states, boundary conditions\n- Include different user types if the feature serves multiple personas\n- Order by priority — most important stories first\n\nExample:\n- \"As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials\"\n- \"As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password\"\n- \"As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working\"\n\n### Requirements\n\n**Must-Have (P0)**: The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: \"If we cut this, does the feature still solve the core problem?\" If no, it is P0.\n\n**Nice-to-Have (P1)**: Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.\n\n**Future Considerations (P2)**: Explicitly out of scope for v1 but we want to design in a way that supports them later. Documenting these prevents accidental architectural decisions that make them hard later.\n\nFor each requirement:\n- Write a clear, unambiguous description of the expected behavior\n- Include acceptance criteria (see below)\n- Note any technical considerations or constraints\n- Flag dependencies on other teams or systems\n\n### Open Questions\n- Questions that need answers before or during implementation\n- Tag each with who should answer (engineering, design, legal, data, stakeholder)\n- Distinguish between blocking questions (must answer before starting) and non-blocking (can resolve during implementation)\n\n### Timeline Considerations\n- Hard deadlines (contractual commitments, events, compliance dates)\n- Dependencies on other teams' work or releases\n- Suggested phasing if the feature is too large for one release\n\n## User Story Writing\n\nGood user stories are:\n- **Independent**: Can be developed and delivered on their own\n- **Negotiable**: Details can be discussed, the story is not a contract\n- **Valuable**: Delivers value to the user (not just the team)\n- **Estimable**: The team can roughly estimate the effort\n- **Small**: Can be completed in one sprint\u002Fiteration\n- **Testable**: There is a clear way to verify it works\n\n### Common Mistakes in User Stories\n- Too vague: \"As a user, I want the product to be faster\" — what specifically should be faster?\n- Solution-prescriptive: \"As a user, I want a dropdown menu\" — describe the need, not the UI widget\n- No benefit: \"As a user, I want to click a button\" — why? What does it accomplish?\n- Too large: \"As a user, I want to manage my team\" — break this into specific capabilities\n- Internal focus: \"As the engineering team, we want to refactor the database\" — this is a task, not a user story\n\n## Requirements Categorization\n\n### MoSCoW Framework\n- **Must have**: Without these, the feature is not viable. Non-negotiable.\n- **Should have**: Important but not critical for launch. High-priority fast follows.\n- **Could have**: Desirable if time permits. Will not delay delivery if cut.\n- **Won't have (this time)**: Explicitly out of scope. May revisit in future versions.\n\n### Tips for Categorization\n- Be ruthless about P0s. The tighter the must-have list, the faster you ship and learn.\n- If everything is P0, nothing is P0. Challenge every must-have: \"Would we really not ship without this?\"\n- P1s should be things you are confident you will build soon, not a wish list.\n- P2s are architectural insurance — they guide design decisions even though you are not building them now.\n\n## Success Metrics Definition\n\n### Leading Indicators\nMetrics that change quickly after launch (days to weeks):\n- **Adoption rate**: % of eligible users who try the feature\n- **Activation rate**: % of users who complete the core action\n- **Task completion rate**: % of users who successfully accomplish their goal\n- **Time to complete**: How long the core workflow takes\n- **Error rate**: How often users encounter errors or dead ends\n- **Feature usage frequency**: How often users return to use the feature\n\n### Lagging Indicators\nMetrics that take time to develop (weeks to months):\n- **Retention impact**: Does this feature improve user retention?\n- **Revenue impact**: Does this drive upgrades, expansion, or new revenue?\n- **NPS \u002F satisfaction change**: Does this improve how users feel about the product?\n- **Support ticket reduction**: Does this reduce support load?\n- **Competitive win rate**: Does this help win more deals?\n\n### Setting Targets\n- Targets should be specific: \"50% adoption within 30 days\" not \"high adoption\"\n- Base targets on comparable features, industry benchmarks, or explicit hypotheses\n- Set a \"success\" threshold and a \"stretch\" target\n- Define the measurement method: what tool, what query, what time window\n- Specify when you will evaluate: 1 week, 1 month, 1 quarter post-launch\n\n## Acceptance Criteria\n\nWrite acceptance criteria in Given\u002FWhen\u002FThen format or as a checklist:\n\n**Given\u002FWhen\u002FThen**:\n- Given [precondition or context]\n- When [action the user takes]\n- Then [expected outcome]\n\nExample:\n- Given the admin has configured SSO for their organization\n- When a team member visits the login page\n- Then they are automatically redirected to the organization's SSO provider\n\n**Checklist format**:\n- [ ] Admin can enter SSO provider URL in organization settings\n- [ ] Team members see \"Log in with SSO\" button on login page\n- [ ] SSO login creates a new account if one does not exist\n- [ ] SSO login links to existing account if email matches\n- [ ] Failed SSO attempts show a clear error message\n\n### Tips for Acceptance Criteria\n- Cover the happy path, error cases, and edge cases\n- Be specific about the expected behavior, not the implementation\n- Include what should NOT happen (negative test cases)\n- Each criterion should be independently testable\n- Avoid ambiguous words: \"fast\", \"user-friendly\", \"intuitive\" — define what these mean concretely\n\n## Scope Management\n\n### Recognizing Scope Creep\nScope creep happens when:\n- Requirements keep getting added after the spec is approved\n- \"Small\" additions accumulate into a significantly larger project\n- The team is building features no user asked for (\"while we're at it...\")\n- The launch date keeps moving without explicit re-scoping\n- Stakeholders add requirements without removing anything\n\n### Preventing Scope Creep\n- Write explicit non-goals in every spec\n- Require that any scope addition comes with a scope removal or timeline extension\n- Separate \"v1\" from \"v2\" clearly in the spec\n- Review the spec against the original problem statement — does everything serve it?\n- Time-box investigations: \"If we cannot figure out X in 2 days, we cut it\"\n- Create a \"parking lot\" for good ideas that are not in scope\n\n## Output Format\n\nUse markdown with clear headers. Keep the document scannable — busy stakeholders should be able to read just the headers and bold text to get the gist.\n\n## Tips\n\n- Be opinionated about scope. It is better to have a tight, well-defined spec than an expansive vague one.\n- If the user's idea is too big for one spec, suggest breaking it into phases and spec the first phase.\n- Success metrics should be specific and measurable, not vague (\"improve user experience\").\n- Non-goals are as important as goals. They prevent scope creep during implementation.\n- Open questions should be genuinely open — do not include questions you can answer from context.\n","# Write Spec\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](..\u002F..\u002FCONNECTORS.md).\n\nWrite a feature specification or product requirements document (PRD).\n\n## Usage\n\n```\n\u002Fwrite-spec $ARGUMENTS\n```\n\n## Workflow\n\n### 1. Understand the Feature\n\nAsk the user what they want to spec. Accept any of:\n- A feature name (\"SSO support\")\n- A problem statement (\"Enterprise customers keep asking for centralized auth\")\n- A user request (\"Users want to export their data as CSV\")\n- A vague idea (\"We should do something about onboarding drop-off\")\n\n### 2. Gather Context\n\nAsk the user for the following. Be conversational — do not dump all questions at once. Ask the most important ones first and fill in gaps as you go:\n\n- **User problem**: What problem does this solve? Who experiences it?\n- **Target users**: Which user segment(s) does this serve?\n- **Success metrics**: How will we know this worked?\n- **Constraints**: Technical constraints, timeline, regulatory requirements, dependencies\n- **Prior art**: Has this been attempted before? Are there existing solutions?\n\n### 3. Pull Context from Connected Tools\n\nIf **~~project tracker** is connected:\n- Search for related tickets, epics, or features\n- Pull in any existing requirements or acceptance criteria\n- Identify dependencies on other work items\n\nIf **~~knowledge base** is connected:\n- Search for related research documents, prior specs, or design docs\n- Pull in relevant user research findings\n- Find related meeting notes or decision records\n\nIf **~~design** is connected:\n- Pull related mockups, wireframes, or design explorations\n- Search for design system components relevant to the feature\n\nIf these tools are not connected, work entirely from what the user provides. Do not ask the user to connect tools — just proceed with available information.\n\n### 4. Generate the PRD\n\nProduce a structured PRD with these sections. See **PRD Structure** below for detailed guidance on what each section should contain.\n\n- **Problem Statement**: The user problem, who is affected, and impact of not solving it (2-3 sentences)\n- **Goals**: 3-5 specific, measurable outcomes tied to user or business metrics\n- **Non-Goals**: 3-5 things explicitly out of scope, with brief rationale for each\n- **User Stories**: Standard format (\"As a [user type], I want [capability] so that [benefit]\"), grouped by persona\n- **Requirements**: Categorized as Must-Have (P0), Nice-to-Have (P1), and Future Considerations (P2), each with acceptance criteria\n- **Success Metrics**: Leading indicators (change quickly) and lagging indicators (change over time), with specific targets\n- **Open Questions**: Unresolved questions tagged with who needs to answer (engineering, design, legal, data)\n- **Timeline Considerations**: Hard deadlines, dependencies, and phasing\n\n### 5. Review and Iterate\n\nAfter generating the PRD:\n- Ask the user if any sections need adjustment\n- Offer to expand on specific sections\n- Offer to create follow-up artifacts (design brief, engineering ticket breakdown, stakeholder pitch)\n\n## PRD Structure\n\n### Problem Statement\n- Describe the user problem in 2-3 sentences\n- Who experiences this problem and how often\n- What is the cost of not solving it (user pain, business impact, competitive risk)\n- Ground this in evidence: user research, support data, metrics, or customer feedback\n\n### Goals\n- 3-5 specific, measurable outcomes this feature should achieve\n- Each goal should answer: \"How will we know this succeeded?\"\n- Distinguish between user goals (what users get) and business goals (what the company gets)\n- Goals should be outcomes, not outputs (\"reduce time to first value by 50%\" not \"build onboarding wizard\")\n\n### Non-Goals\n- 3-5 things this feature explicitly will NOT do\n- Adjacent capabilities that are out of scope for this version\n- For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)\n- Non-goals prevent scope creep during implementation and set expectations with stakeholders\n\n### User Stories\nWrite user stories in standard format: \"As a [user type], I want [capability] so that [benefit]\"\n\nGuidelines:\n- The user type should be specific enough to be meaningful (\"enterprise admin\" not just \"user\")\n- The capability should describe what they want to accomplish, not how\n- The benefit should explain the \"why\" — what value does this deliver\n- Include edge cases: error states, empty states, boundary conditions\n- Include different user types if the feature serves multiple personas\n- Order by priority — most important stories first\n\nExample:\n- \"As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials\"\n- \"As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password\"\n- \"As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working\"\n\n### Requirements\n\n**Must-Have (P0)**: The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: \"If we cut this, does the feature still solve the core problem?\" If no, it is P0.\n\n**Nice-to-Have (P1)**: Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.\n\n**Future Considerations (P2)**: Explicitly out of scope for v1 but we want to design in a way that supports them later. Documenting these prevents accidental architectural decisions that make them hard later.\n\nFor each requirement:\n- Write a clear, unambiguous description of the expected behavior\n- Include acceptance criteria (see below)\n- Note any technical considerations or constraints\n- Flag dependencies on other teams or systems\n\n### Open Questions\n- Questions that need answers before or during implementation\n- Tag each with who should answer (engineering, design, legal, data, stakeholder)\n- Distinguish between blocking questions (must answer before starting) and non-blocking (can resolve during implementation)\n\n### Timeline Considerations\n- Hard deadlines (contractual commitments, events, compliance dates)\n- Dependencies on other teams' work or releases\n- Suggested phasing if the feature is too large for one release\n\n## User Story Writing\n\nGood user stories are:\n- **Independent**: Can be developed and delivered on their own\n- **Negotiable**: Details can be discussed, the story is not a contract\n- **Valuable**: Delivers value to the user (not just the team)\n- **Estimable**: The team can roughly estimate the effort\n- **Small**: Can be completed in one sprint\u002Fiteration\n- **Testable**: There is a clear way to verify it works\n\n### Common Mistakes in User Stories\n- Too vague: \"As a user, I want the product to be faster\" — what specifically should be faster?\n- Solution-prescriptive: \"As a user, I want a dropdown menu\" — describe the need, not the UI widget\n- No benefit: \"As a user, I want to click a button\" — why? What does it accomplish?\n- Too large: \"As a user, I want to manage my team\" — break this into specific capabilities\n- Internal focus: \"As the engineering team, we want to refactor the database\" — this is a task, not a user story\n\n## Requirements Categorization\n\n### MoSCoW Framework\n- **Must have**: Without these, the feature is not viable. Non-negotiable.\n- **Should have**: Important but not critical for launch. High-priority fast follows.\n- **Could have**: Desirable if time permits. Will not delay delivery if cut.\n- **Won't have (this time)**: Explicitly out of scope. May revisit in future versions.\n\n### Tips for Categorization\n- Be ruthless about P0s. The tighter the must-have list, the faster you ship and learn.\n- If everything is P0, nothing is P0. Challenge every must-have: \"Would we really not ship without this?\"\n- P1s should be things you are confident you will build soon, not a wish list.\n- P2s are architectural insurance — they guide design decisions even though you are not building them now.\n\n## Success Metrics Definition\n\n### Leading Indicators\nMetrics that change quickly after launch (days to weeks):\n- **Adoption rate**: % of eligible users who try the feature\n- **Activation rate**: % of users who complete the core action\n- **Task completion rate**: % of users who successfully accomplish their goal\n- **Time to complete**: How long the core workflow takes\n- **Error rate**: How often users encounter errors or dead ends\n- **Feature usage frequency**: How often users return to use the feature\n\n### Lagging Indicators\nMetrics that take time to develop (weeks to months):\n- **Retention impact**: Does this feature improve user retention?\n- **Revenue impact**: Does this drive upgrades, expansion, or new revenue?\n- **NPS \u002F satisfaction change**: Does this improve how users feel about the product?\n- **Support ticket reduction**: Does this reduce support load?\n- **Competitive win rate**: Does this help win more deals?\n\n### Setting Targets\n- Targets should be specific: \"50% adoption within 30 days\" not \"high adoption\"\n- Base targets on comparable features, industry benchmarks, or explicit hypotheses\n- Set a \"success\" threshold and a \"stretch\" target\n- Define the measurement method: what tool, what query, what time window\n- Specify when you will evaluate: 1 week, 1 month, 1 quarter post-launch\n\n## Acceptance Criteria\n\nWrite acceptance criteria in Given\u002FWhen\u002FThen format or as a checklist:\n\n**Given\u002FWhen\u002FThen**:\n- Given [precondition or context]\n- When [action the user takes]\n- Then [expected outcome]\n\nExample:\n- Given the admin has configured SSO for their organization\n- When a team member visits the login page\n- Then they are automatically redirected to the organization's SSO provider\n\n**Checklist format**:\n- [ ] Admin can enter SSO provider URL in organization settings\n- [ ] Team members see \"Log in with SSO\" button on login page\n- [ ] SSO login creates a new account if one does not exist\n- [ ] SSO login links to existing account if email matches\n- [ ] Failed SSO attempts show a clear error message\n\n### Tips for Acceptance Criteria\n- Cover the happy path, error cases, and edge cases\n- Be specific about the expected behavior, not the implementation\n- Include what should NOT happen (negative test cases)\n- Each criterion should be independently testable\n- Avoid ambiguous words: \"fast\", \"user-friendly\", \"intuitive\" — define what these mean concretely\n\n## Scope Management\n\n### Recognizing Scope Creep\nScope creep happens when:\n- Requirements keep getting added after the spec is approved\n- \"Small\" additions accumulate into a significantly larger project\n- The team is building features no user asked for (\"while we're at it...\")\n- The launch date keeps moving without explicit re-scoping\n- Stakeholders add requirements without removing anything\n\n### Preventing Scope Creep\n- Write explicit non-goals in every spec\n- Require that any scope addition comes with a scope removal or timeline extension\n- Separate \"v1\" from \"v2\" clearly in the spec\n- Review the spec against the original problem statement — does everything serve it?\n- Time-box investigations: \"If we cannot figure out X in 2 days, we cut it\"\n- Create a \"parking lot\" for good ideas that are not in scope\n\n## Output Format\n\nUse markdown with clear headers. Keep the document scannable — busy stakeholders should be able to read just the headers and bold text to get the gist.\n\n## Tips\n\n- Be opinionated about scope. It is better to have a tight, well-defined spec than an expansive vague one.\n- If the user's idea is too big for one spec, suggest breaking it into phases and spec the first phase.\n- Success metrics should be specific and measurable, not vague (\"improve user experience\").\n- Non-goals are as important as goals. They prevent scope creep during implementation.\n- Open questions should be genuinely open — do not include questions you can answer from context.\n",{"name":5,"tags":49,"tools":50,"source":51,"license":14,"description":7,"source_path":52,"source_commit":53},[],[],"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins","product-management\u002Fskills\u002Fwrite-spec","8444efcd48f7012f09797778a36a33e73d0861f4","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec",2,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-10 01:53:48",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add monoes\u002Fmonomind --skill write-spec",{"tool":69,"command":70},"bunx","bunx skills add monoes\u002Fmonomind --skill write-spec",{"tool":72,"command":73},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill write-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",11607,[83,109,141,166,193,215],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":44},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[90,91,92,93,94,95,96,41,97,98,99,100,101,102,103,104,105,106,107,108],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","impact","query","snark","review","monomind","security review","stark","zettelkasten","cryptography","security","org","blockchain",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":113,"licenseFileUrl":114,"sourceHtmlUrl":115,"categories":116,"keywords":125,"publishedAt":44},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[117,122],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[126,127,128,94,129,130,39,131,98,132,133,134,35,26,135,136,137,138,139,140],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","commands","paths","suggest","coding","context","ZeRO",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":145,"sourceHtmlUrl":146,"categories":147,"keywords":151,"publishedAt":44},"01M71PASSZY800C0RPEARBS918","write-query","Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[148],{"categoryNo":149,"categoryName":150,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[98,26,152,153,154,155,41,28,39,156,157,158,159,36,160,161,162,163,164,165],"write query","postgres","for","snowflake","best practices","natural-language","with","multi","github","sql","https","syntax","plugins","data",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":178,"publishedAt":44},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[172,175],{"categoryNo":173,"categoryName":174,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":176,"categoryName":177,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000023","Skill与智能体开发",[179,180,181,182,154,183,184,185,186,97,187,188,189,98,101,160,190,191,192,162],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":200,"publishedAt":44},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[199],{"categoryNo":176,"categoryName":177,"taxonomyType":120,"taxonomyTypeDesc":121},[181,201,202,203,204,205,206,154,207,208,132,209,210,211,101,160,212,213,162,214],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":221,"publishedAt":44},"01M71PAHFJHG641X0RR432KB3G","worker-specialist","Org role guidance for a worker specialist: execute one assigned, well-scoped task with precision and report status honestly at real milestones. Covers confirming done-criteria first, surfacing blockers immediately and sharing intermediate results with peers.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworker-specialist\u002FSKILL.md",[],[222,223,224,154,225,226,227,228,229,230,158,231,101,160,232,213,233,234,235,162],"worker","worker specialist","specialist","scoped","milestones","done","one","coordination","task","first","results","report status","sharing","at"]