5-phase-workflow 2.0.6 → 3.0.0-beta-2

package/src/commands/5/plan.md

@@ -1,169 +1,189 @@
 ---
 name: 5:plan
-description: Plans a feature end-to-end, combines requirements and technical discovery, and writes a unified plan.md. Single review gate before /5:implement.
-allowed-tools: Bash, Read, Write, Agent, AskUserQuestion, mcp__claude_ai_Atlassian_Rovo__getJiraIssue
+description: Plans a feature and persists the approved plan as .5/features/{name}/plan.md. Uses native plan mode when available, otherwise an equivalent prose loop. Implements compact plans inline; hands larger ones to /5:implement. Re-run with an existing feature name to refine that plan.
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, AskUserQuestion, EnterPlanMode, TaskCreate, TaskUpdate, mcp__claude_ai_Atlassian_Rovo__getJiraIssue
 user-invocable: true
-argument-hint: [ticket-id-or-description]
+argument-hint: [feature-name-or-ticket-id-or-description]
 ---
 
 <role>
-You are a Workflow Planner. Your only deliverable is `.5/features/{name}/plan.md`.
-You do NOT implement code. You spawn only Explore agents. You write only `.5/.planning-active`, `.5/features/{name}/codebase-scan.md`, and `.5/features/{name}/plan.md`.
-After creating the plan, output the completion message and stop.
+You are a Workflow Planner. Your deliverables are `.5/features/{name}/plan.md` and `.5/features/{name}/codebase-scan.md`.
+Exploration, questions, and the approval gate belong to plan mode — you write no code until the user approves the plan.
+After approval you implement only **compact** plans, inline in this session. Anything larger goes to `/5:implement`.
 </role>
 
-<constraints>
-HARD CONSTRAINTS:
-- Do NOT write code or pseudo-code.
-- Do NOT create source files.
-- Do NOT create a separate feature.md.
-- Do NOT produce step, skill, model, pattern-file, or verify-command tables in plan.md; the step-orchestrator derives those mechanically during `/5:implement`.
-- Do NOT use Bash to create, write, or modify files.
-- Do NOT call EnterPlanMode.
-- Do NOT spawn implementation agents.
-</constraints>
-
 # Plan
 
 ## Options
 
-- `--github` - Auto-fetch feature description from the GitHub issue linked to the current branch.
-- `--jira` - Auto-fetch feature description from the Jira ticket linked to the current branch.
+- `--github` - Auto-fetch the feature description from the GitHub issue linked to the current branch.
+- `--jira` - Auto-fetch the feature description from the Jira ticket linked to the current branch.
 
 Current branch: !`git branch --show-current`
 
-## Progress Checklist
+## Step 1: Resolve Feature and Description
 
-Follow these steps in order and output `✓ Step N complete` after each completed step.
+Run these before entering plan mode.
 
-- [ ] Step 0: Activate planning guard by writing `.5/.planning-active`
-- [ ] Step 1: Auto-fetch ticket if `--github` or `--jira` was passed
-- [ ] Step 2: Gather or confirm feature description
-- [ ] Step 3: Explore the codebase and cache findings in `codebase-scan.md`
-- [ ] Step 4: Discuss requirements, scope, acceptance criteria, and decisions
-- [ ] Step 5: Write unified `plan.md`
-- [ ] Step 6: Self-check `plan.md`, output completion, and stop
+**Refine mode.** If the argument names an existing `.5/features/{name}/plan.md` — directly, or via a ticket prefix matched with Glob on `.5/features/{prefix}*/plan.md` — read that plan and its `codebase-scan.md`. You are refining an existing plan; skip ticket fetching and go to Step 2. If a ticket prefix matches several features, ask which one.
 
-## Step 0: Activate Planning Guard
+**New plan.** Otherwise:
 
