Config Refactor

# config-refactor

> Applies fixes from `audit-report.md` against the repo configuration. Reads
> `docs/config-guidelines.md` and `audit-report.md` as its spec; never invents rules.

**Triggers**: /config-refactor, apply config fixes, refactor claude config, fix config issues

---

## Process

### Step 0 — Detect execution context

Apply the same detection logic as `config-audit` Step 0 (per Principle 13):

- **Global mode** — CWD is the `claude-config` repo. Fixes apply to repo files only.
- **Project mode** — CWD is another project with a `CLAUDE.md`. Fixes apply to the
  project's own files only. The global layer is read-only — `config-refactor` MUST
  NEVER edit `~/.claude/` or the source repo from project mode.
- **No-config mode** — no `CLAUDE.md` in CWD. Stop and print:
  `No CLAUDE.md found. Nothing to refactor.`

Record the mode and proceed.

### Step 1 — Verify inputs

Required files in the repo root:

- `docs/config-guidelines.md`
- `audit-report.md`

If either is missing → stop. Tell the user to run `/config-audit` first.

If `audit-report.md` is older than 24h or older than the last commit touching `CLAUDE.md`,
`output-styles/`, `skills/`, or `hooks/` → WARNING to the user and ask whether to proceed or
re-run `/config-audit`. STOP and wait for the answer.

### Step 2 — Load and group findings

Parse `audit-report.md`. Group findings by the file they target. Within each file group,
sort by severity (CRITICAL first) then by line number descending (so edits do not shift
later line numbers).

### Step 3 — Present the plan

Show the user a plan grouped by file, in this format:

```
File: <path>
  [CRIT-3] <title>           → <action verb> (e.g. "delete lines 145–308", "rename heading", "move to agents/")
  [WARN-7] <title>           → <action verb>
  ...
File: <path>
  ...
```

End the plan with a one-line summary:

```
Applying <N> fixes across <M> files. CRITICAL: a, WARNING: b, SUGGESTION: c.
Confirm to proceed? (y / n / pick)
```

`y` → apply everything.
`n` → abort, leave repo untouched.
`pick` → user selects specific finding IDs to apply (e.g. "CRIT-1, WARN-3, WARN-5").

STOP and wait for the user's choice.

### Step 4 — Apply fixes

For each confirmed finding, derive the edit from the `fix_hint` plus the principle cited.
Standard fix actions and how to execute them:

| Fix hint pattern | Action |
|------------------|--------|
| "Move scoped section to `agents/`" | Cut the section from `CLAUDE.md`; create `agents/<name>.md` with that content plus a YAML header `--- name: <name> ---`; replace the cut location in `CLAUDE.md` with a one-line reference: "Orchestrator rules live in `agents/<name>.md` — loaded on demand." |
| "Remove manual skill catalog" | Delete the catalog table. Add no replacement. |
| "OS-specific tooling assumed without declaration" | Either prefix the line with the OS marker the user confirms, or delete the line. ASK before choosing. |
| "Engram protocol duplicated…" | Delete the protocol block from `CLAUDE.md`. Replace with a one-line reference: "Engram protocol is injected by the `SessionStart` hook. Repo-specific topic-key conventions follow." Keep only the topic-key list. |
| "Rule duplicated (Principle 3.2)" between `CLAUDE.md` and an output-style | Delete the duplicate from the output-style. The output-style may add a single line: "Behavior rules from `CLAUDE.md` still apply." |
| "Force-read table exceeds 4 entries" | Show the user the current entries and ask which 2–4 to keep. STOP and wait. |
| "Rename to 'Skills — Force-read inline'" | Rename the heading. No other changes. |
| "Force-read entry points to missing file" | Delete the row. |
| Skill format violations | Add the missing frontmatter field or section. If `format` value is missing, default to `procedural` and