$npx -y skills add henrydiaosi/dorado --skill ospec-changeCreate or advance an active change inside an OSpec project, from requirement intake through verification and finalize.
| 1 | # OSpec Change |
| 2 | |
| 3 | Use this skill when the user says things like "use ospec change to do a requirement". |
| 4 | |
| 5 | ## Scope |
| 6 | |
| 7 | This skill is the single entry for the full change lifecycle inside an initialized OSpec project: |
| 8 | - requirement intake |
| 9 | - change naming or matching |
| 10 | - explicit queue planning when the user asks for queue behavior |
| 11 | - proposal and task refinement |
| 12 | - implementation guidance |
| 13 | - progress tracking |
| 14 | - verification |
| 15 | - archive readiness check |
| 16 | - finalize closeout |
| 17 | |
| 18 | ## Read Order |
| 19 | |
| 20 | 1. `.skillrc` |
| 21 | 2. `SKILL.index.json` |
| 22 | 3. `for-ai/ai-guide.md` |
| 23 | 4. `for-ai/execution-protocol.md` |
| 24 | 5. If Stitch installation, provider switching, doctor remediation, MCP setup, or auth setup is involved, read the repo-local Stitch plugin spec first. When `docs/stitch-plugin-spec.zh-CN.md` exists, treat it as the source of truth for the config shape. |
| 25 | 6. If the user explicitly asks for queue behavior, inspect `changes/queued/` before creating new queue items. |
| 26 | 7. `changes/active/<change>/proposal.md` |
| 27 | 8. `changes/active/<change>/tasks.md` |
| 28 | 9. `changes/active/<change>/state.json` |
| 29 | 10. `changes/active/<change>/verification.md` |
| 30 | 11. `changes/active/<change>/review.md` |
| 31 | |
| 32 | ## Language |
| 33 | |
| 34 | - Follow the project-adopted document language from `for-ai/` and existing change docs. |
| 35 | - Keep Chinese projects in Chinese unless the repo explicitly adopts English. |
| 36 | |
| 37 | ## Plugin Gates |
| 38 | |
| 39 | After reading `.skillrc`, inspect enabled plugins before advancing the change. |
| 40 | |
| 41 | ### Stitch |
| 42 | |
| 43 | When `.skillrc.plugins.stitch.enabled = true` and `.skillrc.plugins.stitch.capabilities.page_design_review.enabled = true`: |
| 44 | |
| 45 | - determine whether the current change activates `stitch_design_review` from proposal `flags` and `tasks.md` / `verification.md` `optional_steps` |
| 46 | - if activated, read `changes/active/<change>/artifacts/stitch/approval.json` |
| 47 | - if `approval.json.preview_url` or `submitted_at` is empty, run `ospec plugins run stitch <change-path>` before asking the user to review the design |
| 48 | - if `.skillrc.plugins.stitch.project.project_id` is already configured, reuse that exact Stitch project instead of creating a new project |
| 49 | - if `.skillrc.plugins.stitch.project.project_id` is empty, treat the first successful Stitch run as the canonical project and keep using it for later changes |
| 50 | - treat missing approval or `status != approved` as a blocking gate |
| 51 | - do not claim the change can continue implementation closeout or archive readiness until Stitch approval is complete |
| 52 | - treat the built-in `stitch` plugin with the configured provider adapter as the default path unless `.skillrc.plugins.stitch.runner` is explicitly overridden |
| 53 | - if a custom runner is configured and `token_env` is set but missing, stop and request configuration first |
| 54 | - if runner readiness, provider CLI, stitch MCP, or auth readiness is unclear, use `ospec plugins doctor stitch <project-path>` before `ospec plugins run stitch <change-path>` |
| 55 | - if Stitch installation, provider switching, doctor remediation, MCP setup, or auth setup is involved, read the repo-local Stitch plugin spec first; when `docs/stitch-plugin-spec.zh-CN.md` exists, use its documented Gemini / Codex config snippets instead of inventing `command` / `args` / `env` or stdio-proxy settings |
| 56 | - if the repo-local Stitch spec is missing, use these built-in baselines instead of guessing: |
| 57 | - `gemini`: `%USERPROFILE%/.gemini/settings.json` -> `mcpServers.stitch.httpUrl = "https://stitch.googleapis.com/mcp"` and `headers.X-Goog-Api-Key` |
| 58 | - `codex`: `%USERPROFILE%/.codex/config.toml` -> `[mcp_servers.stitch]`, `type = "http"`, `url = "https://stitch.googleapis.com/mcp"`, and `X-Goog-Api-Key` in `headers` or `[mcp_servers.stitch.http_headers]` |
| 59 | - use `ospec plugins approve stitch <change-path>` or `ospec plugins reject stitch <change-path>` to record the review result |
| 60 | |
| 61 | ## Required Logic |
| 62 | |
| 63 | 1. Inspect repository state first when posture is unclear. |
| 64 | 2. If the repo is not initialized, stop at initialization guidance instead of forcing a change. |
| 65 | 3. If the request is a new requirement, derive a concise kebab-case change name and create it. |
| 66 | 4. If the matching active change already exists, continue it instead of duplicating it. |
| 67 | 5. Default to one active change unless the user explicitly asks to split work into multiple changes, create a queue, or execute a queue. |
| 68 | 6. When queue behavior is explicitly requested, derive an ordered list of concise kebab-case change names. Each name should represent one execution unit, not a mixed bundle. |
| 69 | 7. For explicit queue planning, present the queue as an ordered list first. Use `ospec queue add ...` to create queued changes and `ospec run ...` only when the user explicitly asks to run the queue. |
| 70 | 8. Treat `changes/active/<change>/` as the execution container. |
| 71 | 9. Keep `proposal.md`, `tasks.md`, `state.json`, `verification.md`, and `review.md` aligned with actual execution and with the project's established do |