spec-kitty/spec-kitty

# Adversarial Squad Deployment (harness)

The operational alias for the doctrine procedure `adversarial-squad-deployment`
(`packs/built-in/procedures/adversarial-squad-deployment.procedure.yaml`), which is
the single owner of when, who, and how to run a squad. This skill changes **no**
mission type or guard; it is a technique the orchestrator opts into.

## Load the procedure

Before dispatching, load the procedure's full playbook:

```
spec-kitty charter context --include procedure:adversarial-squad-deployment
```

# 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

# spec-kitty-git-workflow

Understand the boundary between what spec-kitty's Python code does with git
and what LLM agents are expected to do. This boundary is critical — agents
that try to create worktrees manually or skip implementation commits will
break the workflow.

---

## The Core Boundary

**Python handles infrastructure git** — worktrees, lane commits, merges,
cleanup. **Agents handle content git** — implementation commits, rebases,
conflict resolution.

# spec-kitty-implement-review

Orchestrate the implement-review loop for Spec Kitty work packages. This skill
teaches any agent how to dispatch implementation and review to the configured
agents, handle rejection loops, enforce cycle limits, and sequence WPs by
dependency graph.

## When to Use This Skill

- Implement one or more WPs through the full implement-review cycle
- Coordinate cross-agent workflows (different agents for implement vs review)
- Handle rejection feedback loops with cycle tracking
- Run a full mission sprint (WP01 through WP_N)

# spec-kitty-mission-review

You are the expert senior reviewer for a completed Spec Kitty mission. The
mission has been fully implemented, all WPs have been approved, and the feature
branch has been merged. Your job is to answer a single question with documented
evidence: **does the merged code accurately and completely realize the spec, and
are there risks the implementation team did not surface?**

This is not a checklist exercise. It is structured adversarial analysis. You
read the spec as the author's promise and the code as the executor's delivery,
and you measure the gap. Every finding you produce must be traceable to an
artifact (a spec section, a git diff line, a test file, a contract clause). You
do not fix anything. You document.

# spec-kitty-mission-system

Understand how missions structure work in Spec Kitty. A mission is a
domain-specific workflow blueprint that defines what steps you go through,
the template each step provides, what artifacts you produce, and how to
validate success.

---

## How Missions Work

### The Core Concept

A mission answers: "What process should we follow to achieve this goal?"

# spec-kitty-orchestrator-api-operator

Teach agents and external systems how to use `spec-kitty orchestrator-api` to
drive workflows from outside the host CLI. The orchestrator-api is the only
supported entry point for external automation -- direct frontmatter mutation,
git worktree manipulation, or internal CLI internals are not part of the
contract.

---

## When to Use This Skill

- Build an external orchestrator that drives spec-kitty workflows
- Integrate CI/CD pipelines with spec-kitty state transitions

# spec-kitty-program-orchestrate

You are the program orchestrator for a multi-repo Spec Kitty effort. A single
"program" is a coordinated feature release that spans two or more repositories
in a specific sequence (often with cross-repo contract dependencies): e.g.
"Decision Moment V1" that touches an events repo, a SaaS backend, a CLI, a
web app, and two test-surface repos.

Your job is to drive the program from kickoff to "all repos merged + all
mission reviews cleared + all post-merge remediations landed" without
requiring the user to hand-hold each transition. You rely on
`spec-kitty-implement-review` to drive each individual mission, on
`spec-kitty-mission-review` to audit each merged mission, and on background
sub-agents to execute phases in parallel where dependencies allow.

# spec-kitty-runtime-next

This skill teaches agents how to advance a Spec Kitty mission through the
canonical runtime control loop, including doctrine-aware context loading at
each step boundary.

## When to Use This Skill

Use this skill when the user wants to:

- Advance a mission to its next step
- Understand what the runtime will do next
- Unblock a stalled mission
- Interpret runtime outcomes (step, blocked, decision_required, terminal)

