chief-init

name	chief-init
description	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.

You are bootstrapping the project's .chief/project.md. This is the only thing this skill creates. Milestones, rules, and other .chief/ content are created later by chief-agent on first need.

Steps

1. Pre-flight checks

1. Verify the framework is installed: .agents/agents/chief-agent.md must exist. If missing, tell the user to run /chief-install first and stop.
2. Check if .chief/project.md already exists.
   • If yes → ask the user: ".chief/project.md already exists. Update it / overwrite / cancel?"
   • If overwrite, back up the current file to .chief/project.md.bak before proceeding.
   • If update, read the current content first and treat the interview as a refinement pass.
   • If cancel, stop.
3. Create .chief/ if it does not exist.

2. Interview the user

Walk through these topics, one short question at a time. Keep questions focused. Wait for the answer before moving on. Skip a topic if the user says "skip" or "n/a".

• Project name and one-line summary.
• Tech stack — primary languages, frameworks, runtimes, databases, key libraries.
• Dev commands — how to install deps, run dev, run tests, lint, typecheck, build.
• Architecture overview — main patterns (e.g. Repository Pattern, Service Layer, hexagonal, monorepo, etc.).
• Directory structure — top-level folders and what they hold.
• Important development rules — conventions developers must follow (commit style, branch policy, formatting, testing requirements, etc.).

If the user is unsure about a topic, suggest reasonable defaults derived from files you can see in the repo (package.json, pyproject.toml, Cargo.toml, Makefile, README.md, etc.) and confirm.

3. Show a draft and confirm

Print the proposed .chief/project.md content as formatted markdown. Then ask once: "Write this to .chief/project.md?"

If the user requests changes, apply them and re-confirm. Do not loop more than three rounds — if alignment is hard, write the current draft and tell the user they can edit manually.

4. Write the file

Write to .chief/project.md. Use this structure (omit empty sections rather than leaving placeholder prose):

# Project Configuration

## Project
{name and one-line summary}

## Development Commands
{commands as a list or table}

## Architecture Overview

### Tech Stack
{...}

### Key Architectural Patterns
{...}

### Directory Structure
{...}

### Important Development Rules
{...}

5. Next steps

Tell the user:

• .chief/project.md is now set. chief-agent will read it for project context.
• To start a milestone: /chief-plan (creates .chief/milestone-N/ lazily).
• To run autonomously once a milestone is planned: /chief-autopilot.
• Rules can be added later under .chief/_rules/_standard/, _contract/, _goal/, _verification/ — chief-agent creates the appropriate subfolder on first rule.

Important rules

• This skill creates only .chief/ (if missing) and .chief/project.md. Do not scaffold milestones, rule subfolders, or _template/.
• Never overwrite an existing project.md without explicit user confirmation; always back up to .bak first.
• If .agents/agents/chief-agent.md is missing, do not proceed — direct the user to /chief-install.
• Keep the interview short. One focused question at a time, no compound questions.
• Reference: a canonical layout example lives at docs/example-chief/ in the chief repo.