-Write `.5/.planning-active`:
+1. Only when `--github` or `--jira` was passed, resolve the ticket:
+   - Read `.5/config.json` if it exists and extract `ticket.pattern`.
+   - Match the pattern against the branch name above.
+   - Validate the ID before fetching: `--github` requires digits only (`^[0-9]+$`), `--jira` requires key format (`^[A-Z][A-Z0-9]+-[0-9]+$`).
+   - `--jira`: fetch via `mcp__claude_ai_Atlassian_Rovo__getJiraIssue` using the validated key as a typed parameter.
+   - `--github`: run `gh issue view "$id" --json title,body`.
+   - If no ticket ID is found, ask the user for it, validate, then fetch. If validation or fetching fails, report the reason and continue without fetched content.
+   - Show fetched content to the user and ask whether any context is missing.
+2. Otherwise, ask the user for the feature description.
+3. Determine a short kebab-case feature folder name. With a known ticket ID, use `{ticket-id}-{feature-name}`. Sanitize to alphanumeric, dash, and underscore only.
 
-```json
-{
-  "phase": "plan",
-  "startedAt": "{ISO-timestamp}"
-}
-```
+## Step 2: Plan in Plan Mode
 
-## Step 1: Auto-fetch Ticket
+Call `EnterPlanMode`. Plan mode owns codebase exploration, clarifying questions, the plan file, and the approval gate — do not run a parallel discovery pass of your own.
 
-Only run this step when `--github` or `--jira` was passed.
+If `.5/index/` exists, read `.claude/skills/use-index/SKILL.md` and follow it to select index files instead of scanning the project broadly. Check the `Generated:` timestamp in `.5/index/README.md` first; if the index is more than a day old, run `.5/index/rebuild-index.sh`.
 
-1. Read `.5/config.json` if it exists and extract `ticket.pattern`.
-2. Match the pattern against the branch name above.
-3. If a ticket ID is found, validate format first:
-   - `--github`: digits only (`^[0-9]+$`)
-   - `--jira`: key format (`^[A-Z][A-Z0-9]+-[0-9]+$`)
-4. After validation:
-   - `--jira`: fetch via `mcp__claude_ai_Atlassian_Rovo__getJiraIssue` using the validated key as a typed parameter.
-   - `--github`: run `gh issue view "$id" --json title,body`.
-5. If no ticket ID is found, ask the user for the ID, validate it, then fetch.
-6. If validation or fetching fails, report the reason and continue without fetched content.
+Carry these three constraints into the planning work:
 
-## Step 2: Gather Description
+**Output shape.** Write the plan using the section shape of `.claude/templates/workflow/PLAN.md`. Use `.claude/templates/workflow/PLAN-COMPACT.md` instead for small, low-risk changes with 1-2 components, no data migration, no security/auth change, and no public API contract change. The plan must end with a Component Checklist table of `Component | Action | Target Path | Intent`, where action is `create`, `modify`, `delete`, or `rename`. For `rename`, the target path is the destination and the intent names the original path. Do not add step, model, skill, pattern-file, or verify-command columns — `/5:implement` derives that wiring mechanically.
 
-If fetched content exists, show it and ask whether any context is missing.
-Otherwise ask the user for the feature description.
+**Necessity gate.** Apply this to every component before it enters the plan. Ask "does this need to exist?" and prefer the simplest approach that meets the acceptance criteria: reuse the standard library, a native platform/framework feature, or an already-installed dependency before adding anything new. Push speculative or "might need later" work to `[DEFERRED]`. Do not plan abstractions, flexibility, or configurability that no acceptance criterion requires.
 
-Do not ask technical follow-ups yet.
+**No code.** Requirements and implementation intent only — no code or pseudo-code in the plan.
 
-## Step 3: Explore Codebase
+In refine mode, seed the planning work with the existing plan's content and change only what the discussion actually changes.
 
-If `.5/index/` exists, check the `Generated:` timestamp in `.5/index/README.md`. If the index is more than one day old, run `.5/index/rebuild-index.sh` to refresh it before spawning the Explore agent.
+## Step 3: Persist the Approved Plan
 
-Spawn one Explore agent. In Codex, use `agent_type: explorer`, `model: gpt-5.4-mini`, and `reasoning_effort: low`.
+Once the user approves the plan, write:
 
-```text
-Analyze the codebase for a unified workflow plan.
+1. `.5/features/{name}/plan.md` — the approved plan. In refine mode, overwrite the existing file and append to a `## Discussion History` section:
 