# spec-kitty-runtime-review

Operate the Spec Kitty review workflow surface: load review context, claim a
work package, read the generated review prompt, and issue an approve or reject
transition.

## When to Use This Skill

- Claim a completed work package for review
- Read the review prompt generated by the review workflow
- Issue an approval or rejection with structured feedback

## Step 1: Load Review Context

# spec-kitty-setup-doctor

Diagnose and repair the Spec Kitty installation for the current project and agent.

Use this skill when the user reports that Spec Kitty is not working, skills are
missing, slash commands are unavailable, or the runtime environment appears broken.

---

## Start here: one command

Inside an initialized project, `spec-kitty doctor` with no subcommand already runs the
fast, read-only, project-level checks (`command-files`, `state-roots`, `ops`), prints one
line per check naming the subcommand behind it, and exits 0 when every check is healthy

# spk-admin-agent-config

Use this skill when the user needs to configure Codex, Claude, OpenCode, or
another agent for Spec Kitty.

## Flow

1. Identify the active host and project root.
2. Verify skill and command install locations for that host.
3. Confirm the agent name used by `spec-kitty next --agent <name>`.
4. Load profile doctrine through `spk-charter-profile-load` when needed.
5. Use `spk-start-agent-surface` for host capability differences.

## Rule

# spk-admin-git-workflow

Use this skill when Spec Kitty work involves git operations, worktree lifecycle,
branch state, commits, merge blockers, or stale repository state.

## Flow

1. Inspect the active mission, branch, worktree, and target branch.
2. Let Spec Kitty-managed git operations run through the CLI when available.
3. Perform manual git operations only when the workflow explicitly requires it.
4. Preserve user changes and avoid destructive repair.
5. Return to `spk-gate-merge` or `spk-run-blocked-recovery` after repair.

## Legacy Alias

# spk-admin-setup-doctor

Use this skill when Spec Kitty is missing commands, skills, runtime files,
agent config, or expected local behavior.

## Flow

1. Run `spec-kitty doctor` first: a bare invocation runs the fast, read-only default
   checks (`command-files`, `state-roots`, `ops`) and exits 0 when healthy, 1 when a check
   reports a finding, naming the subcommand behind it. Drill into
   `spec-kitty doctor <subcommand>` (add `--json` for machine-readable detail) and use the
   subcommand's repair flag (`--fix`, `--repair`, `--close-stale`) only for the surface it
   flags.
2. Verify slash commands and skills exist for the active agent surface.

# spk-admin-upgrade

Use this skill when the user asks to upgrade Spec Kitty or repair stale
generated assets after a version change.

## Flow

1. Identify installed version and project version.
2. Run the supported upgrade command.
3. Review migration output for command and skill repairs.
4. Re-run setup/doctor checks with `spk-admin-setup-doctor`.
5. Do not edit generated installed skills directly; update source skills or
   command templates.

# spk-charter-glossary

Maintain semantic integrity by curating the project glossary, detecting term
drift, and ensuring that all mission artifacts use canonical terminology.

Use this skill when the user asks about canonical terms, glossary updates,
terminology drift, or domain language consistency. Do not use it for purely
operational tasks like advancing the runtime loop or repairing an
installation.

## Flow

1. Locate active glossary context.
2. Check conflicts and strictness before changing anything.

# spk-charter-governance

Use this skill for project governance, charter creation, or charter context
questions.

`.kittify/charter/charter.yaml` is the runtime governance source for a
project; `.kittify/charter/charter.md` is a human-readable companion the
runtime never parses. The charter offering (`src/charter/offering/`) supplies
the reusable directives, tactics, paradigms, styleguides, toolguides,
procedures, agent profiles, and step contracts the charter references.

## Invariant

spec-kitty never calls an LLM. The harness running this skill is the

# spk-charter-profile-load

Use this skill when the agent needs a profile outside the runtime loop or the
user asks to adopt a specific role.

## Resolver-Backed Flow

