spec-kitty.review

## Startup Upgrade Check

Run this at most once per active agent session before the first Spec Kitty command workflow.
If you already ran `spec-kitty upgrade --agent-check --json` in this session, reuse that result and skip this block.
Do not run or announce an upgrade check again for later Spec Kitty commands in the same session.
Otherwise, before continuing, run:

```bash
spec-kitty upgrade --agent-check --json
```

If JSON `action` is `none`, continue.
If `action` is `auto_upgrade`, run `upgrade_command` before continuing. If it fails, tell the user and continue with the current Spec Kitty version.
If `action` is `guidance`, show `upgrade_note` briefly, then continue.
If `action` is `prompt`, ask the user with the host-native question UI when available:

`Spec Kitty {latest_version} is available. You are on {installed_version}. Upgrade now?`

Use these choices:

1. Upgrade now (recommended) - record `upgrade_now`, run `upgrade_command`, then continue.
2. Always keep me up to date - record `always`, run `upgrade_command`, then continue.
3. Not now - record `not_now`, then continue.
4. Never ask again - record `never_ask`, then continue.

Record the selected choice before continuing:

```bash
spec-kitty upgrade --agent-choice <upgrade_now|always|not_now|never_ask> --agent-latest <latest_version> --json
```

If no host-native question UI is available, present the same four choices in plain text and wait for the user.
In non-interactive hosts, choose `not_now` and continue.


# /spec-kitty.review - Review Work Package Implementation

**Version**: 0.12.0+

## Purpose

Review the implementation of a work package against its prompt file, acceptance
criteria, and owned-file boundaries. Verify correctness, test coverage, and
compliance with any applicable guardrails (e.g., bulk edit occurrence maps).

---

## Working Directory

**IMPORTANT**: This step works inside the execution workspace (worktree)
allocated by `spec-kitty agent action review WPxx --agent <name>`. Prefer to stay within
your `owned_files` boundaries; any out-of-map change must be small, justified, and carry a
one-line rationale in the commit message.

**In repos with multiple missions, always pass `--mission <handle>` to every spec-kitty command.** The `<handle>` can be the mission's `mission_id` (ULID), `mid8` (first 8 chars of the ULID), or `mission_slug`. The resolver disambiguates by `mission_id` and returns a structured `MISSION_AMBIGUOUS_SELECTOR` error on ambiguity — there is no silent fallback.

## User Input

The content of the user's message that invoked this skill (everything after the skill invocation token, e.g. after `/spec-kitty.<command>` or `$spec-kitty.<command>`) is the User Input referenced elsewhere in these instructions.

You **MUST** consider this user input before proceeding (if not empty).

## Governance Payload Contract

The prompt produced by `spec-kitty agent action review` is guaranteed to carry
the following surfaces. Trust the prompt; do not consult external governance
sources unless explicitly cited by a fetch command + when-doing rule in the
prompt.

**Guaranteed bodies** (verbatim in the prompt when under the token budget; the
resolver substitutes a `spec-kitty charter context --include section:<slug>`
fetch + when-doing stanza only when the budget would otherwise be exceeded):

- **Terminology Canon** — from `.kittify/charter/charter.md` — governs the
  identifiers and term usage you assess in the diff.
- **Code Review Checklist** — from `.kittify/charter/charter.md` — your
  primary gate set when judging the WP.
- **Regression Vigilance** — from `.kittify/charter/charter.md` — the
  project's explicit drift guard; apply when the diff renames or introduces
  identifier-bearing terms.
- Any additional action-critical sections the mission declares are appended
  automatically.

**Guaranteed citations** (catalog IDs always present in the prompt when the
WP frontmatter selects a reviewer `agent_profile`):

- Every `DIRECTIVE_NNN` declared in the loaded reviewer profile's
  `directive-references` list (for example, `reviewer-renata` cites
  `DIRECTIVE_032` — Conceptual Alignment).
- Every tactic-id declared in the loaded reviewer profile's
  `tactic-references` list (for example, `reviewer-renata` cites the
  `language-driven-design` tactic).

When you assess a WP that renames identifiers or terms, the prompt cites
DIRECTIVE_032 (Conceptual Alignment) by ID; consult its rule body inline or
via the paired fetch command and apply.

**Guaranteed authority pointers** (path + when-doing conditional):

- `glossary/contexts/` — canonical terminology. Consult when the diff
  introduces or renames a domain term.
- `architecture/2.x/adr/` — architectural intent. Consult when the diff
  changes a structural boundary (package layout, public API surface,
  dependency edges).
- Any additional paths declared in the charter's `authority_paths:` block are
  emitted alongside these defaults.

**Fetch commands** (the prompt may substitute these for bodies that exceed the
token budget; whenever a fetch command appears, the accompanying
"When you <verb>, run this and apply" line specifies the trigger):

- `spec-kitty charter context --include directive:DIRECTIVE_NNN`
- `spec-kitty charter context --include tactic:<id>`
- `spec-kitty charter context --include section:<slug>`

## Review Steps

### 1. Setup

Run:

```bash
spec-kitty agent context resolve --action review --mission <handle> --json
```

Then execute the returned `check_prerequisites` command and capture
`feature_dir`. All paths must be absolute.

The output of `spec-kitty agent action review ...` is the authoritative work
package prompt and review context. Do **not** separately call
`spec-kitty charter context` or go hunting for alternate prompt files unless
the command output tells you to. The **Governance Payload Contract** section
above documents what the prompt is guaranteed to carry.

### 2. Load Work Package Prompt

Read the WP prompt file from `featu