Wave 5 Step 15. Threads --raw plumbing through all seven action
command templates and adds a shape test covering structural plumbing
plus help.md's plain-language vocabulary.
- commands/fix.md: --raw flag parsed; fix-plan rendering groups by
userActionLanguage; humanized title/description/recommendation are
rendered verbatim from the cross-referenced scan envelope.
- commands/rollback.md: terminology pass — "manifest" → "list of
changes" in user-facing copy; the file name manifest.yaml is kept
as the machine contract; --raw threaded through.
- commands/plan.md: --raw forwarded to the planner-agent's prompt;
agent now instructed to group actions by userImpactCategory and
lead with userActionLanguage; bash block added for flag parsing.
- commands/implement.md: --raw forwarded to the implementer-agent's
prompt; progress-log lines now reference the humanized titles
already present in the action plan.
- commands/cleanup.md: --raw accepted as no-op (cleanup is
file-management only, no findings prose); bash block added.
- commands/help.md: full plain-language pass — "PreToolUse" and
"frontmatter" jargon removed from user-facing copy; new
vocabulary table surfaces the humanized userImpactCategory and
userActionLanguage labels ("Configuration mistake", "Conflict",
"Wasted tokens", "Missed opportunity", "Dead config" / "Fix this
now", "Fix soon", "Fix when convenient", "Optional cleanup",
"FYI"); --raw documented as global pass-through flag.
- commands/interview.md: --raw accepted as no-op; "unused hooks"
question phrased as "unused automation that runs at specific
events" in user-facing copy.
tests/commands/action-commands-shape.test.mjs (new, +6 tests, 780 → 786):
- structural: bash block + Read tool + --raw/$ARGUMENTS plumbing
across all 7 files
- help.md vocabulary: ≥3 userImpactCategory labels and ≥3
userActionLanguage phrases present
- help.md jargon: no bare "PreToolUse" or "frontmatter" in copy
75 lines
3.1 KiB
Markdown
75 lines
3.1 KiB
Markdown
---
|
|
name: config-audit:interview
|
|
description: Phase 3 - Interactive interview to gather user preferences
|
|
allowed-tools: Read, Write, Edit, AskUserQuestion, Bash
|
|
model: sonnet
|
|
---
|
|
|
|
# Config-Audit: Interview (Phase 3)
|
|
|
|
Gather user preferences to inform the action plan.
|
|
|
|
## IMPORTANT: Inline Execution Only
|
|
|
|
This command runs AskUserQuestion **directly in the main context** — NOT via a Task subagent.
|
|
AskUserQuestion requires synchronous terminal interaction and does not work when delegated to a Task subagent.
|
|
|
|
## Prerequisites
|
|
|
|
- Must have completed Phase 2 (analysis)
|
|
- Use the Read tool on the analysis at `~/.claude/config-audit/sessions/{session-id}/analysis-report.md`
|
|
|
|
## Arguments
|
|
|
|
- `$ARGUMENTS` may contain `--raw` — pass-through accepted for CLI surface consistency. Interview is interactive prose only (no scanner output, no findings prose), so `--raw` is a no-op here.
|
|
|
|
## Implementation Steps
|
|
|
|
0. **Parse flags**:
|
|
|
|
```bash
|
|
RAW_FLAG=""
|
|
if echo "$ARGUMENTS" | grep -q -- "--raw"; then RAW_FLAG="--raw"; fi
|
|
```
|
|
|
|
1. **Load session state**: Verify analysis phase completed, read analysis report for context
|
|
2. **Conduct interview inline**: Use AskUserQuestion tool directly (NOT via Task). Adapt questions based on analysis findings.
|
|
3. **Save interview results**: Write to `~/.claude/config-audit/sessions/{session-id}/interview.md`
|
|
4. **Update state** (see state-management rule)
|
|
5. **Output summary**
|
|
|
|
## Interview Questions
|
|
|
|
Ask these using AskUserQuestion (skip questions that don't apply based on analysis). Where the analysis report references finding IDs, use the humanized title from the report rather than re-deriving prose:
|
|
|
|
1. **Config Style** — Centralized vs Distributed vs Hybrid organization
|
|
2. **Unused automation that runs at specific events** — Wire up, review individually, delete, or leave (only if the analysis report flagged one)
|
|
3. **Duplicate Permissions** — Remove from local, consolidate, or keep (only if found)
|
|
4. **Modular Rules** — Use .claude/rules/ pattern? Yes/No
|
|
5. **Path-Scoped Rules** — Which patterns (tests, src, config, docs) — only if Q4=Yes
|
|
6. **Conflict Resolution** — Per-conflict: global vs project vs custom value (only if conflicts found)
|
|
7. **Permission Audit** — Audit or keep (only if >30 patterns in settings.local.json)
|
|
8. **Project Inheritance** — Per-project: inherit or isolate (only if multiple projects)
|
|
|
|
## Adaptive Questioning
|
|
|
|
Skip questions that don't apply:
|
|
- No unused hooks question if all hooks are wired
|
|
- No duplicates question if no duplicates found
|
|
- No conflict questions if no conflicts detected
|
|
- No path-scoping if user said no to modular rules
|
|
- Fewer project questions if only one project
|
|
- No permission audit if <30 patterns
|
|
|
|
## Skip Interview Option
|
|
|
|
If user runs `/config-audit plan` without interview:
|
|
- Use sensible defaults (centralized, inherit, enable rules)
|
|
- Flag decisions in plan as "assumed"
|
|
|
|
## Error Handling
|
|
|
|
- If user selects "Other" for any question, ask follow-up with AskUserQuestion
|
|
- If interview is cancelled, save partial results
|
|
- If no analysis report found, report error and exit
|
|
- If AskUserQuestion fails, STOP — do not use alternative methods
|