1. Identify the requested profile, action, and active Mission context.
2. Resolve the profile through the CLI:

   ```bash
   spec-kitty agent profile show <profile-id>
   ```

# spk-charter-spdd-reasons

Use this skill when a mission opts into SPDD, REASONS Canvas work, or structured
prompt rationale review. The canvas is a thin, agent-curated reasoning layer
next to the spec, plan, and tasks, stored at
`kitty-specs/<mission>/reasons-canvas.md`.

## Flow

1. Confirm SPDD is selected by charter or mission context
   (`is_spdd_reasons_active` in `src/charter/offering/spdd_reasons/activation.py`).
2. Author or review the REASONS Canvas before downstream prompts depend on it,
   using its seven sections: Requirements, Entities, Approach, Structure,
   Operations, Norms, Safeguards.

# spk-gate-accept

Use this skill when runtime reaches terminal state, the user asks to accept a
mission, or all WPs appear complete.

## Flow

1. Run `/spec-kitty.accept` or the equivalent CLI command.
2. Confirm all required WPs are approved or done.
3. Verify required tests, artifacts, and mission invariants. When the mission
   changed typed sources, run the project's configured compiler/typecheck
   command, matching CI, in addition to the test runner. A failed compiler
   command fails the gate; passing behavioral tests are not a substitute.
4. If accept fails, route to `spk-run-blocked-recovery`.

# spk-gate-consolidate

Use this skill after `spk-gate-accept` passes or when a user asks to
consolidate a mission (merge its lanes into the target branch).

## Flow

1. Confirm the mission passed accept.
2. Run `/spec-kitty.consolidate` or the equivalent CLI command.
3. Resolve git/worktree blockers with `spk-admin-git-workflow`.
4. After consolidation, route to `spk-gate-mission-review`.
5. Then route to `spk-gate-retrospective`.

## Rule

# spk-gate-mission-review

Use this skill after a mission has merged or when the user asks for a mission
review.

## Flow

1. Compare spec, plan, tasks, WPs, reviews, and merged code.
2. Trace functional requirements to implementation evidence.
3. Identify drift, missing tests, security concerns, and follow-up issues.
4. Produce a final verdict and record follow-ups.

## Legacy Alias

# spk-gate-retrospective

Use this skill after merge and mission review, or when the user asks what was
learned from a mission.

## Flow

1. Locate the mission's review and closeout artifacts.
2. Run or request retrospective creation when the workflow supports it.
3. Summarize process issues, recurring blockers, and useful follow-up work.
4. Keep product bugs and process improvements separate.

## Completion Standard

# spk-integrate-orchestrator-api

Use this skill when an agent, script, CI job, or external service needs to drive
Spec Kitty through orchestrator-api.

## Flow

1. Identify the external caller and allowed host boundary.
2. Use documented API contracts rather than scraping local artifacts.
3. Preserve state-machine invariants: no implicit success, no skipped gates.
4. Route mission advancement through runtime decisions.
5. A `PREFLIGHT_FAILED` without a `teardown_error_code` is raised before any lane/target mutation; a refusal leaves refs untouched.

## Legacy Alias

# spk-meta-skill-authoring

Use this skill when creating or revising a Spec Kitty skill.

## Rules

1. Name public operating skills `spk-<family>-<action-or-topic>`.
2. Keep generated `spec-kitty.<command>` slash-command files separate from
   generated `spec-kitty-<command>` command skills.
3. Preserve the older `spec-kitty-<topic>` guide skills (for example
   `spec-kitty-runtime-next`) when they remain useful aliases or detailed
   workflows. Never give a new skill a `spec-kitty-<command>` name: those
   names belong to the generated command skills.
4. Keep mission behavior in doctrine mission composition, not in skill prose.

# spk-meta-skill-map

Use this skill when the user asks what skills exist, how `spk-*` names are
organized, or which skill applies.

## Naming Convention

Use `spk-<family>-<action-or-topic>`.

