chief-rule

You are helping the user capture a single rule into .chief/_rules/. This is the proactive counterpart to /chief-retro — use it whenever the user has a rule in mind and wants to write it down now.

One invocation = one rule (path 2) or scaffolding only (path 1). Re-run for more.

Steps

1. Pre-flight

Just inspect — do NOT create anything yet. Note for later use:

• whether .chief/ exists
• whether .chief/_rules/ exists
• whether .chief/_rules/README.md exists

Scaffolding (creating .chief/, .chief/_rules/, the README) happens at the END of the chosen path, not now. If the user bails out, we leave the filesystem untouched.

2. Pre-interview fork

Ask the user, with exactly two options:

Pick one:

1. Scaffold .chief/_rules/ only (I'll write rules manually later, or use /chief-retro after work)
2. Interview me — write a rule now

If 1 → run the scaffold routine below, then stop. If 2 → continue to step 3. (Scaffolding happens later, in step 7, alongside the rule write.)

Scaffold routine (used by path 1, and by path 7 when _rules/ is missing)

1. Create .chief/ if missing.

2. Create .chief/_rules/ if missing.

3. Write .chief/_rules/README.md if missing, with this content:

   # .chief/_rules/
   
   Global rules that govern this project's autonomous AI work. Lower priority than `AGENTS.md`, higher than milestone goals.
   
   ## Categories
   
   - `_standard/` — Coding standards, architecture constraints
   - `_contract/` — Data models, API contracts, schemas
   - `_goal/` — High-level goals (shared across milestones)
   - `_verification/` — Test commands, build requirements, definition of done
   
   Subfolders are created **lazily** — on first rule in that category. Empty subfolders are not required.
   
   Use `/chief-rule` to add rules proactively, or `/chief-retro` to capture them after a milestone retrospective.
   

4. Do NOT create the four category subfolders. They remain lazy until the first rule lands in each.