-Feature description:
-{feature description}
+```markdown
+## Discussion History
 
-Tasks:
-1. If `.5/index/` exists, read `.claude/skills/use-index/SKILL.md` and follow its guidance to select and read relevant index files. Skip broad project scanning. If the index is missing, fall back to targeted Grep/Glob and note it in the report.
-2. Identify relevant modules, existing patterns, and likely target files.
-3. Find at most 3 similar implementations and reusable helpers.
-4. Identify test framework, test file conventions, and the narrowest relevant build/test commands.
-5. Identify constraints, risks, and places where the user needs to decide.
+### {ISO-date} - {topic}
 
-Report:
-- Relevant existing patterns: path + one-line reason
-- Similar implementations: max 3 paths + one-line reason
-- Likely target paths
-- Test/build setup: commands only, with scope
-- Risks or unknowns
+**Changes made:**
+- {added / clarified / removed}
 
-READ-ONLY. Use only Read, Glob, and Grep.
-Keep the report under 40 lines. Do not include generic project structure, dependency lists, or long file summaries unless directly needed for this feature.
+**Rationale:** {why}
 ```
 
-Write the compact result to `.5/features/{name}/codebase-scan.md`. If the Explore result is longer than 40 lines, summarize it before writing.
+2. `.5/features/{name}/codebase-scan.md` — the exploration findings `/5:implement` needs, under 40 lines:
 
-## Step 4: Collaborative Plan Development
+```markdown
+# Codebase Scan
 
-Discuss naturally until you can articulate:
+## Relevant Existing Patterns
+- `{path}` - {one-line reason}
 
-- The problem and expected outcome
-- Scope in and out
-- Acceptance criteria
-- Key decisions labeled `[DECIDED]`, `[FLEXIBLE]`, or `[DEFERRED]`
-- Existing patterns to follow
-- A clean component checklist with target paths
+## Similar Implementations
+- `{path}` - {one-line reason}
 
-Ask only useful questions. Prefer proposing a concrete understanding and letting the user correct it.
+## Likely Target Paths
+- `{path}`
 
-Apply a necessity gate to every component before it enters the plan. For each one, ask "does this need to exist?" and prefer the simplest approach that meets the acceptance criteria: reuse the standard library, a native platform/framework feature, or an already-installed dependency before adding anything new. Push speculative or "might need later" work to `[DEFERRED]`. Do not plan abstractions, flexibility, or configurability that no acceptance criterion requires.
+## Test/Build Setup
+- {command} - {scope}
 
-## Step 5: Write `plan.md`
+## Risks or Unknowns
+- {risk}
+```
 
-Determine a short kebab-case feature folder name. If a ticket ID is known, use `{ticket-id}-{feature-name}`. Sanitize folder names to alphanumeric, dash, and underscore only.
+In refine mode, update this file only where exploration produced new findings.
 
-Choose the plan template:
+## Step 4: Self-check
 
-- Use `.claude/templates/workflow/PLAN-COMPACT.md` for small, low-risk changes with 1-2 components, no data migration, no security/auth change, and no public API contract change.
-- Use `.claude/templates/workflow/PLAN.md` for everything else.
+Verify:
 
-Write `.5/features/{name}/plan.md` using the selected template.
+- The plan has all required template sections, and optional sections with no useful content were omitted.
+- Acceptance criteria are checkboxes.
+- Decisions are labeled `[DECIDED]`, `[FLEXIBLE]`, or `[DEFERRED]`.
+- Every component traces to scope or acceptance criteria, and none adds abstraction, flexibility, or configurability beyond what an acceptance criterion requires.
+- No implementation code or pseudo-code is present.
 
-The component checklist is intentionally lean:
+## Step 5: Hand Off
 
-- Component name
-- Action (`create`, `modify`, `delete`, `rename`)
-- Target path
-- One-sentence intent
+Approving a plan means the user wants it built. Branch on the plan format you chose in Step 2 — the point is to spend a fresh delegated run only where it pays for itself.
 
-For `rename`, use the target path as the destination and describe the original path in the intent.
+**Compact plan** (`planFormat: compact`, 1-2 low-risk components): implement it here, in this session. The context is already warm, and spinning up orchestration to edit one or two files costs more than it saves. In refine mode, only do this when the refined plan has not been implemented yet — check `.5/features/{name}/state.json`.
 
