spec-kitty

# spec-kitty Use this skill when the user seems to want Spec Kitty involved and the request is not clearly a full mission workflow. Spec Kitty does not spawn another LLM. You are the host. Spec Kitty routes the request, assembles governance context, opens an Op record, and returns. You then do the work under that governance context and close the Op with the real outcome. ## Default Mental Model If the user says anything like "use spec kitty to ...", "hey spec kitty ...", "spec kitty fix ...", or "spec kitty <anything>", treat it as a standalone governed invocation unless they clearly ask for a full mission. Run: ```bash spec-kitty dispatch "<request verbatim>" --json ``` If the user names a specific profile, or you have a strong reason to bypass routing, pass it explicitly: ```bash spec-kitty dispatch "<request verbatim>" --profile <profile-id> --json ``` Do not answer directly before dispatching. The point is to load governance and record the Op before doing the work. ## The open->work->close contract Every standalone invocation follows the same three-step lifecycle: 1. **Open** — `spec-kitty dispatch` opens the Op and loads governance context. It does not do the work and it does not close the Op. 2. **Work** — read `governance_context_text` and do the work under that binding context. 3. **Close** — close the Op with the real outcome: ```bash spec-kitty profile-invocation complete \ --invocation-id <id> \ --outcome <done|failed|abandoned> [...