/spec-kitty-charter-doctrine

name: spec-kitty-charter-doctrine
description: >-
  Run charter interview, generation, context, and sync workflows for
  project governance in Spec Kitty 3.x. Access doctrine artifacts
  programmatically via DoctrineService. Resolve agent profiles. Load
  action-scoped governance context iteratively, not all at once.
  Triggers: "interview for charter", "generate charter",
  "sync charter", "use doctrine", "set up governance",
  "charter status", "extract governance config", "load doctrine",
  "agent profile", "DoctrineService", "action index".
  Does NOT handle: generic spec writing not tied to governance, direct runtime
  loop advancement, setup/repair diagnostics, or editorial glossary maintenance.

spec-kitty-charter-doctrine

Manage the charter lifecycle: interview, generate, context-load, sync, and status. Access doctrine artifacts programmatically via `DoctrineService`. Resolve agent profiles for role-scoped behavior. Load governance context iteratively at action boundaries rather than dumping everything upfront.

`.kittify/charter/charter.yaml` is the Spec Kitty runtime governance source for a project — the single git-tracked, structured file nesting `governance`, `directives`, `catalog`, activation, and `overrides`. `.kittify/charter/charter.md` is a curated, human-readable companion the runtime never parses or resolves policy from. A repository may also keep public governance docs outside `.kittify/`; those docs are human-facing authority unless `charter.yaml`'s `governance.charter.offering.governance_references` points at them. The doctrine layer (`src/charter/offering/`) provides the reusable knowledge artifacts (directives, tactics, paradigms, styleguides, toolguides, procedures, agent profiles, step contracts) that the charter references.

---

⛔ ARCHITECTURAL INVARIANT: spec-kitty NEVER calls LLMs

**spec-kitty is a CLI tool invoked BY an LLM harness (Claude Code, Codex, Cursor, Gemini, etc.). The LLM harness IS the inference engine. spec-kitty must NEVER call any LLM API itself.**

This is not a preference. It is a hard architectural rule with no exceptions.

Why this rule exists

| What you are reading this in | What that means | |------------------------------|-----------------| | Claude Code | Claude IS already running. It should generate doctrine. | | Codex CLI | Codex IS already running. It should generate doctrine. | | Cursor / Gemini / Kiro / ... | Same — the harness IS the inference engine. |

If spec-kitty called the Anthropic SDK internally:

• It would need a separate `ANTHROPIC_API_KEY` — a second API key alongside the one

the harness already uses.

• It would bypass the harness entirely, making the agent's reasoning invisible.
• It would make spec-kitty Anthropic-specific, breaking all other harnesses.
• It would be a hidden inference call the user never authorized or configured.
• It would duplicate what the harness can already do better, with full context.

What this means for charter synthesis

**Charter synthesis is an LLM reasoning task. YOU (the agent running this skill) are the LLM that should do it.**

The synthesis workflow is:

answers.yaml   (the interview answers — what the user told spec-kitty about the project)
     +
doctrine schemas  (the YAML shapes expected for directives, tactics, styleguides)
     +
THIS SKILL  (the instructions you are reading right now)
     ↓
YOU generate the doctrine YAML files
     ↓
spec-kitty CLI commands  (validate, stage, and promote the files you wrote)

spec-kitty's CLI provides validation, schema-checking, DRG validation, neutrality gating, staging, and atomic promotion. It does NOT provide generation — that is your job as the agent.

If you see code that calls `anthropic.Anthropic()` or imports the `anthropic` SDK

inside spec-kitty source files, that is a bug. Remove it immediately.

Canonical locations that must NEVER contain `import anthropic` or any Anthropic SDK call:

• `src/charter/` — any file
• `src/specify_cli/` — any file
• `pyproject.toml` — must not list `anthropic` as a runtime dependency

---

How to Synthesize Doctrine Artifacts (Agent-Driven)

When a user says "synthesize charter doctrine", "generate project doctrine", or "run charter synthesize", you do the following — you do NOT call any CLI command that triggers an LLM. You ARE the LLM.

Step 1 — Read the interview answers

cat .kittify/charter/interview/answers.yaml

This file contains the user's responses: project intent, languages, testing requirements, quality gates, etc.

Step 2 — Read the doctrine schemas for the target artifact kinds

The current synthesis scope is: `directive`, `tactic`, `styleguide`.

Read shipped examples to understand the expected YAML shape. There is no `doctrine list` or `doctrine show` CLI command — use the programmatic `DoctrineService` API (documented in the *Programmatic Doctrine Access* section below) or read the YAML files directly from `packs/built-in/<kind>/` (artifacts live at `<type>/<pack>/[<category>/]<name>` — ADR 2026-07-26-2):

from charter.activation.doctrine_service_builder import build_activation_aware_doctrine_service

service = build_activation_aware_doctrine_service(project_root)

# Read a directive
directive = service.directives.get("<a-directive-id>")

# Read a tactic
tactic = service.tactics.get("<a-tactic-id>")

# Read a styleguide
styleguide = service.styleguides.get("<a-styleguide-id>")

To validate your project-layer doctrine artifacts run:

spec-kitty doctrine validate .kittify/

Step 3 — Read the interview mapping to know what to generate

The interview fields map to target artifact kinds:

• `project_intent`, `quality_gates`, `risk_boundaries` → directives
• `testing_requirements` → directives + tactics (TDD flavour)
• `languages_frameworks` → styleguides (language-specific)
• `performance_targets`, `deployment_constraints` → directives

For each synthesis target, derive: `kind`, `slug` (kebab-case,