Legacy family means the pre-3.2.0 `spec-kitty-*` compatibility skills that
remain alongside the newer `spk-*` hierarchy.

Families:

# spk-mission-documentation

Use this skill when the mission is primarily documentation, release notes,
guides, or user-facing explanation.

## Flow

1. Confirm whether this is a documentation mission or a software mission with
   docs as acceptance criteria.
2. Ground docs in current product behavior, not intended future behavior unless
   clearly marked.
3. Cross-check terms with `spk-charter-glossary`.
4. If docs describe commands or workflows, cross-check `spk-start-command-map`.

# spk-mission-plan

Use this skill when a mission has a spec and needs an implementation plan.

## Flow

1. Invoke `/spec-kitty.plan` against the active mission.
2. Ground the plan in the spec and existing repo architecture.
3. Make tradeoffs explicit: interfaces, data flow, migration needs, tests,
   rollout, and risks.
4. Route research gaps to `spk-mission-research`.
5. Route unclear mission type or workflow questions to `spk-mission-types`.
6. For non-trivial architecture, data/control flow, boundaries, migrations, or
   risky interactions, load `spk-practice-show-me` and use diagrams where they

# spk-mission-research

Use this skill when a mission needs discovery, external facts, design precedent,
technical investigation, or decision support.

## Flow

1. Use `/spec-kitty.research` for pre-spec discovery, before a spec or plan
   exists: capture decisions, evidence, and open questions directly in
   `research.md` (create or extend it; never truncate it).
2. On a mission type that ships research templates (today: the `research`
   mission type), once that mission's plan is filled in you can additionally
   run `spec-kitty research --mission <handle>` to scaffold `research.md`,
   `data-model.md`, and the CSV stubs from the shipped templates. Other

# spk-mission-specify

Use this skill when creating or revising a mission specification.

## Flow

1. Run or invoke `/spec-kitty.specify` for the feature.
2. Capture the user's concrete goal, constraints, non-goals, and success
   criteria.
3. Keep unresolved product decisions explicit instead of hiding them in plan
   details.
4. If terminology matters, route to `spk-charter-glossary`.
5. If governance affects scope, route to `spk-charter-governance`.
6. When a non-trivial user flow, domain lifecycle, rule, or concept boundary is

# spk-mission-tasks

Use this skill when converting a plan into executable tasks or work packages.

## Flow

1. Use `/spec-kitty.tasks` for the default path.
2. Use `/spec-kitty.tasks-outline`, `/spec-kitty.tasks-packages`, and
   `/spec-kitty.tasks-finalize` when staged work-package authoring is enabled.
3. Keep package boundaries reviewable: each WP should have a clear scope,
   dependencies, verification, and expected files or systems.
4. If WPs are too broad for implementation/review lanes, split before runtime
   execution begins.

# spk-mission-types

Use this skill when the user asks which kind of mission to run or how mission
types differ.

## Workflow

1. Identify the requested work: software change, standalone planning,
   documentation, research, or custom/team workflow.
2. Compare available mission types before creating new process.
3. Use the legacy `spec-kitty-mission-system` skill for detailed step-contract,
   procedure, action-index, and template-resolution mechanics.

## Boundary

# spk-practice-bulk-edit

Use this skill when the user asks for a broad rename, replace, migration,
classification, or other multi-occurrence edit. The same token carries
different meaning depending on where it appears, so treating every occurrence
the same is how silent breakage happens (DIRECTIVE_035).

The user will not say "bulk edit". Recognize the shape, set
`change_mode: bulk_edit` in the mission's `meta.json`, and drive the
classification workflow before any code changes.

## Flow

1. Perform a manual pre-edit occurrence review before changing matches.

# spk-practice-semantic-compression

Use this skill when the user asks to reduce, simplify, deduplicate, delete dead
code, or refactor while preserving existing behavior.

## Flow