-Do not include columns for step, model, skill, pattern file, verify command, complexity, or dependencies. That mechanical wiring is generated by `step-orchestrator-agent` from `plan.md` and `codebase-scan.md`.
+1. Say what you are about to do, then implement the Component Checklist directly. Make the smallest coherent change per component and follow the patterns named in the plan.
+2. Run the verify commands from `.5/config.json`. Skip any set to `none`.
+3. Write `.5/features/{name}/state.json`:
 
-## Step 6: Self-check and Stop
+```json
+{
+  "feature": "{name}",
+  "status": "completed|failed",
+  "completedComponents": ["component-name"],
+  "verification": {"status": "passed|partial|failed", "summary": "one line"},
+  "startedAt": "{ISO-timestamp}",
+  "lastUpdated": "{ISO-timestamp}"
+}
+```
 
-Verify:
+Component names must match the plan's Component Checklist verbatim, so a later `/5:implement` can resume against them. This file is also how `/5:review` finds the feature.
 
-- The plan has all required template sections.
-- Optional sections with no useful content were omitted.
-- Acceptance criteria are checkboxes.
-- Decisions are labeled `[DECIDED]`, `[FLEXIBLE]`, or `[DEFERRED]`.
-- Every component traces to scope or acceptance criteria.
-- No component adds abstraction, flexibility, or configurability beyond what an acceptance criterion requires.
-- No implementation code or pseudo-code is present.
+4. If `.5/config.json` `git.autoCommit` is `true`, make one commit for the change using `git.commitMessage.pattern`, staging only the files you touched. Never `git add .` or `git add -A`.
+5. Report what changed, the verification result, and:
+
+```text
+✓ Plan at `.5/features/{name}/plan.md` — implemented inline (compact plan)
+
+Run `/5:review` when you are ready.
+```
+
+If verification fails, leave `status: "failed"` and tell the user they can fix the issue and rerun `/5:implement {name}` to resume.
 
-Output exactly:
+**Full plan:** do not implement. A multi-component plan is worth a fresh run — `/5:implement` executes independent components in parallel waves, routes mechanical work to cheaper models, and gives each executor a narrow context instead of this whole conversation. Output exactly:
 
 ```text
 ✓ Plan created at `.5/features/{name}/plan.md`
 
-Review the plan, then run `/5:implement {name}`.
+Review the plan, then run `/5:implement {name}` in a fresh context.
 ```
 
-Stop immediately.
+Then stop immediately.
+
+## Fallback path
+
+On Codex, or in any runtime without `EnterPlanMode`, replace Step 2 with this loop. Steps 1, 3, 4, and 5 are unchanged — including the compact-plan inline implementation, which matters more here because Codex has no Workflow tool to parallelize a delegated run.
+
+1. Spawn one Explore agent:
+
+```text
+Analyze the codebase for a unified workflow plan.
+
+Feature description:
+{feature description}
+
+Tasks:
+1. If `.5/index/` exists, read the `use-index` skill and follow its guidance to select and read relevant index files. Skip broad project scanning. If the index is missing, fall back to targeted Grep/Glob and note it in the report.
+2. Identify relevant modules, existing patterns, and likely target files.
+3. Find at most 3 similar implementations and reusable helpers.
+4. Identify test framework, test file conventions, and the narrowest relevant build/test commands.
+5. Identify constraints, risks, and places where the user needs to decide.
+
+Report:
+- Relevant existing patterns: path + one-line reason
+- Similar implementations: max 3 paths + one-line reason
+- Likely target paths
+- Test/build setup: commands only, with scope
+- Risks or unknowns
+
+READ-ONLY. Use only Read, Glob, and Grep.
+Keep the report under 40 lines. Do not include generic project structure, dependency lists, or long file summaries unless directly needed for this feature.
+```
+
+2. Discuss with the user until you can articulate the problem and expected outcome, scope in and out, acceptance criteria, key decisions labeled `[DECIDED]` / `[FLEXIBLE]` / `[DEFERRED]`, existing patterns to follow, and a component checklist with target paths. Ask only useful questions — prefer proposing a concrete understanding and letting the user correct it.
+
+3. Apply the same output shape, necessity gate, and no-code constraints from Step 2.
+
+4. Show the plan to the user and get explicit approval before writing it.
+
+Until the user approves the plan you are a planner, not an implementer: write nothing outside `.5/features/{name}/`, write no source code, and spawn no implementation agents. Claude Code enforces this through plan mode; here it is on you. After approval, Step 5 applies as written.

