[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BZG1EPA3CSJJWEED3ZFPFE":3,"skill-same:01M6BZG1EPA3CSJJWEED3ZFPFE":53},{"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":18,"publishedAt":25,"linkOnly":26,"markdownContent":27,"markdownBody":28,"frontMatter":29,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":36,"ownerHtmlUrl":37,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":38,"install":39,"resources":52},"01M6BZG1EPA3CSJJWEED3ZFPFE","auto_task.create_plan_for_feature",null,"Break a complex feature into an ordered PR plan, with a spec per complex PR","causify-ai\u002Fhelpers","causify-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F121828442?v=4","01M6BZFTHW2MQR7FWK8CDW0DRA","Causify.AI","01M6BZFTPJ193AB5N089Z82HQG",155,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fauto_task.create_plan_for_feature\u002FSKILL.md",[],[19,20,21,22,23,24],"create","create plan","plan","auto task create plan for feature","spec","pr","2026-11-10 10:12:30",false,"---\ndescription: Break a complex feature into an ordered PR plan, with a spec per complex PR\nmodel: opus\n---\n\n# Goal\n\n- Given a request from the user to implement a complex feature or component, break\n  it into an ordered sequence of small, reviewable PRs, and write a full spec for\n  every PR complex enough to need one, without implementing any code\n\n## Input\n\n- The user passes a description of the feature\u002Fcomponent to implement and optionally\n  an existing plan file to extend\n\n# When to Use This Skill\n\n- Use it when one request is too large for a single PR: it needs more than one\n  logical, independently reviewable change, and at least one of those changes has\n  a design decision worth writing down\n- For a request that already fits in one PR, skip straight to \"Write a Spec for a\n  PR\" below, with that PR being the whole request\n\n# Workflow\n\n## Understand the Request\n\n- Read related code in the codebase and existing code in the target directory\n- If the user references a roadmap\u002Fplan file (e.g., `plan.\u003CTOPIC>.md`, or a project\n  `docs\u002Fplan.md` as defined in `.claude\u002Fskills\u002Fproject.rules.md`), read it to\n  extract the exact scope of the requested PR\u002Ffeature\n  - Use the plan ids (e.g., `PR_M10`) for the `PR\u003CNUM>` bullets and the spec files,\n    per `.claude\u002Fskills\u002Fproject.rules.md` section \"Name the PRs\"\n- If an architecture doc already exists for the target directory, read it to\n  understand the current design\n- If the problem or the desired solution is not perfectly clear, follow\n  `.claude\u002Fskills\u002Fauto_task.rules.md` section \"Ask for Clarification Before\n  Executing an Unclear Plan\" before decomposing anything\n\n## Decompose into PRs\n\n- Break the feature into an ordered sequence of small, cohesive PRs; each PR must\n  be reviewable and testable on its own\n- Prefer PRs that change whole files over splitting one file's logic across\n  multiple PRs\n- State each PR's dependency on the PRs before it explicitly; do not leave a\n  dependency implicit\n- Merge PRs that are individually low risk and low complexity into one PR instead\n  of over-fragmenting the sequence\n\n## Decide Which PRs Need a Full Spec\n\n- A PR needs a full spec when it introduces a new interface (class, function, CLI\n  flag), makes a non-obvious design decision or trade-off, or carries meaningful\n  risk (touches shared\u002Fcore code, hard to reverse, many call sites)\n- A small, mechanical, low-risk PR (rename, config tweak, adding a test) does not\n  need one; its bullet description in the plan is enough\n- For every PR that needs one, write its spec by following \"Write a Spec for a\n  PR\" below, passing it `\u003CTOPIC>_PR\u003CNUM>` as the topic and pointing it at the plan\n  file written below so it can read the PR's exact scope\n  - This produces `spec.\u003CTOPIC>_PR\u003CNUM>.md` for that PR\n\n## Write a Spec for a PR\n\n- Create a markdown document following the template\n  `.claude\u002Ftemplates\u002Fspecs.template.md`\n- Follow the rules in `.claude\u002Fskills\u002Fmarkdown.rules.md` and\n  `.claude\u002Fskills\u002Ftext.rules.md`\n- Save the result in a file `spec.\u003CTOPIC>.md` in the current directory\n  - E.g., to spec out `PR_P2b` from `plan.md`, save `spec.PR_P2b.md`\n  - Do not name it `plan.\u003CTOPIC>.md`: that name is reserved for the roadmap\n    document that lists PRs, not for a single PR's spec\n- Do not implement any code: describe the architecture only\n  - Short illustrative snippets are fine (e.g., a class interface, a schema, a\n    function signature) as long as they are not a full implementation\n- Distinguish facts (derived from reading the existing code) from decisions made\n  in the spec\n- Reference actual code artifacts (file, class, function names) instead of\n  paraphrasing them generically\n- The entire spec should be no longer than 100 lines using 85 wrapped text\n- Update an architecture file, if one exists, following the instructions in\n  `.claude\u002Fskills\u002Freadme.write_architecture\u002FSKILL.md`\n  - Only add what matters to understand how the pieces work together, not how\n    the new component works internally\n\n## Write the Plan\n\n- Create (or update) the plan file (e.g. `tasks.md`) following\n  `.claude\u002Ftemplates\u002Fauto_task.template.md`\n- Fill in the `* Repo:` checklist per `.claude\u002Fskills\u002Fauto_task.rules.md` section\n  \"Multi-Repo Issues, Branches, and PRs\"\n- For each `PR\u003CNUM>` bullet, link its spec file when one was written:\n  `- [ ] PR\u003CNUM>: \u003CGoal> (see spec.\u003CTOPIC>_PR\u003CNUM>.md)`\n- Write the bullets according to `.claude\u002Fskills\u002Fmarkdown.rules.md` and\n  `.claude\u002Fskills\u002Ftext.rules.md` with minimal text\n- Do not make any change to the code: only propose the plan and the specs\n\n## Rank the PRs\n\n- Order PR bullets by dependency first: a PR never appears before a PR it depends\n  on\n- Among PRs with no dependency on each other, order by increasing complexity,\n  starting from the PR with the highest confidence in its design\n\n# Conventions\n\n- Follow `.claude\u002Fskills\u002Fauto_task.rules.md` for plan format, task list format, and\n  issue\u002Fbranch\u002FPR naming\n- Follow `.claude\u002Fskills\u002Farchitecture.rules.md` for layering and interface design,\n  and for how the decomposition should respect layering\n- Follow `.claude\u002Fskills\u002Fcoding.rules.md` and `.claude\u002Fskills\u002Ftesting.rules.md` for\n  any illustrative code\u002Ftest snippets\n\n# Constraints\n\n- Do not implement any code\n- Do not create the GitHub issue or branch: that happens later, in whichever\n  `auto_task.execute_*` skill runs the plan\n- Distinguish facts (derived from reading the existing code) from decisions made\n  while decomposing the feature\n\n# Verification\n\n- [ ] The plan file follows `.claude\u002Ftemplates\u002Fauto_task.template.md`\n- [ ] Every `PR\u003CNUM>` bullet states a standalone goal and its dependencies\n      explicitly\n- [ ] Every PR complex enough to need one has a `spec.\u003CTOPIC>_PR\u003CNUM>.md`, not\n      named `plan.\u003CTOPIC>.md`, linked from its bullet\n- [ ] Every spec's section in `.claude\u002Ftemplates\u002Fspecs.template.md` is filled in\n      or explicitly marked \"Not applicable\"\n- [ ] No spec contains full implementation code, only interfaces\u002Fillustrative\n      snippets\n- [ ] Every spec's architecture doc was updated, if one exists for the target\n      directory\n- [ ] PRs are ordered by dependency, then by decreasing confidence \u002F increasing\n      complexity\n- [ ] No code was changed: only the plan file and any spec files were written\n- [ ] Any unclear problem or solution was raised with the user before the plan was\n      finalized\n","# Goal\n\n- Given a request from the user to implement a complex feature or component, break\n  it into an ordered sequence of small, reviewable PRs, and write a full spec for\n  every PR complex enough to need one, without implementing any code\n\n## Input\n\n- The user passes a description of the feature\u002Fcomponent to implement and optionally\n  an existing plan file to extend\n\n# When to Use This Skill\n\n- Use it when one request is too large for a single PR: it needs more than one\n  logical, independently reviewable change, and at least one of those changes has\n  a design decision worth writing down\n- For a request that already fits in one PR, skip straight to \"Write a Spec for a\n  PR\" below, with that PR being the whole request\n\n# Workflow\n\n## Understand the Request\n\n- Read related code in the codebase and existing code in the target directory\n- If the user references a roadmap\u002Fplan file (e.g., `plan.\u003CTOPIC>.md`, or a project\n  `docs\u002Fplan.md` as defined in `.claude\u002Fskills\u002Fproject.rules.md`), read it to\n  extract the exact scope of the requested PR\u002Ffeature\n  - Use the plan ids (e.g., `PR_M10`) for the `PR\u003CNUM>` bullets and the spec files,\n    per `.claude\u002Fskills\u002Fproject.rules.md` section \"Name the PRs\"\n- If an architecture doc already exists for the target directory, read it to\n  understand the current design\n- If the problem or the desired solution is not perfectly clear, follow\n  `.claude\u002Fskills\u002Fauto_task.rules.md` section \"Ask for Clarification Before\n  Executing an Unclear Plan\" before decomposing anything\n\n## Decompose into PRs\n\n- Break the feature into an ordered sequence of small, cohesive PRs; each PR must\n  be reviewable and testable on its own\n- Prefer PRs that change whole files over splitting one file's logic across\n  multiple PRs\n- State each PR's dependency on the PRs before it explicitly; do not leave a\n  dependency implicit\n- Merge PRs that are individually low risk and low complexity into one PR instead\n  of over-fragmenting the sequence\n\n## Decide Which PRs Need a Full Spec\n\n- A PR needs a full spec when it introduces a new interface (class, function, CLI\n  flag), makes a non-obvious design decision or trade-off, or carries meaningful\n  risk (touches shared\u002Fcore code, hard to reverse, many call sites)\n- A small, mechanical, low-risk PR (rename, config tweak, adding a test) does not\n  need one; its bullet description in the plan is enough\n- For every PR that needs one, write its spec by following \"Write a Spec for a\n  PR\" below, passing it `\u003CTOPIC>_PR\u003CNUM>` as the topic and pointing it at the plan\n  file written below so it can read the PR's exact scope\n  - This produces `spec.\u003CTOPIC>_PR\u003CNUM>.md` for that PR\n\n## Write a Spec for a PR\n\n- Create a markdown document following the template\n  `.claude\u002Ftemplates\u002Fspecs.template.md`\n- Follow the rules in `.claude\u002Fskills\u002Fmarkdown.rules.md` and\n  `.claude\u002Fskills\u002Ftext.rules.md`\n- Save the result in a file `spec.\u003CTOPIC>.md` in the current directory\n  - E.g., to spec out `PR_P2b` from `plan.md`, save `spec.PR_P2b.md`\n  - Do not name it `plan.\u003CTOPIC>.md`: that name is reserved for the roadmap\n    document that lists PRs, not for a single PR's spec\n- Do not implement any code: describe the architecture only\n  - Short illustrative snippets are fine (e.g., a class interface, a schema, a\n    function signature) as long as they are not a full implementation\n- Distinguish facts (derived from reading the existing code) from decisions made\n  in the spec\n- Reference actual code artifacts (file, class, function names) instead of\n  paraphrasing them generically\n- The entire spec should be no longer than 100 lines using 85 wrapped text\n- Update an architecture file, if one exists, following the instructions in\n  `.claude\u002Fskills\u002Freadme.write_architecture\u002FSKILL.md`\n  - Only add what matters to understand how the pieces work together, not how\n    the new component works internally\n\n## Write the Plan\n\n- Create (or update) the plan file (e.g. `tasks.md`) following\n  `.claude\u002Ftemplates\u002Fauto_task.template.md`\n- Fill in the `* Repo:` checklist per `.claude\u002Fskills\u002Fauto_task.rules.md` section\n  \"Multi-Repo Issues, Branches, and PRs\"\n- For each `PR\u003CNUM>` bullet, link its spec file when one was written:\n  `- [ ] PR\u003CNUM>: \u003CGoal> (see spec.\u003CTOPIC>_PR\u003CNUM>.md)`\n- Write the bullets according to `.claude\u002Fskills\u002Fmarkdown.rules.md` and\n  `.claude\u002Fskills\u002Ftext.rules.md` with minimal text\n- Do not make any change to the code: only propose the plan and the specs\n\n## Rank the PRs\n\n- Order PR bullets by dependency first: a PR never appears before a PR it depends\n  on\n- Among PRs with no dependency on each other, order by increasing complexity,\n  starting from the PR with the highest confidence in its design\n\n# Conventions\n\n- Follow `.claude\u002Fskills\u002Fauto_task.rules.md` for plan format, task list format, and\n  issue\u002Fbranch\u002FPR naming\n- Follow `.claude\u002Fskills\u002Farchitecture.rules.md` for layering and interface design,\n  and for how the decomposition should respect layering\n- Follow `.claude\u002Fskills\u002Fcoding.rules.md` and `.claude\u002Fskills\u002Ftesting.rules.md` for\n  any illustrative code\u002Ftest snippets\n\n# Constraints\n\n- Do not implement any code\n- Do not create the GitHub issue or branch: that happens later, in whichever\n  `auto_task.execute_*` skill runs the plan\n- Distinguish facts (derived from reading the existing code) from decisions made\n  while decomposing the feature\n\n# Verification\n\n- [ ] The plan file follows `.claude\u002Ftemplates\u002Fauto_task.template.md`\n- [ ] Every `PR\u003CNUM>` bullet states a standalone goal and its dependencies\n      explicitly\n- [ ] Every PR complex enough to need one has a `spec.\u003CTOPIC>_PR\u003CNUM>.md`, not\n      named `plan.\u003CTOPIC>.md`, linked from its bullet\n- [ ] Every spec's section in `.claude\u002Ftemplates\u002Fspecs.template.md` is filled in\n      or explicitly marked \"Not applicable\"\n- [ ] No spec contains full implementation code, only interfaces\u002Fillustrative\n      snippets\n- [ ] Every spec's architecture doc was updated, if one exists for the target\n      directory\n- [ ] PRs are ordered by dependency, then by decreasing confidence \u002F increasing\n      complexity\n- [ ] No code was changed: only the plan file and any spec files were written\n- [ ] Any unclear problem or solution was raised with the user before the plan was\n      finalized\n",{"model":30,"description":7},"opus","master","39143a859859181eff7e774457997b5278fd9e99",".claude\u002Fskills\u002Fauto_task.create_plan_for_feature",170,"https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers","https:\u002F\u002Fcausify.ai","https:\u002F\u002Fgithub.com\u002Fcausify-ai","2026-11-02 02:09:15",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add causify-ai\u002Fhelpers --skill auto_task.create_plan_for_feature",{"tool":45,"command":46},"bunx","bunx skills add causify-ai\u002Fhelpers --skill auto_task.create_plan_for_feature",{"tool":48,"command":49},"pnpm","pnpm dlx skills add causify-ai\u002Fhelpers --skill auto_task.create_plan_for_feature","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fauto_task.create_plan_for_feature\u002FSKILL.md",true,[],[54,73,90,101,109,118],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":65,"publishedAt":25},"01M6C9ZMM0XSXCHHABMJ9XB1JB","tutorial_in_60_mins.propagate_docker_changes","Sync tutorial and class-project Docker files to match project_template","https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Ftutorial_in_60_mins.propagate_docker_changes\u002FSKILL.md",[60],{"categoryNo":61,"categoryName":62,"taxonomyType":63,"taxonomyTypeDesc":64},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[66,67,68,69,70,71,72],"tutorial in 60 mins propagate docker changes","tutorial","docker","files","haiku","template","sync",{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":82,"publishedAt":25},"01M6C9ZJK8QJ9FNCY39WVF3GMG","tutorial_in_60_mins.merge_markdown","Merge the content of a markdown file into a Jupyter notebook","https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Ftutorial_in_60_mins.merge_markdown\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":63,"taxonomyTypeDesc":64},"01JBSEEDCAT000000000000002","文档处理",[83,84,67,85,86,70,87,88,89],"merge","tutorial in 60 mins merge markdown","markdown","jupyter","file","content","jupyter notebook",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":25},"01M6C9ZFYK13ZCT1E8BEEC4NG4","tutorial_in_60_mins.format","Format a directory to follow the \"Learn X in 60 Minutes\" tutorial conventions","https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Ftutorial_in_60_mins.format\u002FSKILL.md",[],[97,67,98,99,100,70],"tutorial in 60 mins format","format","directory","learn",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":25},"01M6C9ZDKXSBKNKX7M3X4W38G5","tutorial_in_60_mins.create","Create a tutorial directory for the Learn X in 60 Minutes conventions","https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Ftutorial_in_60_mins.create\u002FSKILL.md",[],[108,67,19,99,100],"tutorial in 60 mins create",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":25},"01M6BZS5Z0QE03WRS1TM3XJEY9","todo.reorg_in_progress","Reorganize ai_task_queue.md so in-progress tasks, not-started tasks, and mislabeled topic headers sit under the right H1 stage","https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Ftodo.reorg_in_progress\u002FSKILL.md",[],[116,117],"todo reorg in progress","tasks",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":25},"01M6BZS4CQZ6KK2KQ26SVB7QCS","todo.reorg_headers","Reorganize ai_task_queue.md .md so every H2 topic matches ALL TOPICS and every H3 task sits under the right topic, keeping its H1 stage","https:\u002F\u002Fgithub.com\u002Fcausify-ai\u002Fhelpers\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Ftodo.reorg_headers\u002FSKILL.md",[],[125],"todo reorg headers"]