1. Load agent profile `randy-reducer`.
2. Load paradigm `semantic-compression`.
3. Map the behavioral envelope before editing.
4. Find exact, parameterized, structural, and semantic redundancy.
5. Extract one implementation per concept or delete proven dead weight.
6. Consolidate competing behavioral paths behind one canonical owner.
7. Verify equivalence and report evidence plus residual risk.

# spk-practice-show-me

Make the current point visible. Skip the preamble, keep prose brief, and pick
the smallest representation that answers the question. Do not add a diagram
when a sentence or short list is clearer.

## Choose the Shape

- Logic or an algorithm: compact pseudocode.
- Runtime behavior: call tree or sequence diagram.
- UI composition: component tree with only relevant state and boundaries.
- Ownership or refactor scope: shallow file tree with one responsibility per entry.
- Existing-to-proposed change: `diff` over the matching tree, flow, or pseudocode.
- Domain lifecycle: state diagram.

# spk-run-blocked-recovery

Use this skill when `next`, review, accept, merge, or sync output
shows a blocker.

## Flow

1. Capture the exact command and blocker output.
2. Classify the blocker: missing artifact, invalid state, guard failure,
   worktree/git issue, sync issue, auth issue, or user decision required.
3. Use the nearest specialist skill: setup doctor, git workflow, team sync,
   review, accept, or merge.
4. Make one repair, rerun the same command, and compare output.
5. Escalate to the user only when the command requires a product decision or

# spk-run-implement-review

Use this skill when a mission is in implementation/review lanes or the user
wants the agent to coordinate implementers and reviewers.

## Flow

1. Use `spk-run-next` to identify the active WP and lane.
2. Dispatch implementation only from runtime-provided prompt context.
3. Review each WP independently with `spk-run-review-wp`.
4. On rejection, feed structured reviewer feedback back into the next
   implementation attempt.
5. Continue until runtime returns terminal or a blocker.

# spk-run-next

Use this skill when advancing an active mission, asking what to do next, or
recovering from a runtime decision.

## Flow

1. Query state with `spec-kitty next --mission <handle> --json` or advance with
   `spec-kitty next --agent <name> --mission <handle> --result <success|failed|blocked>`.
2. Read the returned decision kind.
3. For `query`, inspect only; do not execute a prompt or mark a result.
4. For `step`, execute the generated prompt file.
5. For `decision_required`, answer with `--answer`, `--result`, `--agent`, and
   `--decision-id` when multiple decisions are pending.

# spk-run-program-orchestrate

Use this skill when a user wants to coordinate several related Spec Kitty
missions or repositories as one program.

## Flow

1. Build the mission dependency order before launching work.
2. Use `spk-run-next` for each mission's authoritative next action.
3. Coordinate parallel implementation only where dependencies allow.
4. Keep review, accept, merge, mission-review, and retrospective gates per
   mission.
5. Surface blockers as program risks without bypassing mission-level gates.

# spk-run-review-wp

Use this skill when the user asks to review a WP, approve/reject work, or
operate the review workflow surface.

## Flow

1. Claim or select the WP from the runtime/review output.
2. Compare implementation against WP scope, spec, plan, and acceptance checks.
3. Approve only when behavior and verification satisfy the WP.
4. Reject with concrete, actionable feedback and affected files or commands.
5. Let `spk-run-implement-review` continue the loop.

## Recording the verdict

# spk-run-verdict-capture

Use this skill whenever an agent (any of the 12 slash-command harnesses or the shared
Agent-Skill harnesses) needs to **record the outcome of a WP review** — approve, reject, or
otherwise. It documents the single deterministic seam so verdicts never diverge by harness.

## The authoritative seam

The **sole** authority for a WP's review verdict is the `review_result` event in the mission's
`status.events.jsonl` (read back via `specify_cli.status.event_sourced_review_result`). The
`review-cycle-N.md` render is **non-authoritative prose** — do not hand-edit it to change a
verdict, and never treat it as the source of truth. Because the verdict is an event, it is
append-only, deterministic, and identical across every agent.

