spec-kitty.charter

## 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.charter - Interview + Compile Charter

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

## Repo Scope

`/spec-kitty.charter` is a repo-scoped governance flow, not a per-mission flow.

- Run it from the repository root.
- Do **not** try to resolve a mission handle for this command.
- For charter subcommands, `--mission-type` means the reusable mission blueprint
  (for example `software-dev` or `documentation`), not a mission instance in
  `kitty-specs/`.
- The hidden `--mission` flag on `spec-kitty charter ...` is only a deprecated
  alias for `--mission-type`.

If you need deterministic context before interviewing:

1. Confirm you are in the repo root.
2. Check whether a charter already exists:

```bash
spec-kitty charter status --json
```

3. If needed, inspect available mission blueprints:

```bash
spec-kitty mission list
```

For this command, the default mission type is `software-dev` unless the user
explicitly wants a different mission blueprint.

## Skill Load

Before proceeding, load the `spec-kitty-charter-doctrine` skill for the charter
lifecycle model, doctrine access patterns, and action-context rules.

If the skill conflicts with this command contract, follow this command contract.

## Command Contract

This command owns charter discovery in chat. Do not default to
`spec-kitty charter interview --defaults` unless the user explicitly asks for a
fast bootstrap with canned defaults.

Listen intently to what the human-in-command says next. If any form of charter
already exists, assume the user is probably flagging a charter addition, course
correction, or new guidance they noticed while observing Spec Kitty or agent
behavior. Do not restart a full interview unless the user asks for one or the
existing charter is clearly unusable. The default goal is to update the charter
with the new guidance.

The CLI charter workflow is a compiler and persistence surface, not the primary
interview experience. Your job is to:

1. Inspect the repo quickly to form an initial governance hypothesis.
2. Discover the intended charter change in chat. For an existing charter, ask
   focused follow-up questions about the new guidance; for a missing charter,
   run a short targeted interview.
3. Synthesize the answers into `.kittify/charter/interview/answers.yaml`.
4. Run `spec-kitty charter generate --from-interview --json`.
5. Verify generation with `spec-kitty charter status --json`.

Do not preload governance context for all workflow actions as part of charter
generation. Action context is loaded iteratively at the actual action boundary.

## Doctrine Gaps

If no built-in paradigm or directive cleanly fits the user's needs:

- Do **not** force a near-match just to populate selections.
- Keep `selected_paradigms` and `selected_directives` narrow and truthful.
- Encode the missing policy as project-specific charter policy in the interview
  answers and generated charter.
- Say clearly that this is a doctrine gap, not an existing doctrine match.
- Treat it as a candidate for later doctrine extraction rather than solving it by
  misclassifying the project now.

### Output location

- Charter markdown: `.kittify/charter/charter.md`
- Interview answers: `.kittify/charter/interview/answers.yaml`
- Reference manifest: `.kittify/charter/references.yaml`
- Local reference docs: `.kittify/charter/library/*.md`

## Execution Paths

### Path A: LLM-led interview (default)

Use this for normal `/spec-kitty.charter` runs.

1. Inspect the repo quickly before asking questions. Prefer high-signal files:
   - `README.md`
   - `AGENTS.md`
   - `CLAUDE.md`
   - `pyproject.toml`, `package.json`, `go.mod`, `Cargo.toml`
   - existing `.kittify/charter/*` artifacts if present
   - If `.claudeignore` exists, respect it during repo inspection and do not
     spend time reading ignored paths unless the user explicitly asks.
   - If `.claudeignore` does not exist, treat the following as low-signal Spec
     Kitty bootstrap artifacts by default and do not over-interpret them as
     project intent:
     - `.kittify/config.yaml`
     - `.kittify/metadata.yaml`
     - `.kittify/skills-manifest.json`
     - `.kittify/missions/`
     - `.kittify/templates/`
     - `.kittify/scripts/`