/spec-kitty

name: spec-kitty
description: >-
  Standalone Spec Kitty governance invocation: run Spec Kitty when the user
  indicates they want Spec Kitty involved, load governance context, open an Op,
  do the work under that context, and close the Op with the real outcome.
  Documents dispatch, profiles list, invocations list, and
  profile-invocation complete. Triggers: "use spec kitty to", "hey spec kitty",
  "spec kitty <anything>", ad-hoc requests that are not part of a running full
  mission workflow.

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:

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:

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.

When the user asks to show, explain, compare, map, or visualize the governed work—or when dense prose hides its structure—also load `spk-practice-show-me`. Use its smallest-useful-visual rule while keeping the dispatch lifecycle here authoritative.

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:

   spec-kitty profile-invocation complete \
     --invocation-id <id> \
     --outcome <done|failed|abandoned> [--evidence <path>]

Failed work closes as `failed`; dropped work closes as `abandoned`. Never leave an Op open deliberately. `spec-kitty doctor ops` reports orphaned open Ops, and `spec-kitty doctor ops --close-stale` sweeps stale ones closed as `abandoned` with `closed_by: doctor_sweep`.

Usage

Discover profiles

spec-kitty profiles list --json

Profiles are an optional routing escape hatch, not the primary UX.

Open a governed invocation

spec-kitty dispatch "implement WP03" --json
spec-kitty dispatch "review this migration" --profile reviewer --json

Response fields:

| Field | Type | Description | |-------|------|-------------| | `invocation_id` | string (ULID) | Unique ID for this Op | | `profile_id` | string | Resolved profile identifier | | `action` | string | Normalised action string | | `governance_context_text` | string or null | Full governance context assembled from the project DRG; `null` in `--brief` mode | | `governance_context_hash` | string | SHA-256 hash of `governance_context_text` | | `governance_context_available` | boolean | `false` when charter has not been synthesised | | `governance_context_reference` | object, `--brief` only | Digest, size, line count and fetch command standing in for the omitted text | | `router_confidence` | string or null | Routing confidence score | | `status` | `"open"` | The Op is open until you close it | | `close_contract` | object | Exact close command, accepted outcomes, and flags |

Governance context injection

After calling `dispatch`, the response includes `governance_context_text`.

You must inject this text into your working context before executing the task.

Steps: 1. Read `governance_context_text` from the JSON response. 2. Add the text to the beginning of your task execution context. Treat it as binding governance: follow any directives, constraints, and guidelines it contains when generating code, plans, or analyses. 3. If `governance_context_available` is `false`, note it to the user ("governance context unavailable — run `spec-kitty charter synthesize` to build the DRG") but proceed with the task. The Op trail is still recorded. 4. After completing the work, close the Op.

Re-dispatching in the same session (`--brief`)

The payload is ~13-26 KB and nearly all of it is unchanged between two dispatches of the same profile and action. Once this session has read the full text, re-dispatch with `--brief`: the response keeps the routing fields, sets `governance_context_text` to `null`, and returns `governance_context_reference` — a digest, the size, and the command that fetches the text again:

spec-kitty dispatch "review the migration" --profile reviewer-renata --brief --json
# governance_context_reference.fetch_command:
#   spec-kitty charter context --action review --profile reviewer-renata --json --no-mark-loaded

Rules that keep briefing honest:

• The **first** read for a profile/action in a session must be the full text

(or the fetch command's `text` field). `--brief` is for re-reads, not for skipping governance: dispatch still assembles the context on every call, and never suppresses it on its own.

• The reference is emitted only when the text exists and the printed command

reproduces it; fetching must not change first-load state, hence `--no-mark-loaded`.

• The reference is a command, not a snapshot: it rebuilds the text on fetch, so

charter, DRG or profile changes made after dispatch can change it. Compare the first 16 hex characters of the SHA-256 of the fetched `text` with `digest`; on a mismatch, discard it and re-dispatch without `--brief`.

• The Op record, the close contract and the glossary scan are identica