[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71PBJJ24QE0GQG2AMSEHE45":3,"skill-same:01M71PBJJ24QE0GQG2AMSEHE45":68},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M71PBJJ24QE0GQG2AMSEHE45","openspec-apply-change",null,"Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.","MuShi17\u002FRollo-Code","MuShi17","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F134412104?v=4","01M71PBCMDNS56TC97TVJA960Z","林磊","01M71PBCN6ZKE8PR1VX7NSHAYZ",1,"MIT","https:\u002F\u002Fgithub.com\u002FMuShi17\u002FRollo-Code\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-apply-change\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"openspec apply change","apply change","openspec","openspec apply","apply","change","implement","user","tasks","Bash","when","use","implementation","start","implementing","continue","cli","work","2026-11-10 13:02:02",false,"---\nname: openspec-apply-change\ndescription: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.\nallowed-tools: Bash(openspec:*)\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n  author: openspec\n  version: \"1.0\"\n  generatedBy: \"1.12.0\"\n---\n\nImplement tasks from an OpenSpec change.\n\n**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store \u003Cid>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store \u003Cid>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change \"\u003Cname>\" --json --store \"\u003Cid>\"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec\u002F` root.\n\n**Input**: Optionally specify a change name (e.g., `$openspec-apply-change (Codex) or \u002Fopenspec-apply-change (other agents) add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.\n\n**Steps**\n\n1. **Select the change**\n\n   If a name is provided, use it. Otherwise:\n   - Infer from conversation context if the user mentioned a change\n   - Auto-select if only one active change exists\n   - If ambiguous, run `openspec list --json` to get available changes and ask the user to select one\n\n   Always announce: \"Using change: \u003Cname>\" and how to override (e.g., `$openspec-apply-change (Codex) or \u002Fopenspec-apply-change (other agents) \u003Cother>`).\n\n2. **Check status to understand the schema**\n   ```bash\n   openspec status --change \"\u003Cname>\" --json\n   ```\n   Parse the JSON to understand:\n   - `schemaName`: The workflow being used (e.g., \"spec-driven\")\n   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints\n   - Which artifact contains the tasks (typically \"tasks\" for spec-driven, check status for others)\n\n3. **Get apply instructions**\n\n   ```bash\n   openspec instructions apply --change \"\u003Cname>\" --json\n   ```\n\n   This returns:\n   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal\u002Fspecs\u002Fdesign\u002Ftasks or spec\u002Ftests\u002Fimplementation\u002Fdocs)\n   - Progress (total, complete, remaining)\n   - Task list with status\n   - Dynamic instruction based on current state\n   - Optional `context`: current required project instruction input from the selected root\n   - Optional `operationGuidance`: current advisory guidance for apply\n\n   **Handle states:**\n   - If `state: \"blocked\"` (missing artifacts): show message, suggest using `$openspec-continue-change (Codex) or \u002Fopenspec-continue-change (other agents)` (if it is not installed, run `openspec status --change \"\u003Cname>\" --json` to see the next artifact and `openspec instructions \u003Cartifact-id> --change \"\u003Cname>\" --json` for how to create it)\n   - If `state: \"all_done\"`: congratulate, suggest archive\n   - Otherwise: proceed to implementation\n\n   Treat `context` as a required prompt-level input. Read and consider it, and\n   apply relevant project facts, conventions, and constraints while implementing.\n   Treat `operationGuidance` as optional additive advice. Read and consider every\n   entry, and follow entries that are applicable and compatible with the built-in\n   workflow.\n\n   Keep both fields separate from CLI-returned state, missing artifacts, tasks,\n   progress, `contextFiles`, and the built-in `instruction`. They are not\n   evidence of task completion, do not replace the built-in instruction, and do\n   not permit bypassing a blocked state. If context conflicts with the built-in\n   instruction, an explicit user choice, or a CLI-controlled value, report the\n   conflict and preserve the controlling value. If guidance is inapplicable or\n   conflicts with those controlling inputs, do not follow it and explain why.\n   These are prompt-level behavior contracts, not enforceable checks.\n\n4. **Read context files**\n\n   Read every file path listed under `contextFiles` from the apply instructions output.\n   The files depend on the schema being used:\n   - **spec-driven**: proposal, specs, design, tasks\n   - Other schemas: follow the contextFiles from CLI output\n\n   Do not copy `context` or `operationGuidance` verbatim into implementation\n   files or planning artifacts unless the user separately asks for that content.\n\n5. **Show current progress**\n\n   Display:\n   - Schema being used\n   - Progress: \"N\u002FM tasks complete\"\n   - Remaining tasks overview\n   - Dynamic instruction from CLI\n\n6. **Implement tasks (loop until done or blocked)**\n\n   For each pending task:\n   - Show which task is being worked on\n   - Make the code changes required\n   - Keep changes minimal and focused\n   - Mark task complete in the tasks file: `- [ ]` → `- [x]`\n   - Continue to next task\n\n   **Pause if:**\n   - Task is unclear → ask for clarification\n   - Implementation reveals a design issue → suggest updating artifacts\n   - A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently\n   - Error or blocker encountered → report and wait for guidance\n   - User interrupts\n\n7. **On completion or pause, show status**\n\n   Display:\n   - Tasks completed this session\n   - Overall progress: \"N\u002FM tasks complete\"\n   - If all done: suggest archive\n   - If paused: explain why and wait for guidance\n\n**Output During Implementation**\n\n```\n## Implementing: \u003Cchange-name> (schema: \u003Cschema-name>)\n\nWorking on task 3\u002F7: \u003Ctask description>\n[...implementation happening...]\n✓ Task complete\n\nWorking on task 4\u002F7: \u003Ctask description>\n[...implementation happening...]\n✓ Task complete\n```\n\n**Output On Completion**\n\n```\n## Implementation Complete\n\n**Change:** \u003Cchange-name>\n**Schema:** \u003Cschema-name>\n**Progress:** 7\u002F7 tasks complete ✓\n\n### Completed This Session\n- [x] Task 1\n- [x] Task 2\n...\n\nAll tasks complete! You can archive this change with `$openspec-archive-change (Codex) or \u002Fopenspec-archive-change (other agents)`.\n```\n\n**Output On Pause (Issue Encountered)**\n\n```\n## Implementation Paused\n\n**Change:** \u003Cchange-name>\n**Schema:** \u003Cschema-name>\n**Progress:** 4\u002F7 tasks complete\n\n### Issue Encountered\n\u003Cdescription of the issue>\n\n**Options:**\n1. \u003Coption 1>\n2. \u003Coption 2>\n3. Other approach\n\nWhat would you like to do?\n```\n\n**Guardrails**\n- Keep going through tasks until done or blocked\n- Always read context files before starting (from the apply instructions output)\n- If task is ambiguous, pause and ask before implementing\n- If implementation reveals issues, pause and suggest artifact updates\n- Keep code changes minimal and scoped to each task\n- Update task checkbox immediately after completing each task\n- Pause on errors, blockers, or unclear requirements - don't guess\n- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior\n- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred\n- Use contextFiles from CLI output, don't assume specific file names\n- Do not use context or operation guidance as proof that a task is complete\n- Apply relevant project context; report conflicts with controlling workflow inputs\n- Consider every guidance entry; explain any inapplicable or conflicting advice\n- Do not copy runtime context or operation guidance into implementation files or planning artifacts\n- Preserve CLI-controlled blocked\u002Fready\u002Fall-done behavior and completion criteria\n\n**Fluid Workflow Integration**\n\nThis skill supports the \"actions on a change\" model:\n\n- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions\n- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly\n","Implement tasks from an OpenSpec change.\n\n**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store \u003Cid>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store \u003Cid>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change \"\u003Cname>\" --json --store \"\u003Cid>\"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec\u002F` root.\n\n**Input**: Optionally specify a change name (e.g., `$openspec-apply-change (Codex) or \u002Fopenspec-apply-change (other agents) add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.\n\n**Steps**\n\n1. **Select the change**\n\n   If a name is provided, use it. Otherwise:\n   - Infer from conversation context if the user mentioned a change\n   - Auto-select if only one active change exists\n   - If ambiguous, run `openspec list --json` to get available changes and ask the user to select one\n\n   Always announce: \"Using change: \u003Cname>\" and how to override (e.g., `$openspec-apply-change (Codex) or \u002Fopenspec-apply-change (other agents) \u003Cother>`).\n\n2. **Check status to understand the schema**\n   ```bash\n   openspec status --change \"\u003Cname>\" --json\n   ```\n   Parse the JSON to understand:\n   - `schemaName`: The workflow being used (e.g., \"spec-driven\")\n   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints\n   - Which artifact contains the tasks (typically \"tasks\" for spec-driven, check status for others)\n\n3. **Get apply instructions**\n\n   ```bash\n   openspec instructions apply --change \"\u003Cname>\" --json\n   ```\n\n   This returns:\n   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal\u002Fspecs\u002Fdesign\u002Ftasks or spec\u002Ftests\u002Fimplementation\u002Fdocs)\n   - Progress (total, complete, remaining)\n   - Task list with status\n   - Dynamic instruction based on current state\n   - Optional `context`: current required project instruction input from the selected root\n   - Optional `operationGuidance`: current advisory guidance for apply\n\n   **Handle states:**\n   - If `state: \"blocked\"` (missing artifacts): show message, suggest using `$openspec-continue-change (Codex) or \u002Fopenspec-continue-change (other agents)` (if it is not installed, run `openspec status --change \"\u003Cname>\" --json` to see the next artifact and `openspec instructions \u003Cartifact-id> --change \"\u003Cname>\" --json` for how to create it)\n   - If `state: \"all_done\"`: congratulate, suggest archive\n   - Otherwise: proceed to implementation\n\n   Treat `context` as a required prompt-level input. Read and consider it, and\n   apply relevant project facts, conventions, and constraints while implementing.\n   Treat `operationGuidance` as optional additive advice. Read and consider every\n   entry, and follow entries that are applicable and compatible with the built-in\n   workflow.\n\n   Keep both fields separate from CLI-returned state, missing artifacts, tasks,\n   progress, `contextFiles`, and the built-in `instruction`. They are not\n   evidence of task completion, do not replace the built-in instruction, and do\n   not permit bypassing a blocked state. If context conflicts with the built-in\n   instruction, an explicit user choice, or a CLI-controlled value, report the\n   conflict and preserve the controlling value. If guidance is inapplicable or\n   conflicts with those controlling inputs, do not follow it and explain why.\n   These are prompt-level behavior contracts, not enforceable checks.\n\n4. **Read context files**\n\n   Read every file path listed under `contextFiles` from the apply instructions output.\n   The files depend on the schema being used:\n   - **spec-driven**: proposal, specs, design, tasks\n   - Other schemas: follow the contextFiles from CLI output\n\n   Do not copy `context` or `operationGuidance` verbatim into implementation\n   files or planning artifacts unless the user separately asks for that content.\n\n5. **Show current progress**\n\n   Display:\n   - Schema being used\n   - Progress: \"N\u002FM tasks complete\"\n   - Remaining tasks overview\n   - Dynamic instruction from CLI\n\n6. **Implement tasks (loop until done or blocked)**\n\n   For each pending task:\n   - Show which task is being worked on\n   - Make the code changes required\n   - Keep changes minimal and focused\n   - Mark task complete in the tasks file: `- [ ]` → `- [x]`\n   - Continue to next task\n\n   **Pause if:**\n   - Task is unclear → ask for clarification\n   - Implementation reveals a design issue → suggest updating artifacts\n   - A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently\n   - Error or blocker encountered → report and wait for guidance\n   - User interrupts\n\n7. **On completion or pause, show status**\n\n   Display:\n   - Tasks completed this session\n   - Overall progress: \"N\u002FM tasks complete\"\n   - If all done: suggest archive\n   - If paused: explain why and wait for guidance\n\n**Output During Implementation**\n\n```\n## Implementing: \u003Cchange-name> (schema: \u003Cschema-name>)\n\nWorking on task 3\u002F7: \u003Ctask description>\n[...implementation happening...]\n✓ Task complete\n\nWorking on task 4\u002F7: \u003Ctask description>\n[...implementation happening...]\n✓ Task complete\n```\n\n**Output On Completion**\n\n```\n## Implementation Complete\n\n**Change:** \u003Cchange-name>\n**Schema:** \u003Cschema-name>\n**Progress:** 7\u002F7 tasks complete ✓\n\n### Completed This Session\n- [x] Task 1\n- [x] Task 2\n...\n\nAll tasks complete! You can archive this change with `$openspec-archive-change (Codex) or \u002Fopenspec-archive-change (other agents)`.\n```\n\n**Output On Pause (Issue Encountered)**\n\n```\n## Implementation Paused\n\n**Change:** \u003Cchange-name>\n**Schema:** \u003Cschema-name>\n**Progress:** 4\u002F7 tasks complete\n\n### Issue Encountered\n\u003Cdescription of the issue>\n\n**Options:**\n1. \u003Coption 1>\n2. \u003Coption 2>\n3. Other approach\n\nWhat would you like to do?\n```\n\n**Guardrails**\n- Keep going through tasks until done or blocked\n- Always read context files before starting (from the apply instructions output)\n- If task is ambiguous, pause and ask before implementing\n- If implementation reveals issues, pause and suggest artifact updates\n- Keep code changes minimal and scoped to each task\n- Update task checkbox immediately after completing each task\n- Pause on errors, blockers, or unclear requirements - don't guess\n- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior\n- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred\n- Use contextFiles from CLI output, don't assume specific file names\n- Do not use context or operation guidance as proof that a task is complete\n- Apply relevant project context; report conflicts with controlling workflow inputs\n- Consider every guidance entry; explain any inapplicable or conflicting advice\n- Do not copy runtime context or operation guidance into implementation files or planning artifacts\n- Preserve CLI-controlled blocked\u002Fready\u002Fall-done behavior and completion criteria\n\n**Fluid Workflow Integration**\n\nThis skill supports the \"actions on a change\" model:\n\n- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions\n- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly\n",{"name":5,"license":15,"metadata":42,"description":7,"allowed-tools":45,"compatibility":46},{"author":21,"version":43,"generatedBy":44},"1.0","1.12.0","Bash(openspec:*)","Requires openspec CLI.","main","41de37f5c51137a665ab0b7687bc4dc6552f78aa",".agents\u002Fskills\u002Fopenspec-apply-change",0,"https:\u002F\u002Fgithub.com\u002FMuShi17\u002FRollo-Code","https:\u002F\u002Fgithub.com\u002FMuShi17","2026-09-14 01:06:53",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add MuShi17\u002FRollo-Code --skill openspec-apply-change",{"tool":60,"command":61},"bunx","bunx skills add MuShi17\u002FRollo-Code --skill openspec-apply-change",{"tool":63,"command":64},"pnpm","pnpm dlx skills add MuShi17\u002FRollo-Code --skill openspec-apply-change","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMuShi17\u002FRollo-Code\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-apply-change\u002FSKILL.md",true,[],[69,90,102,119,135],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":37},"01M71PBYXE0VXGS6HV1HMWZ3AH","openspec-update-change","Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.","https:\u002F\u002Fgithub.com\u002FMuShi17\u002FRollo-Code\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-update-change\u002FSKILL.md",[],[21,24,76,77,35,78,79,28,80,29,81,30,82,83,84,85,86,87,88,89],"openspec update change","update","coherent","Fold","artifacts","Existing","new","planning","never","decisions","code","one","with","plan",{"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":37},"01M71PBVSDP6KXTHH93HYHF0BD","openspec-sync-specs","Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.","https:\u002F\u002Fgithub.com\u002FMuShi17\u002FRollo-Code\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-sync-specs\u002FSKILL.md",[],[21,97,98,24,30,47,99,77,35,100,101,88,26,28,29],"sync","openspec sync specs","spec","delta","changes",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":37},"01M71PBSJQYZF6X5N2RCC30ZRN","openspec-propose","Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.","https:\u002F\u002Fgithub.com\u002FMuShi17\u002FRollo-Code\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-propose\u002FSKILL.md",[],[109,21,80,28,29,35,110,111,31,82,112,113,114,115,116,30,24,117,118,88],"openspec propose","describe","generated","design","complete","for","build","get","proposal","ready",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":37},"01M71PBPWQYQ2Z2BZP2E2BR275","openspec-explore","Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.","https:\u002F\u002Fgithub.com\u002FMuShi17\u002FRollo-Code\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-explore\u002FSKILL.md",[],[126,127,21,128,28,29,30,129,114,130,131,132,24,26,133,134,35],"openspec explore","explore","requirements","mode","thinking partner","ideas","thinking","think","partner",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":37},"01M71PBM4QPEJAECB7DAGF3TEY","openspec-archive-change","Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.","https:\u002F\u002Fgithub.com\u002FMuShi17\u002FRollo-Code\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-archive-change\u002FSKILL.md",[],[142,24,21,143,26,28,144,29,30,31,145,113,35],"openspec archive change","archive","workflow","finalize"]