spec-kitty-charter

name	spec-kitty.charter
description	Interview and compile a project charter
user-invocable	true

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

spec-kitty charter status --json

3. If needed, inspect available mission blueprints:

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/
     • agent wrapper directories such as .claude/, .codex/, .gemini/, .cursor/, .opencode/
   • If the repo is otherwise sparse, say so plainly. A freshly initialized Spec Kitty workspace with mostly .kittify/ metadata is a greenfield bootstrap case, not a signal-rich codebase.
   • In that greenfield case, stop spending time inspecting Spec Kitty init relics and start the interview. The user's answers are the primary source of governance intent.
   • If charter status or repo inspection reports "not inside a git repository" but the directory is clearly a new project bootstrap, treat that as a greenfield setup condition rather than a reason to delay the interview.
2. Discover the intended charter update in chat:
   • If a charter exists and the user gives a correction, complaint, observed agent failure, desired norm, or new policy, treat that as the primary source. Ask only the minimum follow-up needed to make the guidance precise enough to encode.
   • Preserve existing charter guidance unless the user clearly wants to replace or narrow it.
   • If the user's input names agent behavior that should change, translate it into enforceable review, planning, implementation, terminology, risk, or exception-policy guidance.
   • If the user input is a small course correction, avoid a broad charter interview. Update the relevant fields and regenerate.

spec-kitty charter generate --from-interview --json
spec-kitty charter status --json

5. Treat the generated charter bundle as a real repository change. If .kittify/charter/charter.md or other generated charter artifacts changed, stage and commit them before concluding the command unless the user explicitly asked not to commit.

Commit expectation

• Do not stop at "there is an uncommitted charter change."
• After successful generation, the default behavior is to create the commit via Spec Kitty's safe-commit path.
• Use a concise commit message that makes the governance action explicit:

spec-kitty safe-commit --message "chore: generate project charter" \
  .kittify/charter/interview/answers.yaml \
  .kittify/charter/charter.md \
  .kittify/charter/references.yaml \
  .gitignore

• If generation produced no diff, say so and do not create an empty commit.
• If unrelated dirty changes exist, avoid sweeping them into the charter commit; spec-kitty safe-commit commits only the requested files.

Path B: CLI interview fallback

Use this only when the user explicitly wants the CLI questionnaire itself:

spec-kitty charter interview --profile comprehensive
spec-kitty charter generate --from-interview

Path C: Deterministic defaults bootstrap

Use this only when the user explicitly asks for defaults, speed, CI bootstrap, or “just make me a starter charter”:

spec-kitty charter interview --defaults --profile minimal --json
spec-kitty charter generate --from-interview --json
spec-kitty charter status --json

When you use defaults, say clearly that no real interview happened.

Editing Rules

• The preferred editable source for this command is .kittify/charter/interview/answers.yaml.
• To revise policy inputs, edit answers.yaml (or rerun charter interview) and regenerate.
• Use --force with generate if the charter already exists and must be replaced.
• Keep charter concise; full detail belongs in reference docs listed in references.yaml.

Validation + Status

After generation, verify status:

spec-kitty charter status --json

Do not chain status with four context calls and dump all of it back into the LLM. That burns first-load state and floods the context window with bootstrap payloads intended for later action boundaries.

Charter Context Bootstrap

Do not preload all action contexts here.

The next real workflow action will load its own context automatically.

If you need to inspect one action manually for debugging, query a single action without consuming first-load state:

spec-kitty charter context --action specify --json --no-mark-loaded

Use JSON text as governance context only for the immediate next action. Do not eagerly inject specify, plan, implement, and review all at once.

Interview Output Shape

When you synthesize .kittify/charter/interview/answers.yaml, match the CLI schema:

schema_version: 1.0.0
mission: software-dev
profile: comprehensive
answers:
  project_intent: "..."
  languages_frameworks: "..."
  testing_requirements: "..."
  quality_gates: "..."
  review_policy: "..."
  performance_targets: "..."
  deployment_constraints: "..."
  documentation_policy: "..."
  risk_boundaries: "..."
  amendment_process: "..."
  exception_policy: "..."
selected_paradigms:
  - domain-driven-design
selected_directives:
  - DIRECTIVE_001
available_tools:
  - git

Select paradigms, directives, and tools deliberately from repo evidence plus user answers. Do not silently accept the full catalog unless the user explicitly asks for defaults.