package/src/commands/5/reconfigure.md

@@ -7,7 +7,7 @@ user-invocable: true
 
 <role>
 You are a Project Reconfigurer. You refresh documentation and skills using existing config.json preferences.
-You do NOT modify user preferences (ticket patterns, review tools, branch conventions, etc.).
+You do NOT modify user preferences (ticket patterns, branch conventions, commit patterns, etc.).
 You detect codebase changes, confirm with the user, invoke the configuration refresh skills, then report.
 After reporting what was updated, you are DONE.
 </role>
@@ -23,7 +23,7 @@ Single-command refresh that skips the full Q&A of `/5:configure`. Re-detects cod
 | Scenario | Command |
 |----------|---------|
 | First-time setup | `/5:configure` |
-| Change preferences (ticket pattern, review tool, etc.) | `/5:configure` |
+| Change preferences (ticket pattern, commit pattern, etc.) | `/5:configure` |
 | Codebase evolved, refresh docs/skills | **`/5:reconfigure`** |
 | Add new skill patterns | `/5:configure` |
 
@@ -42,7 +42,7 @@ Your job:
 ✅ Report what was updated
 
 Your job is NOT:
-❌ Ask preference questions (ticket pattern, branch convention, review tool, etc.)
+❌ Ask preference questions (ticket pattern, branch convention, commit pattern, etc.)
 ❌ Modify config.json preferences (only the `skills` section may be updated if user confirms new patterns)
 ❌ Skip confirmation — always show what will be regenerated
 

package/src/commands/5/review.md

@@ -1,7 +1,8 @@
 ---
 name: 5:review
-description: Reviews code changes using native agent review or CodeRabbit CLI. Categorizes findings and saves them for /5:address-review-findings.
-allowed-tools: Bash, Read, Glob, Grep, AskUserQuestion, Agent, mcp__jetbrains__*
+description: Reviews code changes via the built-in code-review skill. Categorizes findings and saves them for /5:address-review-findings.
+allowed-tools: Bash, Read, Glob, Grep, AskUserQuestion, Agent, Skill, mcp__jetbrains__*
+argument-hint: [low|medium|high|max]
 user-invocable: true
 model: sonnet
 ---
@@ -13,17 +14,7 @@ You do NOT apply fixes. Fix application is handled by /5:address-review-findings
 
 # Review
 
-CodeRabbit: !`which coderabbit 2>/dev/null && coderabbit auth status 2>/dev/null || echo "not installed"`
-
-## Step 1: Determine Review Tool
-
-Read `.5/config.json` and use `reviewTool`.
-
-- Missing, `native`, or legacy `claude`: use native review.
-- `coderabbit`: use CodeRabbit if installed/authenticated; otherwise ask whether to switch to native review or stop for setup.
-- `none`: report that automated review is disabled and stop.
-
-## Step 2: Determine Scope
+## Step 1: Determine Scope
 
 Ask what to review:
 
@@ -32,27 +23,31 @@ Ask what to review:
 3. All changes (`git diff HEAD`)
 4. Current branch vs main/master (`git diff main...HEAD`)
 
-## Step 3: Spawn Review Agent
+## Step 2: Run the Review
+
+Effort level: default `high`. If the user passed an argument matching `low`, `medium`, `high`, or `max`, use that instead.
+`ultra` is not accepted here — it is user-triggered and billed and cannot be launched from a command. If the user passes it, say so and use `max`.
 
-Spawn one review agent. The main context handles user interaction only.
+Never pass `--fix` or `--comment`. This command only records findings; applying fixes and posting PR comments is `/5:address-review-findings`.
 
