[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NX3AAAJDBEEND76A98FZ8C":3,"skill-same:01M6NX3AAAJDBEEND76A98FZ8C":67},{"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":28,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6NX3AAAJDBEEND76A98FZ8C","writing-plans",null,"Use when you have a spec or requirements for a multi-step task, before touching code","mattonweb\u002Fai-assistant-foundry","mattonweb","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2309734?v=4","01M6NQYCY846TKYN2ZCRS71WQ7","Matt Johnson","01M6NQYD2NPAQEFVD8TW9W0SVX",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fmanage-agile\u002Fcblecker\u002Fwriting-plans\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40],"writing","writing plans","plans","spec","code","use","task","requirements","multi","multi-step task","you","for","2026-11-10 10:12:30",false,"---\nname: writing-plans\ndescription: Use when you have a spec or requirements for a multi-step task, before touching code\n---\n\n# Writing Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the implementation plan.\"\n\n**Context:** This should be run in a dedicated worktree (created by brainstorming skill).\n\n**Save plans to:** `docs\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n\n# [Feature Name] Implementation Plan\n\n> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies\u002Flibraries]\n\n---\n```\n\n## Task Structure\n\n```markdown\n\n### Task N: [Component Name]\n\n**Files:**\n- Create: `exact\u002Fpath\u002Fto\u002Ffile.py`\n- Modify: `exact\u002Fpath\u002Fto\u002Fexisting.py:123-145`\n- Test: `tests\u002Fexact\u002Fpath\u002Fto\u002Ftest.py`\n\n**Step 1: Write the failing test**\n\n```python\ndef test_specific_behavior():\n    result = function(input)\n    assert result == expected\n```\n\n**Step 2: Run test to verify it fails**\n\nRun: `pytest tests\u002Fpath\u002Ftest.py::test_name -v`\nExpected: FAIL with \"function not defined\"\n\n**Step 3: Write minimal implementation**\n\n```python\ndef function(input):\n    return expected\n```\n\n**Step 4: Run test to verify it passes**\n\nRun: `pytest tests\u002Fpath\u002Ftest.py::test_name -v`\nExpected: PASS\n\n**Step 5: Commit**\n\n```bash\ngit add tests\u002Fpath\u002Ftest.py src\u002Fpath\u002Ffile.py\ngit commit -m \"feat: add specific feature\"\n```\n```\n\n## Remember\n- Exact file paths always\n- Complete code in plan (not \"add validation\")\n- Exact commands with expected output\n- Reference relevant skills with @ syntax\n- DRY, YAGNI, TDD, frequent commits\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `docs\u002Fplans\u002F\u003Cfilename>.md`. Two execution options:**\n\n**1. Subagent-Driven (this session)** - I dispatch fresh subagent per task, review between tasks, fast iteration\n\n**2. Parallel Session (separate)** - Open new session with executing-plans, batch execution with checkpoints\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:**\n- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development\n- Stay in this session\n- Fresh subagent per task + code review\n\n**If Parallel Session chosen:**\n- Guide them to open new session in worktree\n- **REQUIRED SUB-SKILL:** New session uses superpowers:executing-plans\n","# Writing Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the implementation plan.\"\n\n**Context:** This should be run in a dedicated worktree (created by brainstorming skill).\n\n**Save plans to:** `docs\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n\n# [Feature Name] Implementation Plan\n\n> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies\u002Flibraries]\n\n---\n```\n\n## Task Structure\n\n```markdown\n\n### Task N: [Component Name]\n\n**Files:**\n- Create: `exact\u002Fpath\u002Fto\u002Ffile.py`\n- Modify: `exact\u002Fpath\u002Fto\u002Fexisting.py:123-145`\n- Test: `tests\u002Fexact\u002Fpath\u002Fto\u002Ftest.py`\n\n**Step 1: Write the failing test**\n\n```python\ndef test_specific_behavior():\n    result = function(input)\n    assert result == expected\n```\n\n**Step 2: Run test to verify it fails**\n\nRun: `pytest tests\u002Fpath\u002Ftest.py::test_name -v`\nExpected: FAIL with \"function not defined\"\n\n**Step 3: Write minimal implementation**\n\n```python\ndef function(input):\n    return expected\n```\n\n**Step 4: Run test to verify it passes**\n\nRun: `pytest tests\u002Fpath\u002Ftest.py::test_name -v`\nExpected: PASS\n\n**Step 5: Commit**\n\n```bash\ngit add tests\u002Fpath\u002Ftest.py src\u002Fpath\u002Ffile.py\ngit commit -m \"feat: add specific feature\"\n```\n```\n\n## Remember\n- Exact file paths always\n- Complete code in plan (not \"add validation\")\n- Exact commands with expected output\n- Reference relevant skills with @ syntax\n- DRY, YAGNI, TDD, frequent commits\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `docs\u002Fplans\u002F\u003Cfilename>.md`. Two execution options:**\n\n**1. Subagent-Driven (this session)** - I dispatch fresh subagent per task, review between tasks, fast iteration\n\n**2. Parallel Session (separate)** - Open new session with executing-plans, batch execution with checkpoints\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:**\n- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development\n- Stay in this session\n- Fresh subagent per task + code review\n\n**If Parallel Session chosen:**\n- Guide them to open new session in worktree\n- **REQUIRED SUB-SKILL:** New session uses superpowers:executing-plans\n",{"name":5,"description":7},"main","d8518247cb8ab8b2dac57a6be33543ffd23b97c5","manage-agile\u002Fcblecker\u002Fwriting-plans",0,"https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry","https:\u002F\u002Fgithub.com\u002Fmattonweb","2026-05-29 08:42:23",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add mattonweb\u002Fai-assistant-foundry --skill writing-plans",{"tool":59,"command":60},"bunx","bunx skills add mattonweb\u002Fai-assistant-foundry --skill writing-plans",{"tool":62,"command":63},"pnpm","pnpm dlx skills add mattonweb\u002Fai-assistant-foundry --skill writing-plans","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fmanage-agile\u002Fcblecker\u002Fwriting-plans\u002FSKILL.md",true,[],[68,94,108,127,148,174],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":76,"publishedAt":41},"01M6P02DENRHN6KVGYC55FKASJ","writing-clearly-and-concisely","Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsoftaworks\u002Fwriting-clearly-and-concisely\u002FSKILL.md",[74,75],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[77,29,78,79,40,80,81,82,83,84,85,34,86,87,88,89,90,91,92,93],"writing clearly and concisely","concisely","text","more","timeless","error","professional","prose","reports","read","Rules","commit messages","messages","error messages","ui","documentation","commit",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":41},"01M6P0286HZ8RWMFCCPC8HF7SC","crafting-effective-readmes","Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsoftaworks\u002Fcrafting-effective-readmes\u002FSKILL.md",[],[101,102,29,103,104,34,105,106,107],"crafting effective readmes","README","templates","type","project","guidance","files",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":117,"publishedAt":41},"01M6P025A41BBTPWVTZ3GFQVG6","wiki-architect","You are a documentation architect that produces structured wiki catalogues and onboarding guides from codebases.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsickn33\u002Fwiki-architect\u002FSKILL.md",[114],{"categoryNo":115,"categoryName":116,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000038","人力资源",[118,119,120,121,39,122,123,124,125,126,92],"wiki","architect","wiki architect","unknown","documentation architect","guides","structured","community","onboarding",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":41},"01M6P01NSKPXP77NWB4K0PXRK5","readme","You are an expert technical writer creating comprehensive project documentation. Your goal is to write a README.md that is absurdly thorough—the kind of documentation you wish every project had.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsickn33\u002Freadme\u002FSKILL.md",[],[102,134,135,136,39,137,138,105,139,140,46,141,142,143,144,145,92,146,147],"project documentation","tree","kind","expert","github","wish","writer","goal","write","technical writer","technical","https","write a readme","safe",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":41},"01M6P01GP0NEN8KT3A3SA6ZFVE","ubiquitous-language","Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions \"domain model\" or \"DDD\".","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fmattpocock\u002Fubiquitous-language\u002FSKILL.md",[],[155,156,34,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173],"ubiquitous language","language","extract","user","glossary","model","terms","ddd","create","build","true","canonical","style","define","harden","domain model","domain","terminology","conversation",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":182,"publishedAt":41},"01M6P01BJBP9XP4TDRT7QD1ZVA","technical-writing-style","Enforce clear, direct writing in software development documents including OKRs, PRDs, tech specs, architecture decision records (ADRs), git commit messages, PR descriptions, READMEs, changelogs, runbooks, incident postmortems, API docs, and onboarding guides. Trigger whenever a user asks to write, edit, revise, or review any of these document types. Also trigger when the user says writing \"sounds like AI\", \"feels robotic\", \"needs polish\", or asks to \"make it sound more natural\" in the context of technical or professional prose. Do not trigger for fiction, poetry, creative writing, academic papers, or legal documents unless the user explicitly asks for a more natural tone.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fmattnebr\u002Ftechnical-writing-style\u002FSKILL.md",[180,181],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[183,184,167,144,29,185,83,186,187,188,189,190,191,192,193,89,194,195,93,196],"writing style","technical writing style","technical writing","papers","types","runbooks","software development","incident","Poetry","decision","api","documents","architecture","review"]