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.

After scaffolding for path 1: tell the user the README path and stop.

3. Interview (one focused question at a time)

Ask each question separately. Wait for the answer before moving on. Keep questions short. Skip a question if the user says "skip" or "n/a" — but do not skip Q1 (what).

1. What is the rule? — A single-sentence statement of the rule.
2. Why does it exist? — The motivation: incident, preference, constraint, decision.
3. When and where does it apply? — Scope: always / specific area / specific milestone / specific file types / etc.
4. Any code or text example? — Optional. A short snippet showing right vs wrong, or a concrete instance.
5. Filename? — Short kebab-case (e.g. commit-style, db-naming, pr-size). No .md suffix needed.

4. Classify into a category

Based on the answers, propose one of the four categories:

• _standard/ — coding standards, naming, formatting, architectural constraints, "how we write code"
• _contract/ — data models, API contracts, schemas, type-level invariants
• _goal/ — high-level goals shared across milestones, product direction
• _verification/ — test commands, build requirements, definition of done, CI gates

Tell the user which category you picked and why (one sentence). Ask them to confirm or override.

5. Draft the file

Write the draft using plain markdown, no frontmatter:

# <The rule statement, as a single declarative sentence>

**Why:** <motivation from Q2>

**How to apply:** <scope from Q3>

## Example

<code or prose example from Q4 — omit this section if user skipped Q4>

Show the rendered draft to the user. Ask once: "Write this to .chief/_rules/<category>/<filename>.md?"

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

6. Collision handling (content-aware)

Before writing, check if .chief/_rules/<category>/<filename>.md already exists.

If it does, read the existing file first, then classify the relationship and propose the right action:

Relationship	Detection signal	Action
Identical	New rule's statement, why, and how-to-apply substantially match existing	Skip. Tell user the rule is already captured. Stop.
Refines / extends	Same concern, new adds detail (e.g. clarifies scope, adds an example, tightens wording)	Merge: produce a unified version that preserves both. Show diff. Backup existing to <filename>.md.bak. Confirm, then write.
Contradicts	New rule reverses or replaces existing	Replace: show old vs new side-by-side. Backup existing to <filename>.md.bak. Confirm, then write.
Different concern, name collision	Existing file's H1 / Why is about a different thing despite same filename	Suggest a more specific filename. Loop back to step 3 question 5 (filename) with the user.

NEVER overwrite without backing up to .bak first. NEVER skip the read-before-write step on collision.

7. Write and report

1. If .chief/_rules/ does not exist yet, run the scaffold routine from step 2 first (creates .chief/, .chief/_rules/, and _rules/README.md).
2. Create the target category subfolder (e.g. .chief/_rules/_standard/) if missing — this is the lazy creation point.
3. Write the rule file.

Then report:

• Path written
• Backup path (if collision triggered a .bak)
• Reminder: chief-agent will pick up this rule on its next read of .chief/_rules/**

Stop. Do not ask "add another?" — one rule per invocation. User re-runs for the next.

Important rules

• This skill creates only rule files (and the .chief/_rules/README.md on first run). Do not scaffold milestones, project.md, or anything else.
• NEVER create empty category subfolders — they are lazy. Only create _standard/, _contract/, _goal/, or _verification/ when the first rule lands there.
• NEVER overwrite an existing rule file without a .bak backup AND user confirmation.
• NEVER read or modify files outside .chief/_rules/ (except the read of AGENTS.md if you need it for context — but you usually do not).
• Keep the interview short. One focused question at a time, no compound questions.
• Use plain markdown. No frontmatter. The repo's existing .chief/_rules/ files are plain markdown — keep the convention.
• If the user picks path 1 (scaffold only), do NOT continue into the interview. Stop after the README is written.