[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M719225XZP41H8Q3J45YYBK4":3,"skill-same:01M719225XZP41H8Q3J45YYBK4":124},{"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":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M719225XZP41H8Q3J45YYBK4","converge-planning",null,"Design a Converge playbook end-to-end. Use when the user says \"plan a project\", \"design a playbook\", \"decompose into tasks\", \"scaffold a Converge workflow\", \"onboard to Converge\", or asks how to write TASK.md \u002F playbook.yml. Two entry points: plan a new playbook or update an existing one. Hand off to `\u002Fconverge-control` after producing the playbook structure.","openplaybooks-dev\u002Fconverge","openplaybooks-dev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F270560357?v=4","01M7191G17AHW5SXN63HJ0BEZV","01M7191G29922BDNWN8CFVG4PD",3,"MIT","https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"converge planning","planning","converge","use","decompose","playbook","write","update","how","plan","structure","hand","tasks","workflow","when","new","design","how to","end","project","2026-11-10 10:12:30",false,"---\nname: converge-planning\ndescription: >-\n  Design a Converge playbook end-to-end. Use when the user says \"plan a\n  project\", \"design a playbook\", \"decompose into tasks\", \"scaffold a\n  Converge workflow\", \"onboard to Converge\", or asks how to write\n  TASK.md \u002F playbook.yml. Two entry points: plan a new playbook or update\n  an existing one. Hand off to `\u002Fconverge-control` after producing the\n  playbook structure.\n---\n\n# Converge Planning\n\n## When to use this skill\n\nUser says: \"plan a project\" \u002F \"design a playbook\" \u002F \"decompose into tasks\" \u002F \"write a playbook\"\n\n---\n\n## Scenario lookup — pick the right file immediately\n\nRead one scenario that matches the user's ask. If learning or comparing patterns, read multiple.\n\n| What the user says | Read this scenario |\n|---|---|\n| \"build an app\" \u002F \"implement features\" \u002F \"create screens and components\" | `scenarios\u002Fsoftware-development.md` |\n| \"generate a design system\" \u002F \"design tokens\" \u002F \"component library\" | `scenarios\u002Fdesign-system.md` |\n| \"automate a workflow\" \u002F \"business rules\" \u002F \"reports and notifications\" | `scenarios\u002Fbusiness-automation.md` |\n| \"optimize\" \u002F \"genetic algorithm\" \u002F \"score and rank candidates\" | `scenarios\u002Foptimization.md` |\n| \"deep research\" \u002F \"explore a topic\" \u002F \"multi-epoch research\" | `scenarios\u002Fexploration.md` |\n| \"goal-driven\" \u002F \"sprint planning\" \u002F \"kanban\" \u002F \"do-while loop\" | `scenarios\u002Fgoal-driven.md` |\n| \"data pipeline\" \u002F \"cron-triggered\" \u002F \"ETL\" \u002F \"continuous sync\" | `scenarios\u002Fpipeline.md` |\n| \"two playbooks feeding each other\" \u002F \"dual loop\" \u002F \"generator-evaluator\" | `scenarios\u002Fdual-feedback-loop.md` |\n| \"decompose into modules\" \u002F \"write templates\" \u002F \"spawn per component\" | `scenarios\u002Fdecomposition.md` |\n\n**No match?** Default to `scenarios\u002Fdecomposition.md` — it explains the root pattern all others specialize.\n\n---\n\n## The thinking sequence\n\n1. **Ask: what does the deliverable contain?** (BOM, not steps)\n2. **Decompose into artifacts** — noun-phrase task names.\n3. **Identify composition** — which artifact reads whose output? (inputs:)\n4. **Identify static vs. dynamic** — known at plan time vs. runtime data\n5. **Assign modes** — task \u002F spawner \u002F converger \u002F gateway\n6. **Write TASK.md contracts**\n7. **Validate** (anti-patterns check)\n8. **Hand off** to converge-control\n\n---\n\n## Step-by-step\n\n### 1. Ask: what does the deliverable contain?\n\nNot \"what steps\" — \"what artifacts\".\n\nWRONG: \"generate a design system\" \u002F \"build a blog\" \u002F \"plan, design, implement\"\nRIGHT: \"A design system: brand identity + tokens + primitives + components\"\nRIGHT: \"A blog: schema + API + frontend + tests\"\n\nWork backward from final artifacts. This is your BOM (bill of materials).\n\n### 2. Decompose into artifacts\n\nBreak into complete deliverables. Task name = output artifact (noun phrase).\n\nSee `scenarios\u002F` for worked examples:\n- `scenarios\u002Fdesign-system.md` — BOM: branding → tokens → primitives → components\n- `scenarios\u002Fsoftware-development.md` — BOM: schema → API → frontend → tests\n- `scenarios\u002Fbusiness-automation.md` — BOM: intake → rules → report → notification\n\nFor each artifact: can one agent finish it in one session?\n- Yes → task\n- No → split further\n\nIf the decomposition reads like steps (\"1. do X, 2. do Y\"), stop and restart from the artifacts.\n\n### 3. Identify composition via inputs:\n\nOrdering is by inputs tracing. No `depends_on:` in task frontmatter.\n\nIf task B reads A's output path → B runs after A. The runtime deduces the graph from inputs: alone.\n\n```\nBrand identity (no inputs — first)\n  ↓ inputs: brand identity output\nTokens (reads: Brand identity)\n  ↓ inputs: tokens output\nPrimitives (reads: Tokens)\n  ↓ inputs: primitives output\nComponents (reads: Primitives)\n```\n\n### 4. Identify static vs. dynamic\n\n**Static:** known at plan time. Lives in `tasks\u002F`. The fixed skeleton.\n\n**Dynamic:** from runtime data (catalog, API, user input). Lives in `templates\u002F`. Spawned by a `mode: spawner` task.\n\nAsk: is the child list known at plan time?\n- Yes → static children under `tasks\u002F\u003Cid>\u002Ftasks\u002F`\n- No → mode: spawner + templates\u002F\n\nTemplates are for content that varies per invocation — NOT for every task.\n\n### 5. Assign modes\n\nRead `references\u002Ftask-modes.md` for the full table.\n\n```\ntask         — one agent, one deliverable. (default)\nspawner     — runtime fan-out from data. Body calls ctx.loop.spawn().\nconverger   — multi-wave fix loop until checks pass.\ngateway     — sync point. No body.\n```\n\n### 6. Write TASK.md contracts\n\nRead `references\u002Fschema.md` for field reference.\n\nFor each task, write `tasks\u002F\u003Cid>\u002FTASK.md`:\n\n```yaml\n---\nid: \u003Cid>\ntitle: \u003Cnoun phrase for the output>\ninputs:\n  - \u003Cpath to upstream output>\noutputs:\n  - \u003Cpath to this task's output>\nchecks:\n  - id: \u003Ccheck-name>\n    cmd: \u003Cshell command — exit 0 = pass>\n---\n```\n\n**Do not add `tasks:` to playbook.yml.** For static skeletons, the loader discovers tasks from the `tasks\u002F` directory at compile time. Task bodies (inputs:, outputs:, checks:) go in `tasks\u002F\u003Cid>\u002FTASK.md`.\n\nFor spawner tasks (dynamic children from templates\u002F), write the spawner body in `tasks\u002F\u003Cid>\u002FTASK.md` with `mode: spawner`.\n\n### 7. Validate\n\nRead `references\u002Fanti-patterns.md` if something smells wrong.\n\nPer-task checks:\n- [ ] Title is a noun phrase, not a verb\n- [ ] Outputs are specific paths\n- [ ] Every output has a check\n- [ ] Every input traces to an upstream output\n\nPlaybook-level:\n- [ ] Looks like a BOM, not steps\n- [ ] Static vs. dynamic is correct\n\n### 8. Hand off\n\n```\n\u002Fconverge-control run --playbook=\u003Cname>\n```\n\n---\n\n## Key principles\n\n**BOM over steps.** Start from \"what does it contain\", not \"what runs first\".\n\n**Files are the currency.** Work passes through `outputs:` and `inputs:`, not prompts pasted into bodies.\n\n**Middle work is wrong.** Each task's output must be complete and usable — not \"part 1\" for the next task to finish.\n\n**Tasks are nouns.** \"brand identity\", \"color tokens\", \"primitive components\". NOT \"catalog\", \"generate\", \"build\".\n\n**Ordering via inputs:.** Do not write `depends_on:` in task frontmatter. Sibling order is determined by `inputs:`.\n\n---\n\n## Trigger references\n\nRead `references\u002F` only when flagged:\n- `references\u002Ftask-modes.md` — when assigning mode to a parent task\n- `references\u002Fschema.md` — when writing TASK.md frontmatter\n- `references\u002Fanti-patterns.md` — when decomposition smells wrong\n- `references\u002Fphases.md` — only if existing codebase (step 1, optional)\n\n---\n\n## Update existing playbook\n\n### 1. Read current structure\n\nRead the `tasks\u002F` tree to understand what's already there.\n\n### 2. Identify what changed\n\n- New goal or requirement? → decompose new sub-goals (step 2 above)\n- Restructure existing? → anti-patterns check\n- Add new fan-out or loop? → assign mode + write contracts\n\n### 3. Apply steps 3–7 from Plan new\n\n### 4. Hand off\n\n```\n\u002Fconverge-control run --playbook=\u003Cname> --resume\n```\n","# Converge Planning\n\n## When to use this skill\n\nUser says: \"plan a project\" \u002F \"design a playbook\" \u002F \"decompose into tasks\" \u002F \"write a playbook\"\n\n---\n\n## Scenario lookup — pick the right file immediately\n\nRead one scenario that matches the user's ask. If learning or comparing patterns, read multiple.\n\n| What the user says | Read this scenario |\n|---|---|\n| \"build an app\" \u002F \"implement features\" \u002F \"create screens and components\" | `scenarios\u002Fsoftware-development.md` |\n| \"generate a design system\" \u002F \"design tokens\" \u002F \"component library\" | `scenarios\u002Fdesign-system.md` |\n| \"automate a workflow\" \u002F \"business rules\" \u002F \"reports and notifications\" | `scenarios\u002Fbusiness-automation.md` |\n| \"optimize\" \u002F \"genetic algorithm\" \u002F \"score and rank candidates\" | `scenarios\u002Foptimization.md` |\n| \"deep research\" \u002F \"explore a topic\" \u002F \"multi-epoch research\" | `scenarios\u002Fexploration.md` |\n| \"goal-driven\" \u002F \"sprint planning\" \u002F \"kanban\" \u002F \"do-while loop\" | `scenarios\u002Fgoal-driven.md` |\n| \"data pipeline\" \u002F \"cron-triggered\" \u002F \"ETL\" \u002F \"continuous sync\" | `scenarios\u002Fpipeline.md` |\n| \"two playbooks feeding each other\" \u002F \"dual loop\" \u002F \"generator-evaluator\" | `scenarios\u002Fdual-feedback-loop.md` |\n| \"decompose into modules\" \u002F \"write templates\" \u002F \"spawn per component\" | `scenarios\u002Fdecomposition.md` |\n\n**No match?** Default to `scenarios\u002Fdecomposition.md` — it explains the root pattern all others specialize.\n\n---\n\n## The thinking sequence\n\n1. **Ask: what does the deliverable contain?** (BOM, not steps)\n2. **Decompose into artifacts** — noun-phrase task names.\n3. **Identify composition** — which artifact reads whose output? (inputs:)\n4. **Identify static vs. dynamic** — known at plan time vs. runtime data\n5. **Assign modes** — task \u002F spawner \u002F converger \u002F gateway\n6. **Write TASK.md contracts**\n7. **Validate** (anti-patterns check)\n8. **Hand off** to converge-control\n\n---\n\n## Step-by-step\n\n### 1. Ask: what does the deliverable contain?\n\nNot \"what steps\" — \"what artifacts\".\n\nWRONG: \"generate a design system\" \u002F \"build a blog\" \u002F \"plan, design, implement\"\nRIGHT: \"A design system: brand identity + tokens + primitives + components\"\nRIGHT: \"A blog: schema + API + frontend + tests\"\n\nWork backward from final artifacts. This is your BOM (bill of materials).\n\n### 2. Decompose into artifacts\n\nBreak into complete deliverables. Task name = output artifact (noun phrase).\n\nSee `scenarios\u002F` for worked examples:\n- `scenarios\u002Fdesign-system.md` — BOM: branding → tokens → primitives → components\n- `scenarios\u002Fsoftware-development.md` — BOM: schema → API → frontend → tests\n- `scenarios\u002Fbusiness-automation.md` — BOM: intake → rules → report → notification\n\nFor each artifact: can one agent finish it in one session?\n- Yes → task\n- No → split further\n\nIf the decomposition reads like steps (\"1. do X, 2. do Y\"), stop and restart from the artifacts.\n\n### 3. Identify composition via inputs:\n\nOrdering is by inputs tracing. No `depends_on:` in task frontmatter.\n\nIf task B reads A's output path → B runs after A. The runtime deduces the graph from inputs: alone.\n\n```\nBrand identity (no inputs — first)\n  ↓ inputs: brand identity output\nTokens (reads: Brand identity)\n  ↓ inputs: tokens output\nPrimitives (reads: Tokens)\n  ↓ inputs: primitives output\nComponents (reads: Primitives)\n```\n\n### 4. Identify static vs. dynamic\n\n**Static:** known at plan time. Lives in `tasks\u002F`. The fixed skeleton.\n\n**Dynamic:** from runtime data (catalog, API, user input). Lives in `templates\u002F`. Spawned by a `mode: spawner` task.\n\nAsk: is the child list known at plan time?\n- Yes → static children under `tasks\u002F\u003Cid>\u002Ftasks\u002F`\n- No → mode: spawner + templates\u002F\n\nTemplates are for content that varies per invocation — NOT for every task.\n\n### 5. Assign modes\n\nRead `references\u002Ftask-modes.md` for the full table.\n\n```\ntask         — one agent, one deliverable. (default)\nspawner     — runtime fan-out from data. Body calls ctx.loop.spawn().\nconverger   — multi-wave fix loop until checks pass.\ngateway     — sync point. No body.\n```\n\n### 6. Write TASK.md contracts\n\nRead `references\u002Fschema.md` for field reference.\n\nFor each task, write `tasks\u002F\u003Cid>\u002FTASK.md`:\n\n```yaml\n---\nid: \u003Cid>\ntitle: \u003Cnoun phrase for the output>\ninputs:\n  - \u003Cpath to upstream output>\noutputs:\n  - \u003Cpath to this task's output>\nchecks:\n  - id: \u003Ccheck-name>\n    cmd: \u003Cshell command — exit 0 = pass>\n---\n```\n\n**Do not add `tasks:` to playbook.yml.** For static skeletons, the loader discovers tasks from the `tasks\u002F` directory at compile time. Task bodies (inputs:, outputs:, checks:) go in `tasks\u002F\u003Cid>\u002FTASK.md`.\n\nFor spawner tasks (dynamic children from templates\u002F), write the spawner body in `tasks\u002F\u003Cid>\u002FTASK.md` with `mode: spawner`.\n\n### 7. Validate\n\nRead `references\u002Fanti-patterns.md` if something smells wrong.\n\nPer-task checks:\n- [ ] Title is a noun phrase, not a verb\n- [ ] Outputs are specific paths\n- [ ] Every output has a check\n- [ ] Every input traces to an upstream output\n\nPlaybook-level:\n- [ ] Looks like a BOM, not steps\n- [ ] Static vs. dynamic is correct\n\n### 8. Hand off\n\n```\n\u002Fconverge-control run --playbook=\u003Cname>\n```\n\n---\n\n## Key principles\n\n**BOM over steps.** Start from \"what does it contain\", not \"what runs first\".\n\n**Files are the currency.** Work passes through `outputs:` and `inputs:`, not prompts pasted into bodies.\n\n**Middle work is wrong.** Each task's output must be complete and usable — not \"part 1\" for the next task to finish.\n\n**Tasks are nouns.** \"brand identity\", \"color tokens\", \"primitive components\". NOT \"catalog\", \"generate\", \"build\".\n\n**Ordering via inputs:.** Do not write `depends_on:` in task frontmatter. Sibling order is determined by `inputs:`.\n\n---\n\n## Trigger references\n\nRead `references\u002F` only when flagged:\n- `references\u002Ftask-modes.md` — when assigning mode to a parent task\n- `references\u002Fschema.md` — when writing TASK.md frontmatter\n- `references\u002Fanti-patterns.md` — when decomposition smells wrong\n- `references\u002Fphases.md` — only if existing codebase (step 1, optional)\n\n---\n\n## Update existing playbook\n\n### 1. Read current structure\n\nRead the `tasks\u002F` tree to understand what's already there.\n\n### 2. Identify what changed\n\n- New goal or requirement? → decompose new sub-goals (step 2 above)\n- Restructure existing? → anti-patterns check\n- Add new fan-out or loop? → assign mode + write contracts\n\n### 3. Apply steps 3–7 from Plan new\n\n### 4. Hand off\n\n```\n\u002Fconverge-control run --playbook=\u003Cname> --resume\n```\n",{"name":5,"description":7},"main","7d618d8bc059f1a0974706d1d15ec25f73cf1e1d",".claude\u002Fskills\u002Fconverge-planning",1,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge","https:\u002F\u002Fplaybooks.to","https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev","2026-06-13 10:11:21",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add openplaybooks-dev\u002Fconverge --skill converge-planning",{"tool":62,"command":63},"bunx","bunx skills add openplaybooks-dev\u002Fconverge --skill converge-planning",{"tool":65,"command":66},"pnpm","pnpm dlx skills add openplaybooks-dev\u002Fconverge --skill converge-planning","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002FSKILL.md",true,[70,76,80,84,88,92,96,100,104,108,112,116,120],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fanti-patterns.md","REFERENCE","参考文档",2225,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Freferences\u002Fanti-patterns.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fphases.md",659,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Freferences\u002Fphases.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fschema.md",2552,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Freferences\u002Fschema.md",{"path":85,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Ftask-modes.md",2474,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Freferences\u002Ftask-modes.md",{"path":89,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":90,"sourceHtmlUrl":91},"scenarios\u002Fbusiness-automation.md",2930,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Fbusiness-automation.md",{"path":93,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":94,"sourceHtmlUrl":95},"scenarios\u002Fdecomposition.md",5629,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Fdecomposition.md",{"path":97,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":98,"sourceHtmlUrl":99},"scenarios\u002Fdesign-system.md",3483,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Fdesign-system.md",{"path":101,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":102,"sourceHtmlUrl":103},"scenarios\u002Fdual-feedback-loop.md",5416,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Fdual-feedback-loop.md",{"path":105,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":106,"sourceHtmlUrl":107},"scenarios\u002Fexploration.md",8786,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Fexploration.md",{"path":109,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":110,"sourceHtmlUrl":111},"scenarios\u002Fgoal-driven.md",6698,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Fgoal-driven.md",{"path":113,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":114,"sourceHtmlUrl":115},"scenarios\u002Foptimization.md",8415,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Foptimization.md",{"path":117,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":118,"sourceHtmlUrl":119},"scenarios\u002Fpipeline.md",8200,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Fpipeline.md",{"path":121,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":122,"sourceHtmlUrl":123},"scenarios\u002Fsoftware-development.md",10421,"https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fconverge-planning\u002Fscenarios\u002Fsoftware-development.md",[125,146,155,177,183,211],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":43},"01M71989MQF3GPZ7P5TX6S93PD","hello-checker","Use this skill when asked to \"verify\", \"check\", or \"validate\" a file's existence and content. It provides a reliable workflow for confirming files meet their spec.","https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002Ftests\u002Ftest-codex-real\u002F.converge\u002Fskills\u002Fhello-checker\u002FSKILL.md",[131],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[133,134,135,136,26,137,138,139,140,141,142,36,37,143,144,145],"checker","hello checker","hello","it","content","validate","spec","verify","check","file","Meet","files","for",{"skillNo":147,"name":148,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":43},"01M7198823W79B3S15TPV97TCB","ask-skill","https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002Ftests\u002Ftest-ask-autonomous\u002F.converge\u002Fplaybooks\u002Fdefault\u002Fskills\u002Fask-skill\u002FSKILL.md",[151],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[153,154],"ask skill","ask",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":165,"publishedAt":43},"01M71986EJ6VCM8YKGEM2YEDQV","html-review-artifact","Framework-wide guidance for crafting polished human-review artifacts as markdown or HTML","https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002Fskills\u002Fhtml-review-artifact\u002FSKILL.md",[161,164],{"categoryNo":162,"categoryName":163,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[166,167,168,169,170,145,171,172,173,174,175,176],"html","artifact","review","html review artifact","as","framework","wide","guidance","markdown","human","artifacts",{"skillNo":178,"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":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":43},"01M719833M2XWXG1VPBW30GW7J","https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002Fskills\u002Fconverge-planning\u002FSKILL.md",[181],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[25,23,24,33,36,35,26,27,34,29,32,31,30,28,38,39,40,41,42,37],{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":195,"publishedAt":43},"01M7197XZT1T9GDYAJGVGX1J60","converge-control","Operate a Converge playbook end-to-end — start runs, monitor progress, narrow failures with `--select`, inspect runtime state, validate definitions, surgically reset subtrees, and stop stuck or orphaned runs. Use this skill whenever the user says \"run my playbook\", \"execute this\", \"monitor the run\", \"converge failed\", \"the run is stuck\", \"retry failures\", \"babysit this playbook\", \"what's the status?\", \"show me the gantt\", or asks how to use `converge run` \u002F `--select` \u002F `inspect` \u002F `doctor` \u002F `clean` \u002F `stop`. Also use it for `HTTP 401` \u002F `Invalid API key` failures on the first task — those are environment-not-playbook problems — and for any post-run cleanup work. Hand off to `converge-planning` if the user wants to design or restructure the playbook itself.","https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002Fskills\u002Fconverge-control\u002FSKILL.md",[189,190],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":191,"categoryName":192,"taxonomyType":193,"taxonomyTypeDesc":194},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[196,197,25,198,199,200,201,202,203,204,34,205,206,39,40,207,41,208,209,210],"converge control","control","operate","invalid","show","api","me","work","reset","show me","cleanup","clean","inspect","select","retry",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":218,"publishedAt":43},"01M7197SCVN0QTD3CM4M83WYJH","repair-taskts","Fix task.ts definition issues — Seed syntax, missing .build(), empty checks, import errors, TypeScript errors","https:\u002F\u002Fgithub.com\u002Fopenplaybooks-dev\u002Fconverge\u002Fblob\u002Fmain\u002Fpackages\u002Fcore\u002Fsrc\u002Fnavigator\u002Frepair\u002Fskill-templates\u002Frepair-taskts\u002FSKILL.md",[217],{"categoryNo":191,"categoryName":192,"taxonomyType":193,"taxonomyTypeDesc":194},[219,220,221,222,29,223,224,225,226,227,228,229,230,231,232,41,233,25,234,235],"repair taskts","repair","Bash","edit","read","line","at","spawn","code","analysis","number","errors","issues","fix","chain","definition","never"]