-For native review:
+**Primary path** — if the built-in `code-review` skill is available, invoke it:
 
 ```text
-You are a code reviewer. Review the selected diff blind, purely on its merits.
+Skill(skill: "code-review", args: "{target} {effort}")
+```
+
+Derive `{target}` from the scope answer: options 1-3 review the current working-tree diff (no target argument needed); option 4 passes the branch. Use the findings it reports.
 
-Scope: {scope}
-Base branch: {base branch if relevant}
+**Fallback path** — on Codex, or when the `code-review` skill is unavailable, spawn one review agent instead:
 
-Process:
-1. Get the diff for the selected scope.
-2. Triage the diff by file and classify each changed file as high, medium, or low risk.
-3. Read full files only for high-risk changes, public API boundaries, security/auth, data migrations, and files where the diff alone is insufficient.
-4. For medium-risk files, read targeted symbols or nearby changed sections plus direct imports only when needed.
-5. For low-risk mechanical/docs/config changes, review the diff without reading full files unless something looks inconsistent.
-6. Review for bugs, security, performance, code quality, API design, and missing tests.
-7. Review for over-engineering: unnecessary abstractions, single-use indirection, unused flexibility or configurability, speculative generality, and reinventing standard-library or existing-dependency behavior. Report clear cases as Fixable and judgment calls as Questions.
-8. Categorize findings as Fixable, Questions, or Manual.
+```text
+Review the diff for {scope} blind, on its merits.
+Triage files by risk; read full files only for high-risk changes, public API boundaries,
+security/auth, and data migrations. For everything else, review the diff alone.
+Report bugs, security, performance, code quality, API design, missing tests, and
+over-engineering (unnecessary abstractions, single-use indirection, speculative
+generality, reinventing stdlib or existing dependencies).
+Do not apply fixes. Keep findings concise; no raw diff excerpts.
 
 Output:
 Status: success | failed
@@ -64,22 +59,33 @@ Questions:
 - file: {path}, line: {N}, question: {what}
 Manual Review:
 - file: {path}, line: {N}, description: {what}, severity: {level}
-
-Do not apply fixes.
-Keep findings concise and do not include raw diff excerpts unless needed to identify the issue.
 ```
 
-For CodeRabbit, run the CLI for the selected scope, then categorize the output into the same format.
-
-## Step 4: Save Findings
+## Step 3: Save Findings
 
 Determine feature name from the most recent `.5/features/*/state.json`, or ask the user.
 
 Write `.5/features/{feature-name}/review-findings-{YYYYMMDD-HHmmss}.md` using `.claude/templates/workflow/REVIEW-FINDINGS.md`.
 
+When the findings come from the `code-review` skill, map its reported fields onto the template:
+
+| Reported finding | Template field |
+|---|---|
+| `verdict: CONFIRMED` with a localized, single-file fix | **Category:** `Fixable` |
+| `verdict: PLAUSIBLE` | **Category:** `Question` |
+| `verdict: CONFIRMED` but spanning files or needing a design decision | **Category:** `Manual` |
+| `category: correctness` | **Severity:** `error` (`warning` when `PLAUSIBLE`) |
+| `category: simplification` / `efficiency` / `test-coverage` | **Severity:** `suggestion` |
+| `file`, `line` | **File:**, **Line:** |
+| `summary` | **Description:** |
+| the concrete fix, else `short_summary` | **Suggested Fix:** |
+| `failure_scenario` | **Original Reviewer Message:** |
+
+Findings from the fallback path map directly: Fixable Issues, Questions, and Manual Review become their matching categories.
+
 Do not ask the user to edit action markers in the findings file. The findings file is the review record; `/5:address-review-findings` will present each finding interactively and record decisions separately.
 
-## Completion
+## Step 4: Report and Hand Off
 
 Output:
 
@@ -91,6 +97,16 @@ Review complete.
 - Manual review needed: {N}
 
 Findings saved at `.5/features/{feature-name}/review-findings-{timestamp}.md`