# spk-start-agent-surface

Use this skill when the question is about where Spec Kitty works, how commands
or skills appear in a specific agent, or why behavior differs by surface.

## Checks

1. Identify the surface: command line, Codex, Claude Code, slash-command host,
   or command-skill host.
2. Check whether slash commands, skills, and local filesystem access are
   available in that surface.
3. If commands are missing, route to `spk-admin-setup-doctor`.
4. If the user needs compatibility research, use the legacy
   `spec-kitty-agent-surface-research` skill when installed.

# spk-start-command-map

Route command questions without conflating command wrappers and operating
skills.

## Flow

1. Read `references/command-map.md`.
2. Choose the command for execution and the `spk-*` skill for operating
   guidance.
3. If the user asks for discovery rather than a command, route to
   `spk-meta-skill-map`.

## Boundary

# spk-start-first-feature

Use this skill when a user wants to start their first Spec Kitty mission or
feature and needs the end-to-end path.

## Workflow

1. Verify install and agent surface with `spk-admin-setup-doctor` if commands or
   skills are missing.
2. Create or select the mission with `/spec-kitty.specify`.
3. Build the plan with `/spec-kitty.plan`.
4. Produce work packages with `/spec-kitty.tasks` or the outline/packages/finalize
   split when the project uses staged task authoring.
5. Advance work with `spk-run-next`.

# spk-start-here

Orient the user by where they are working: command line or supported agent
harness.

## Access Model

- Command-line users run `spec-kitty` CLI commands. `spk-*` skills are not CLI
  commands.
- Agent-harness users invoke installed command surfaces:
  `/spec-kitty.<command>` in slash-command hosts, or the `spec-kitty-<command>`
  command skill in skill hosts (`$spec-kitty-<command>` in Codex,
  `/skill:spec-kitty-<command>` in Pi, `/spec-kitty-<command>` in Vibe, Letta
  and Antigravity).

<!-- Generated by spec-kitty from a charter pack skill. A local edit is kept and reported as drift; to change this skill, edit its pack source and re-run the activation. -->

# Skill triage

## Instructions

Run triage: $ARGUMENTS

<!-- Generated by spec-kitty from a charter pack skill. A local edit is kept and reported as drift; to change this skill, edit its pack source and re-run the activation. -->

# Skill triage

## Instructions

Run triage: $ARGUMENTS

# spk-doctrine-charter

Use this skill for project governance, charter creation, charter sync, or
doctrine context questions.

## Flow

1. Invoke `/spec-kitty.charter` or the relevant charter command.
2. Keep governance decisions explicit and versioned.
3. Load charter context on demand, scoped to the active action.
4. Use glossary and SPDD skills when the charter selects those practices.

## Legacy Alias

# spk-doctrine-glossary

Use this skill when the user asks about canonical terms, glossary updates,
terminology drift, or domain language consistency.

## Flow

1. Locate active glossary context.
2. Classify the change: new term, alias, conflict, drift, or usage correction.
3. When shaping a domain model or resolving a contested term, use the detailed
   `spec-kitty-glossary-context` workflow to pressure-test the model before
   recording it.
4. Update or apply terminology without rewriting unrelated docs.
5. Feed domain language back into spec, plan, and documentation skills.

# spk-doctrine-show-me

Make the current point visible. Skip the preamble, keep prose brief, and pick
the smallest representation that answers the question. Do not add a diagram
when a sentence or short list is clearer.

## Choose the Shape

- Logic or an algorithm: compact pseudocode.
- Runtime behavior: call tree or sequence diagram.
- UI composition: component tree with only relevant state and boundaries.
- Ownership or refactor scope: shallow file tree with one responsibility per entry.
- Existing-to-proposed change: `diff` over the matching tree, flow, or pseudocode.
- Domain lifecycle: state diagram.

## 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:

## 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:

## 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.