[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RB9N2DCGAX2J300PNPY0M5":3,"skill-same:01M6RB9N2DCGAX2J300PNPY0M5":80},{"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":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6RB9N2DCGAX2J300PNPY0M5","write-a-spec",null,"Create a feature spec or refactor RFC through user interview, codebase exploration, and module design, then publish it as a GitHub issue or local Markdown file. Use when the user wants to write a PRD, RFC, refactor plan, product requirements document, change proposal, or plan a large feature or refactor.","Nairon-AI\u002Fagentic-starter-pack","Nairon-AI","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F260662138?v=4","01M6R8PZ1Y8CSQGFN61VACZGTH","Nairon AI","01M6R8PZ6184VR3BA88YZFBC3N",4,"MIT","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fplanning\u002Fwrite-a-spec\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"spec","write a spec","write","requirements","design","when","user interview","codebase exploration","proposal","as","module","feature","file","local","exploration","document","use","interview","create","publish","2026-11-10 10:12:30",false,"---\nname: write-a-spec\ndescription: Create a feature spec or refactor RFC through user interview, codebase exploration, and module design, then publish it as a GitHub issue or local Markdown file. Use when the user wants to write a PRD, RFC, refactor plan, product requirements document, change proposal, or plan a large feature or refactor.\n---\n\n# Write a Spec\n\nCreate a durable planning document for a significant change. This skill covers both:\n\n- feature specs \u002F PRDs\n- refactor RFCs \u002F change plans\n\n## 1. Pick the mode\n\nDecide which mode fits the request:\n\n- **Feature spec** when the user is planning new product behavior, a major feature, or a product requirement\n- **Refactor RFC** when the user is restructuring an existing system, improving architecture, or breaking a refactor into safe incremental steps\n\nIf the request is ambiguous, ask one short question to resolve the mode.\n\n## 2. Gather the problem space\n\nStart with a detailed description from the user, then explore the repo to verify assumptions and understand the current state.\n\nYou are trying to understand:\n\n- the real problem\n- the affected users or developers\n- current constraints\n- existing interfaces and modules\n- what is already working\n\n## 3. Interview until the scope is clear\n\nWork through open questions one at a time.\n\nFor **feature specs**, clarify:\n\n- desired user outcomes\n- key user stories\n- boundaries of the feature\n- major product and technical constraints\n\nFor **refactor RFCs**, clarify:\n\n- what pain is being removed\n- alternative options that were considered\n- exact scope vs out-of-scope\n- what a safe migration path looks like\n\n## 4. Explore module boundaries and tests\n\nLook for the major modules you would build or modify.\n\nActively prefer **deep modules**:\n\n- small interfaces\n- large implementation hidden behind them\n- testable at the boundary\n\nCheck existing test coverage in the affected area and note what good new tests would verify.\n\n## 5. Write the document\n\nIf GitHub is available, publish the result as an issue. Otherwise, write it to `.\u002Fplans\u002F`.\n\nUse:\n\n- `.\u002Fplans\u002F\u003Cslug>-spec.md` for feature specs\n- `.\u002Fplans\u002Frefactor-\u003Cslug>.md` for refactor RFCs\n\n### Feature spec template\n\n```md\n## Problem Statement\n\n[The problem from the user's perspective]\n\n## Solution\n\n[The proposed solution from the user's perspective]\n\n## User Stories\n\n1. As a \u003Cactor>, I want \u003Cfeature>, so that \u003Cbenefit>\n\n## Implementation Decisions\n\n- modules to build or modify\n- interface changes\n- architectural decisions\n- schema or API contracts\n\n## Testing Decisions\n\n- what good tests verify\n- which modules need tests\n- prior art in the codebase\n\n## Out of Scope\n\n[Not included in this spec]\n\n## Further Notes\n\n[Anything else worth recording]\n```\n\n### Refactor RFC template\n\n```md\n## Problem Statement\n\n[The developer-facing problem]\n\n## Solution\n\n[The proposed refactor approach]\n\n## Commits\n\n1. [Tiny commit that leaves the system working]\n2. [Next tiny commit]\n\n## Decision Document\n\n- modules to build or modify\n- interface changes\n- architectural decisions\n- migration or rollout constraints\n\n## Testing Decisions\n\n- what good tests verify\n- what existing coverage exists\n- what new boundary tests are needed\n\n## Out of Scope\n\n[Not included in this refactor]\n\n## Further Notes\n\n[Optional]\n```\n\n## Gotchas\n\n- Do not include file paths or code snippets in the durable document.\n- The value is in clarifying scope and decisions, not producing a long wall of text.\n- Refactor plans should break work into tiny commits that keep the codebase working.\n- Feature specs should be extensive on user stories, not just implementation notes.\n","# Write a Spec\n\nCreate a durable planning document for a significant change. This skill covers both:\n\n- feature specs \u002F PRDs\n- refactor RFCs \u002F change plans\n\n## 1. Pick the mode\n\nDecide which mode fits the request:\n\n- **Feature spec** when the user is planning new product behavior, a major feature, or a product requirement\n- **Refactor RFC** when the user is restructuring an existing system, improving architecture, or breaking a refactor into safe incremental steps\n\nIf the request is ambiguous, ask one short question to resolve the mode.\n\n## 2. Gather the problem space\n\nStart with a detailed description from the user, then explore the repo to verify assumptions and understand the current state.\n\nYou are trying to understand:\n\n- the real problem\n- the affected users or developers\n- current constraints\n- existing interfaces and modules\n- what is already working\n\n## 3. Interview until the scope is clear\n\nWork through open questions one at a time.\n\nFor **feature specs**, clarify:\n\n- desired user outcomes\n- key user stories\n- boundaries of the feature\n- major product and technical constraints\n\nFor **refactor RFCs**, clarify:\n\n- what pain is being removed\n- alternative options that were considered\n- exact scope vs out-of-scope\n- what a safe migration path looks like\n\n## 4. Explore module boundaries and tests\n\nLook for the major modules you would build or modify.\n\nActively prefer **deep modules**:\n\n- small interfaces\n- large implementation hidden behind them\n- testable at the boundary\n\nCheck existing test coverage in the affected area and note what good new tests would verify.\n\n## 5. Write the document\n\nIf GitHub is available, publish the result as an issue. Otherwise, write it to `.\u002Fplans\u002F`.\n\nUse:\n\n- `.\u002Fplans\u002F\u003Cslug>-spec.md` for feature specs\n- `.\u002Fplans\u002Frefactor-\u003Cslug>.md` for refactor RFCs\n\n### Feature spec template\n\n```md\n## Problem Statement\n\n[The problem from the user's perspective]\n\n## Solution\n\n[The proposed solution from the user's perspective]\n\n## User Stories\n\n1. As a \u003Cactor>, I want \u003Cfeature>, so that \u003Cbenefit>\n\n## Implementation Decisions\n\n- modules to build or modify\n- interface changes\n- architectural decisions\n- schema or API contracts\n\n## Testing Decisions\n\n- what good tests verify\n- which modules need tests\n- prior art in the codebase\n\n## Out of Scope\n\n[Not included in this spec]\n\n## Further Notes\n\n[Anything else worth recording]\n```\n\n### Refactor RFC template\n\n```md\n## Problem Statement\n\n[The developer-facing problem]\n\n## Solution\n\n[The proposed refactor approach]\n\n## Commits\n\n1. [Tiny commit that leaves the system working]\n2. [Next tiny commit]\n\n## Decision Document\n\n- modules to build or modify\n- interface changes\n- architectural decisions\n- migration or rollout constraints\n\n## Testing Decisions\n\n- what good tests verify\n- what existing coverage exists\n- what new boundary tests are needed\n\n## Out of Scope\n\n[Not included in this refactor]\n\n## Further Notes\n\n[Optional]\n```\n\n## Gotchas\n\n- Do not include file paths or code snippets in the durable document.\n- The value is in clarifying scope and decisions, not producing a long wall of text.\n- Refactor plans should break work into tiny commits that keep the codebase working.\n- Feature specs should be extensive on user stories, not just implementation notes.\n",{"name":5,"description":7},"main","c9d0c408715983e993b2f9ebffdbfa7f10153bcb","planning\u002Fwrite-a-spec",0,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack","https:\u002F\u002Fgithub.com\u002FNairon-AI","https:\u002F\u002Fwww.naironai.com\u002F","Building the future of Work","2026-09-20 17:40:05",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add Nairon-AI\u002Fagentic-starter-pack --skill write-a-spec",{"tool":72,"command":73},"bunx","bunx skills add Nairon-AI\u002Fagentic-starter-pack --skill write-a-spec",{"tool":75,"command":76},"pnpm","pnpm dlx skills add Nairon-AI\u002Fagentic-starter-pack --skill write-a-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fplanning\u002Fwrite-a-spec\u002FSKILL.md",true,[],[81,111,131,151,171,193],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":93,"publishedAt":52},"01M6RBCG630Y8X99XWR9Q4GYNY","writing-shape","Take a markdown file of raw material and shape it into an article through a conversational session — drafting candidate openings, growing the piece paragraph by paragraph, arguing about format (lists, tables, callouts, quotes) at each step. Use when the user has a pile of notes, fragments, or a rough draft and wants help turning it into something publishable.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-shape\u002FSKILL.md",[87,90],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":91,"categoryName":92,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[94,95,96,97,98,44,99,100,101,48,102,103,104,105,106,107,108,109,110,37],"writing","writing shape","shape","notes","help","markdown","format","session","take","draft","article","material","it","about","quotes","at","candidate",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":119,"publishedAt":52},"01M6RBCCCB1KMF01P5SYGFWBSW","writing-fragments","Grilling session that mines the user for fragments — heterogeneous nuggets of writing (claims, vignettes, sharp sentences, half-thoughts) — and appends them to a single document as raw material for a future article. Use when the user wants to develop ideas before imposing structure, or mentions \"fragments\", \"ideate\", or \"raw material\" for writing.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-fragments\u002FSKILL.md",[117,118],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":29,"taxonomyTypeDesc":30},[94,120,121,122,123,124,101,48,47,125,126,104,41,105,127,128,129,130,37],"writing fragments","grilling","ideate","develop","user","structure","ideas","sharp","claims","for","single",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":139,"publishedAt":52},"01M6RBC8V7NHHKMTAZB4BPXVYQ","writing-beats","Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-beats\u002FSKILL.md",[137,138],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":29,"taxonomyTypeDesc":30},[94,140,141,34,48,142,143,96,144,145,146,104,147,41,148,105,149,150,129,37],"writing beats","choose","assemble","only","journey","next","options","end","style","narrative","argument",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":159,"publishedAt":52},"01M6RBC58SG5Y5SC4ZV4ZNEFHC","stop-slop","Remove AI writing patterns from prose. Use when drafting, editing, or reviewing text to eliminate predictable AI tells.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fstop-slop\u002FSKILL.md",[157,158],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":29,"taxonomyTypeDesc":30},[160,161,162,94,163,164,165,166,167,48,168,169,170,129,37],"stop","stop slop","slop","content","https","text","editing","remove","prose","patterns","drafts",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":179,"publishedAt":52},"01M6RBBJTTCJ7KZCP16G9JDFZH","humanizer","Remove signs of AI-generated writing from text. Use when editing or reviewing\ntext to make it sound more natural and human-written. Based on Wikipedia's\ncomprehensive \"Signs of AI writing\" guide. Detects and fixes patterns including:\ninflated symbolism, promotional language, superficial -ing analyses, vague\nattributions, em dash overuse, rule of three, AI vocabulary words, passive\nvoice, negative parallelisms, and filler phrases.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fhumanizer\u002FSKILL.md",[177,178],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":29,"taxonomyTypeDesc":30},[173,94,180,181,165,182,34,183,184,167,185,186,169,187,188,189,190,191,192,37],"code","em dash","read","edit","generated","guide","opencode","three","human","make","wikipedia","vague","dash",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":52},"01M6RBBEQKJ5HRH8AV9J85QB1T","feedback","Prepare, deliver, and debrief timely interpersonal feedback using a question-first coaching flow, observable behavior, owned experience, and concrete impact. Use when drafting feedback, coaching managers, rehearsing a feedback conversation, praising specific behavior, or reviewing whether feedback landed.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Ffeedback\u002FSKILL.md",[],[195,200,201,202,203,204,48,205,206,207,208,209,37,210],"prepare","flow","first","question","behavior","conversation","coaching","debrief","impact","managers","deliver"]