-
-Run `/5:address-review-findings {feature-name}` to decide on each finding interactively, then apply approved fixes.
 ```
+
+If there are no findings, stop here.
+
+Otherwise ask the user directly whether to continue:
+
+- "Address these findings now?"
+  - Options:
+    1. "Yes, run `/5:address-review-findings {feature-name}`" — decide on each finding interactively, then apply approved fixes
+    2. "No, stop here" — findings stay on disk for later
+
+- If the user chooses yes: invoke `/5:address-review-findings {feature-name}`.
+- If the user chooses no: tell them to run `/5:address-review-findings {feature-name}` when they are ready, and stop.

package/src/commands/5/split.md

@@ -13,55 +13,15 @@ You do NOT implement code. You do NOT modify source files. You write only child
 
 # Split Plan
 
-Use this command when an existing plan is too large and should become multiple independently implementable plans.
+## Step 1: Locate the Parent Plan
 
-## Goals
+Resolve `{feature-name}` to `.5/features/{feature-name}/plan.md`. Given only a ticket ID or prefix, glob `.5/features/{prefix}*/plan.md`. Given nothing, use the most recently modified `.5/features/*/plan.md`, asking the user to choose between several plausible recent ones. If no parent plan exists, stop and tell the user to run `/5:plan` first.
 
-- Help the user decide how to split the parent plan.
-- Suggest good split points based on implementation independence.
-- Create child feature folders, each with its own `plan.md` and `codebase-scan.md`.
-- Preserve traceability to the original parent plan and sibling split plans.
+Read the parent `plan.md` and its `codebase-scan.md` if it exists. Do not read source files unless those two are insufficient to identify safe split boundaries; if they are, use targeted Glob/Grep or one read-only Explore agent.
 
-## Process
+## Step 2: Agree on the Split
 
-### Step 1: Locate Parent Plan
-
-1. If `{feature-name}` was provided, use `.5/features/{feature-name}/plan.md`.
-2. If only a ticket ID or prefix was provided, glob `.5/features/{prefix}*/plan.md`.
-3. If no feature was provided:
-   - Find `.5/features/*/plan.md`.
-   - Prefer the most recently modified plan.
-   - If there are multiple plausible recent plans, ask the user to choose.
-4. If no parent plan exists, stop and tell the user to run `/5:plan` first.
-
-Read:
-
-- Parent `.5/features/{feature}/plan.md`
-- Parent `.5/features/{feature}/codebase-scan.md` if it exists
-- `.5/config.json` only if needed for ticket naming conventions
-
-Do not read source files unless the parent plan and scan are insufficient to identify safe split boundaries. If extra context is needed, use targeted Glob/Grep or one Explore agent with a read-only prompt.
-
-### Step 2: Analyze Split Boundaries
-
-Extract from the parent plan:
-
-- Overview and desired outcome
-- Scope in/out
-- Acceptance criteria
-- Decisions
-- Existing patterns
-- Module impact
-- Component checklist
-- Technical notes and constraints
-
-Suggest 2-5 split options optimized for independently running `/5:implement`:
-
-- Prefer components that touch different target files or modules.
-- Keep each child plan with coherent acceptance criteria.
-- Keep dependency order explicit when one child must land before another.
-- Avoid technical-layer splits when they would create child plans that cannot be verified independently.
-- Avoid splitting tightly coupled same-file changes unless the user explicitly wants it.
+Propose 2-5 boundaries optimized for running `/5:implement` on each child independently: prefer components touching different files or modules, keep each child's acceptance criteria coherent and independently verifiable, and make dependency order explicit when one child must land first. Avoid technical-layer splits that produce children nobody can verify alone, and avoid splitting tightly coupled same-file changes unless the user asks for it.
 
 Present the recommendation compactly:
 
@@ -73,44 +33,15 @@ Recommended split:
 Dependency order: {none | child A before child B because ...}
 ```
 
-Then ask the user:
-
-- How many child plans should be created?
-- Which suggested boundaries should be used or changed?
-
-Use AskUserQuestion for concrete choices. If the user provides textual boundaries, summarize them back before writing.
-
-### Step 3: Confirm Each Child Plan
-
-For each child plan, ask or confirm:
-
-- Child title
-- Child folder slug
-- Scope in
-- Scope out
-- Acceptance criteria
-- Component checklist rows copied or adapted from the parent
-- Dependencies on sibling child plans
-
-Folder naming:
-
-- Use `{parent-feature}-{nn}-{child-slug}`.
-- `nn` is 2-digit, starting at `01`.
-- Sanitize slugs to lowercase kebab-case using only alphanumeric characters, dash, and underscore.
-- If the folder already exists, ask whether to choose a new slug or stop. Do not overwrite existing child folders without explicit user approval.
+Agree with the user on the boundaries, each child's scope and folder slug, and which components go where. Show the final split summary and get confirmation before writing anything.
 
-Before writing files, show the final split summary and ask for confirmation.
+Folder naming: `{parent-feature}-{nn}-{child-slug}`, with `nn` a 2-digit index starting at `01` and the slug sanitized to lowercase kebab-case (alphanumeric, dash, underscore). If a folder already exists, ask whether to choose a new slug or stop — never overwrite an existing child folder without explicit approval.
 
-### Step 4: Write Child Artifacts
+## Step 3: Write Child Artifacts
 
-For each confirmed child folder, create:
+For each confirmed child, write `.5/features/{child-feature}/plan.md` using `.claude/templates/workflow/PLAN.md`, or `PLAN-COMPACT.md` when the child clearly has only 1-2 low-risk components. Copy only the parent context relevant to that child. Keep decisions labeled `[DECIDED]` / `[FLEXIBLE]` / `[DEFERRED]`, acceptance criteria as independently verifiable checkboxes, and the component checklist lean (component, action, target path, intent — no step/model/pattern/verify columns, no code).
 
-- `.5/features/{child-feature}/plan.md`
-- `.5/features/{child-feature}/codebase-scan.md`
-
-Use `.claude/templates/workflow/PLAN.md` structure for every child plan unless the child clearly has only 1-2 low-risk components; in that case, use `.claude/templates/workflow/PLAN-COMPACT.md`.
-
-Each child `plan.md` must include a `## Split Metadata` section after the overview:
+Each child plan carries this section after its overview:
 
 ```markdown
 ## Split Metadata
@@ -123,27 +54,9 @@ Each child `plan.md` must include a `## Split Metadata` section after the overvi
 - Dependency order: {none | sibling names and reason}
 ```
 
-Child plan content rules:
-
-- Copy only parent context relevant to that child.
-- Keep decisions labeled `[DECIDED]`, `[FLEXIBLE]`, or `[DEFERRED]`.
-- Acceptance criteria must be checkboxes and independently verifiable.
-- Component checklist remains lean: component, action, target path, intent.
-- Do not add step/model/pattern/verify columns.
-- Do not include implementation code or pseudo-code.
-
-Child `codebase-scan.md` rules:
-
-- If the parent scan exists, copy only relevant patterns, likely target paths, test/build setup, risks, and unknowns for the child.
-- If no parent scan exists, write:
-
-```markdown
-# Codebase Scan
-
-No parent codebase scan was available when this plan was split.
-```
+Also write `.5/features/{child-feature}/codebase-scan.md` with the parent scan's patterns, target paths, test/build setup, risks, and unknowns that apply to that child. If there is no parent scan, write `# Codebase Scan` followed by `No parent codebase scan was available when this plan was split.`
 
-### Step 5: Write Split Manifest
+## Step 4: Write the Split Manifest
 
 Write `.5/features/{parent-feature}/split-manifest-{YYYYMMDD-HHmmss}.json`:
 
@@ -166,25 +79,8 @@ Write `.5/features/{parent-feature}/split-manifest-{YYYYMMDD-HHmmss}.json`:
 }
 ```
 
-Keep the parent `plan.md` unchanged.
-
-### Step 6: Report
-
-Output:
-
-```text
-Plan split complete.
-
-Parent: .5/features/{parent-feature}/plan.md
-Manifest: .5/features/{parent-feature}/split-manifest-{timestamp}.json
+Leave the parent `plan.md` unchanged.
 
-Child plans:
-- .5/features/{child-1}/plan.md
-- .5/features/{child-2}/plan.md
-
-Implement separately with:
-/5:implement {child-1}
-/5:implement {child-2}
-```
+## Step 5: Report
 
-Stop immediately.
+Output the parent path, the manifest path, each child plan path, and the `/5:implement {child}` command for each. Then stop.