chief

Run chief-agent in full autopilot. Requires goals and contracts to exist. Chief creates TODO, delegates to builder, and repeats until milestone is done. Auto mode makes all decisions autonomously; safe mode stops on ambiguity. Use "/chief-autopilot" for auto or "/chief-autopilot safe" for safe mode.

Deep grill that interviews the user one question at a time AND verifies each answer against the codebase via background `answer-verifier-agent` calls. Catches factual conflicts, contradictions with prior decisions, and unfounded assumptions inline. Persists the session to `.chief/_grill/opened/NNNN-topic.md` so it survives context compaction. Use when the user wants a stress-tested grill — when stakes are high, when claims must be cross-checked against actual repo state, or when the topic spans many decisions. Heavier than `/grill-design`; prefer this when correctness matters more than speed.

Bootstrap `.chief/project.md` for a Chief-installed project by interviewing the user about their tech stack, dev commands, architecture, and key rules. Use after `/chief-install` (or any time the user wants to set up project-wide context). This is the lazy entry point for `.chief/` — it creates only `project.md`; milestones and rules are created later, on demand.

Plan a new milestone or extend an existing one step-by-step with review gates. Starts with a grill-design session to clarify requirements, then walks through goal → contract → todo → task specs, pausing for user approval at each step.

Run a retrospective on the current milestone or latest batch. Checks goal/contract coverage, summarizes planned vs delivered, and proposes rule updates. Use "/chief-retro" after completing a batch or milestone.

Proactively add a rule to `.chief/_rules/`. Counterpart to `/chief-retro` (which proposes rules reactively from observed patterns). Use when the user has a rule in mind and wants to capture it now. Interviews the user (what / why / when / examples), classifies the rule into a category (_standard / _contract / _goal / _verification), shows a draft, and writes after confirmation. One rule per invocation.

Stress-test a design, idea, or approach by interviewing the user one question at a time. Each question comes with a recommended answer AND a one-line self-critique of that recommendation. After each user answer, briefly stress-test the answer against prior decisions before moving on. Use when the user wants a sharp grill on a design or decision tree without persistence overhead. Lighter than `/chief-grill` (which adds codebase verification and a session log).

Co-write a top-down design spec for software projects. Shape vague ideas into clear specs by working layer-by-layer — vision, scope, building blocks, then detail. Use when user wants to design a system, plan a project, write a design spec, or needs to see the big picture before diving into details. Use before /grill-design to prevent losing focus on large projects.

Cut an over-engineered plan down to one achievable increment. Reads the current codebase to understand what exists, then trims scope to the smallest useful step that still scales. Use when user says "slim down", "too much", "over-engineered", "simplify the plan", "what's the MVP", "cut scope".

Quick commit all files with a short 1-line message. Saves tokens by skipping detailed diff analysis. Use when the user wants a fast save (e.g. "/dump-commit" or "/dump-commit fix upgrade flow").

Install the Chief framework into the current project. Installs subagents and AGENTS.md only — `.chief/` is created lazily by chief-agent at runtime. Use when the user wants to set up the framework (e.g. "/chief-install" or "/chief-install canary").

Upgrade the Chief to a specific version. Uses upgrade.sh as the primary method, falls back to manual if script fails. Use when the user wants to upgrade the framework (e.g. "/chief-upgrade" or "/chief-upgrade canary").