arn-code-batch-planning

name	arn-code-batch-planning
description	This skill should be used when the user says "batch planning", "batch plan", "arness batch planning", "arn-code-batch-planning", "plan multiple features", "plan all features", "plan unblocked features", "plan the backlog", "plan from backlog", "batch spec and plan", "plan next features", "sequential planning", "multi-feature plan", "plan the next batch", "plan these features", "batch plan GitHub issues", "batch plan from Jira", "plan issues in batch", or wants to plan multiple features from the greenfield Feature Tracker, GitHub issues, or Jira issues in a single session. Pre-analyzes all selected features in parallel, then guides sequential spec review with pipelined plan generation. This skill is typically invoked directly or after arn-brainstorming completes and chains to arn-code-batch-implement upon completion. For single-feature planning, arn-planning is the correct entry point.
version	1.0.0

Arness Batch Planning

Plan multiple features in a single session with parallel pre-analysis and pipelined plan generation. Supports features from greenfield Feature Tracker (F-NNN), GitHub issues, Jira issues, or plain descriptions. Pre-analyzes all selected features in parallel using arn-code-batch-analyzer agents to generate draft specs, then guides the user through sequential review. Plans are generated in the background while the user reviews the next spec.

This skill is a sequencer. It MUST NOT duplicate sub-skill logic. All pipeline work is done by the invoked skills and agents (arn-code-batch-analyzer, arn-code-feature-spec, arn-code-feature-planner, arn-code-save-plan). Arness-code-batch-planning handles: source detection, feature selection, parallel pre-analysis orchestration, sequential spec review, pipelined plan generation, plan review, and chaining.

Pipeline position:

Sources:
  arn-spark (greenfield) -> feature-backlog.md ─┐
  GitHub issues ─────────────────────────────────┤
  Jira issues ───────────────────────────────────┤
                                                  v
                                  **arn-code-batch-planning**
                                    |
                                    +-- Step 2.5: scope assessment (score each feature → swift/standard/thorough)
                                    +-- Step 2.6: generate SWIFT/STANDARD plans (auto, no review)
                                    +-- Step 2.7: parallel arn-code-batch-analyzer (thorough only → draft specs)
                                    +-- Step 3: per thorough feature: arn-code-feature-spec (resume from draft)
                                    +-- Step 3.5: per thorough feature: plan review → save-plan
                                    |
                                    v
                                  arn-code-batch-implement

Step 0: Ensure Configuration

Read ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-ensure-config/references/step-0-fast-path.md and follow its instructions. This guarantees a user profile exists and ## Arness is configured with Arness Code fields before proceeding.

After configuration is ensured, extract the following from ## Arness:

• Plans directory — base path where project plans and PLAN_PREVIEW files are stored
• Specs directory — path to the directory containing specification files
• Code patterns — path to the directory containing stored pattern documentation
• Vision directory (if exists) — path to greenfield vision artifacts
• Use cases directory (if exists) — path to UC documents
• Issue tracker — determines remote issue tracker type (github, jira, or none)
• Template path — path to report templates

---

Step 1: Detect Feature Sources

Batch planning supports multiple feature sources. Check them in order — the first match determines the primary source.

1a. Check for Greenfield Feature Tracker

Read the backlog-selection reference: ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-batch-planning/references/backlog-selection.md. Follow its procedure to scan the Feature Tracker and identify unblocked features.

If greenfield backlog exists with 2+ unblocked features: Proceed to Step 2 with greenfield features (input_type: greenfield for each).

If greenfield backlog exists with exactly 1 unblocked feature:

Inform the user: "Only 1 unblocked feature found: F-XXX [Feature Name]. Batch planning is designed for 2+ features."

Ask (using AskUserQuestion):

"How would you like to proceed?"

Options:

1. Plan this feature — Switch to arn-planning with F-XXX
2. Proceed with batch anyway — Use the batch pipeline for this single feature
3. Exit

If Plan this feature: invoke Skill: arn-code:arn-planning with the F-XXX reference. Exit batch-planning. If Proceed with batch anyway: continue to Step 2 with the single feature pre-selected. If Exit: STOP.

If greenfield backlog exists with zero unblocked features:

Inform the user: "No unblocked features found. All pending features have incomplete dependencies." Present the summary counts.

Ask (using AskUserQuestion):

"No features are available for batch planning. What would you like to do?"

Options:

1. Switch to single-feature planning — Run arn-planning to describe a feature or report a bug
2. Exit — I'll wait for dependencies to complete

If Switch: invoke Skill: arn-code:arn-planning. Exit batch-planning. If Exit: STOP.

1b. Check for Remote Issues (Non-Greenfield Fallback)

If no greenfield Feature Tracker exists (no Vision directory field, or no feature-backlog.md) BUT Issue tracker is github or jira:

Ask (using AskUserQuestion):

"No greenfield feature backlog found, but [GitHub/Jira] issues are available. How would you like to select features?"

Options:

1. Browse [GitHub/Jira] issues — Select multiple issues to plan in batch
2. Switch to arn-planning — Plan a single feature instead
3. Exit

If Browse issues:

• For GitHub: gh issue list --state open --limit 20 --json number,title,labels
• For Jira: fetch open issues via MCP
• Present in a table with number, title, and labels
• Let user multi-select which issues to plan (same layered selection as Step 2)
• For each selected issue, set input_type: github_issue or jira_issue
• Proceed to Step 2 with the selected issues

If Switch: invoke Skill: arn-code:arn-planning. Exit. If Exit: STOP.

1c. No Feature Source Available

If no greenfield backlog AND no Issue tracker configured:

Inform the user: "Batch planning requires either a greenfield feature backlog or an issue tracker (GitHub/Jira). Run arn-brainstorming to set up the greenfield pipeline, or configure an issue tracker in ## Arness." Offer: "Or run arn-planning to plan a single feature by description." STOP.

---

Step 2: Feature Selection

Present the unblocked features in a table sorted by phase then priority:

Unblocked features ready for planning:

| # | ID | Feature | Priority | Phase | Deps |
|---|------|---------|----------|-------|------|
| 1 | F-001 | [Name] | Must-have | Foundation | None |
| 2 | F-003 | [Name] | Should-have | Core | F-001 |
| ... | ... | ... | ... | ... | ... |

Also show summary: "[total] features in tracker, [unblocked] unblocked, [in-progress] in progress, [done] done."

Selection flow

If 4 or fewer unblocked features:

Ask (using AskUserQuestion, multiSelect: true):

"Which features would you like to plan for batch implementation? Select all that apply."

Options: list each unblocked feature as F-XXX: [Feature Name]

If more than 4 unblocked features:

Use layered selection to stay within the 4-option AskUserQuestion limit.

First, ask (using AskUserQuestion):

"There are [N] unblocked features. How would you like to select?"

Options:

1. All unblocked features — Plan all [N] features sequentially
2. Let me choose — Pick specific features from the list

If All unblocked features: select all, proceed to Step 2.5.

If Let me choose: present features in groups of 4 using sequential AskUserQuestion calls (multiSelect: true). After each group, ask if the user wants to select from the next group or proceed with current selections. Continue until all groups are offered or the user says proceed.

After feature selection is confirmed, inform the user about the batch workflow:

"Batch planning workflow: After all features are planned, the specs and plans will be committed to a new branch, pushed, and a PR will be opened to merge them into main. This is required before batch implementation — workers need the plans on main to find them. You'll be asked to confirm the PR merge before any implementation begins."

If Git is no: instead inform: "Plans will be saved locally. Note: batch implementation requires git — you can implement features one at a time with /arn-implementing."

---

Step 2.5: Scope Assessment

Score each selected feature to determine its ceremony tier. This is a lightweight assessment using only the feature description and pattern documentation — no codebase reading required. The same scope router used by arn-planning (Step 3C) is applied here per feature.

2.5a. Load Scope Router Context

Read (if not already loaded):

• <code-patterns-dir>/architecture.md
• <code-patterns-dir>/code-patterns.md
• ${CLAUDE_PLUGIN_ROOT}/skills/arn-planning/references/scope-router-criteria.md

2.5b. Score Each Feature

For each selected feature, apply the scope router criteria from the reference:

1. Rate each of the 6 criteria (file count, domain sensitivity, architectural change, cross-module impact, reversibility risk, test infrastructure) based on the feature's description and the loaded pattern documentation.
2. Multiply each rating (0/1/2) by the criterion's weight.
3. Sum the weighted scores (0-20).
4. Apply override rules (high-weight high-score → minimum standard; multi-high → minimum thorough).
5. Map to tier: 0-4 → swift, 5-12 → standard, 13-20 → thorough.
6. Apply edge case rules (borderline 4-5 defaults to standard, borderline 12-13 defaults to thorough).

2.5c. Present Assessment

Show the results table:

Scope Assessment: [N] features scored

| # | ID | Feature | Score | Tier | Key Factor |
|---|------|---------|-------|------|-----------|
| 1 | F-001 | [Name] | [N] | swift | [one-sentence rationale] |
| 2 | F-003 | [Name] | [N] | standard | [one-sentence rationale] |
| 3 | F-005 | [Name] | [N] | thorough | [one-sentence rationale] |

Do NOT present individual criterion scores (per scope-router-criteria.md: "This assessment is internal — do not present the scoring table to the user"). Present only the recommended tier and a one-sentence rationale.

Show pipeline summary:

Pipeline routing:
  [N] swift     — workers plan + execute autonomously (no interactive review)
  [M] standard  — workers plan + execute autonomously (no interactive review)
  [K] thorough  — interactive spec review below, then workers execute

2.5d. Tier Override Gate

Ask (using AskUserQuestion):

"Tier assignments look right?"

Options:

1. Looks good — Proceed with these tiers
2. Adjust tiers — Let me override individual assignments

If Looks good: proceed to Step 2.6.

If Adjust tiers: for each feature the user wants to change, ask which tier to assign (swift, standard, or thorough). No warning is needed for downgrades — the recommendation is advisory per scope-router-criteria.md rule 4. After adjustments, re-display the final table and proceed.

---

Step 2.6: Generate Swift/Standard Plans

For features assigned to swift or standard tiers, generate plan artifacts immediately. These features skip the interactive spec review — batch-implement workers will read these plans and handle execution autonomously.

Read the plan templates:

• ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-swift/references/swift-plan-template.md (for swift features)
• ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-standard/references/standard-plan-template.md (for standard features)

For each swift feature:

1. Derive project name: SWIFT_<kebab-case-name> (from feature name)
2. Create directory: mkdir -p <plans-dir>/SWIFT_<name>/
3. Generate SWIFT_<name>.md following the swift plan template, populated from:
   • Feature description (from source: greenfield feature file, GitHub issue body, Jira description, or plain text)
   • Pattern documentation (architecture.md, code-patterns.md, testing-patterns.md)
   • Scope assessment notes (files likely affected, patterns that apply, identified risks)
4. Write the plan file

For each standard feature:

1. Derive project name: STANDARD_<kebab-case-name> (from feature name)
2. Create directory: mkdir -p <plans-dir>/STANDARD_<name>/
3. Generate STANDARD_<name>.md following the standard plan template, populated from:
   • Feature description (same sources as above)
   • Pattern documentation (all loaded pattern docs)
   • Scope assessment notes
   • Spec-Lite section: derive problem statement, key requirements (3-7), and architectural notes from the feature description and architecture.md
   • Implementation Tasks section (always present for standard tier)
4. Write the plan file

If greenfield source: Update the Feature Tracker status to in-progress for each swift/standard feature.

Show each generated plan to the user with a brief summary:

Swift/Standard Plans Generated: [N] features

1. SWIFT_<name>.md — [1-2 sentence summary of scope, files, approach]
2. STANDARD_<name>.md — [1-2 sentence summary of scope, key requirements, files]
...

For each plan, show: the tier, problem statement (or scope summary), files to modify, and key patterns that will be followed. This gives the user a quick sanity check without full interactive exploration.

Ask (using AskUserQuestion):

"Review these plans before proceeding?"

Options:

1. Looks good — Proceed with all plans as generated
2. Review one — Let me look at a specific plan in detail
3. Adjust tiers — Some of these need a different tier (returns to Step 2.5d)

If Looks good: proceed to Step 2.7.

If Review one: present the plans as options (max 4, layered if more). When user selects a plan, show its full content. Ask:

"What would you like to do with this plan?"

Options:

1. Approve — Plan is fine as-is
2. Edit — Let me adjust the plan content
3. Upgrade to thorough — This needs full interactive spec review

If Approve: return to the plan selection (for reviewing another) or proceed. If Edit: let the user modify the plan, write updated version. Return to selection. If Upgrade to thorough: move this feature from the swift/standard list to the thorough list. It will go through Step 2.7 pre-analysis and Step 3 interactive review.

If Adjust tiers: return to Step 2.5d (tier override gate) with current assignments.

After all reviews complete, proceed to Step 2.7.

---

Step 2.7: Pre-Analysis (Parallel) — Thorough Features Only

If no features were assigned to the thorough tier, skip this step entirely and proceed to Step 3.

Pre-generate draft specs for thorough features only using arn-code-batch-analyzer agents. Swift and standard features already have plan artifacts from Step 2.6 and do not need pre-analysis.

Show progress:

Pre-analyzing [K] thorough features in parallel...
(Swift and standard features already have plans — skipping pre-analysis for those.)

For each thorough feature, spawn a arn-code-batch-analyzer agent via the Task tool, passing the model from .arness/agent-models/code.md as the model parameter (see plugins/arn-code/skills/arn-code-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:

• run_in_background: true
• The feature's input type and source-specific context:
  • Greenfield: feature ID, feature file path, vision dir, use cases dir
  • GitHub issue: issue reference
  • Jira issue: issue key
• Code patterns path
• Specs directory and derived spec name
• Template reference: ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-feature-spec/references/feature-spec-template.md
• Greenfield loading reference: ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-feature-spec/references/greenfield-loading.md

ALL agents MUST be spawned in a SINGLE message for true parallelism.

Wait for all agents to complete. As each completes, report:

Pre-analysis complete: F-XXX [Name] (draft spec written)

If any agent fails: Retry that specific feature's batch-analyzer (up to 2 retries). If it still fails after 3 total attempts, pause and inform the user:

"Pre-analysis failed for F-XXX [Name] after 3 attempts: [error details]"

Ask (using AskUserQuestion):

"How would you like to handle this?"

Options:

1. Retry again — Give it one more attempt
2. Skip this feature — Remove it from the batch
3. Abort pre-analysis — Stop and troubleshoot

Never silently fall back to a degraded flow. The user must always know what happened and explicitly choose how to proceed.

After all agents complete, show summary:

[K] draft specs ready for thorough features. Starting interactive review.

Proceed to Step 3.

---

Step 3: Sequential Spec Review Loop — Thorough Features Only

If no features were assigned to the thorough tier, skip this step and proceed to Step 3.5.

Show the plan:

Batch Planning: [N] features selected
Order: F-XXX -> F-YYY -> F-ZZZ -> ...

For each selected feature, sequentially:

3a. Show Progress

Reviewing feature [current/total]: F-XXX [Feature Name]
─────────────────────────────────────────────────────

3b. Update Feature Tracker

If the source is greenfield: update the Feature Tracker status to in-progress for this feature. Re-write feature-backlog.md with the updated tracker.

Revert on failure: If this feature is later skipped (via error handling) or the batch is aborted, revert the feature's status from in-progress back to pending before proceeding.

3c. Invoke Feature Spec

Invoke Skill: arn-code:arn-code-feature-spec with the feature context.

Feature-spec will detect the pre-built DRAFT_FEATURE_*.md file (written by the batch-analyzer in Step 2.7) and offer: "Resume or start fresh?" The user picks "Resume" and exploration starts immediately with the pre-built analysis — no agent wait.

Sketch context for batch workflows (conditional): If the batch-analyzer reported UI involvement for this feature (check the draft's Architectural Assessment or UI Design sections for non-empty content), prepend this context to the feature description before invoking feature-spec:

"This feature is being planned for batch implementation. Completing the sketch during planning is strongly recommended — batch workers cannot interact with users to iterate on sketches during implementation. Sketch completion ensures workers can promote validated components autonomously."

If the batch-analyzer did not detect UI involvement, omit this context entirely — it would be confusing for non-UI features. Feature-spec will present the sketch offer with this additional context when it detects UI involvement. The user's decision within feature-spec is final.

3d. Background Plan Generation (Pipelined)

After feature-spec completes and the finalized spec file exists (FEATURE_*.md):

1. Read the finalized spec file
2. Derive the spec name from the filename
3. Spawn the arn-code-feature-planner agent via the Task tool, passing the model from .arness/agent-models/code.md as the model parameter (see plugins/arn-code/skills/arn-code-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:
   • run_in_background: true
   • The full spec file content (FEATURE_.md or BUGFIX_.md)
   • The spec file path (for the Spec: linkage line in the plan)
   • code-patterns.md content
   • testing-patterns.md content
   • architecture.md content
   • ui-patterns.md content (if exists)
   • security-patterns.md content (if exists)
   • Output path: <plans-dir>/PLAN_PREVIEW_<spec-name>.md

Immediately proceed to Step 3a for the NEXT feature. The plan generates in the background while the user reviews the next spec.

3e. Progress Report

Print:

Feature F-XXX [Name] spec finalized. Plan generating in background. [remaining] remaining.

Error Handling (Spec Phase)

If feature-spec fails (error or unexpected exit):

Ask (using AskUserQuestion):

"Feature spec for F-XXX encountered an error. How would you like to proceed?"

Options:

1. Retry — Run feature-spec again for this feature
2. Skip — Skip this feature and continue with the next
3. Abort — Stop batch planning

If the user says "stop" mid-loop:

Show what has been completed so far (completed specs and any plans already generated). Inform the user: "Batch planning paused. [M] of [N] features spec'd. Plans are generating in background for completed specs. Run /arn-code-batch-implement when ready — it will pick up completed plans."

---

Step 3.5: Plan Review Phase — Thorough Features Only

If no features were assigned to the thorough tier, skip this step and proceed to Step 4.

After all thorough specs are reviewed, collect and review all generated plans for thorough features. Swift and standard plans were already written in Step 2.6 and do not need user review.

Wait for any still-running background planners to complete. Show progress:

Waiting for plan generation to complete: [N] plans ready, [M] still generating...

For each feature (in order):

3.5a. Check Plan Status

• If PLAN_PREVIEW exists: present a summary of the plan (phases, deliverables, key decisions).

• If planner failed: retry once in the foreground. If it fails again, inform the user with the error and ask:

  Ask (using AskUserQuestion):

  "Plan generation failed for F-XXX. How would you like to proceed?"

  Options:

  1. Retry — Run the planner again
  2. Skip this feature — Remove it from the batch
  3. Abort — Stop batch planning

3.5b. Plan Approval

Before presenting the plan to the user, parse each phase's **Complexity:** and **Complexity rationale:** fields (added by arn-code-feature-planner per its Complexity Assessment section). When presenting the plan summary, always show the complexity rating per phase (e.g., Phase 3: Dispatch Site Edits — 7 deliverables — complexity: complex).

Ask (using AskUserQuestion):

"Does this plan for F-XXX look right?"

Options:

1. Approve — Save this plan and continue
2. Adjust — Let me refine the plan
3. Skip this feature — Remove from the batch

If Approve: run the Complex Phase Upgrade Gate below (Step 3.5c) before invoking save-plan. After the gate completes, invoke Skill: arn-code:arn-code-save-plan. Proceed to the next feature's plan.

If Adjust: let the user provide feedback. Spawn the arn-code-feature-planner agent via the Task tool (foreground), passing the model from .arness/agent-models/code.md as the model parameter (see plugins/arn-code/skills/arn-code-ensure-config/references/ensure-config.md "Dispatch convention" for fallback), with revision instructions and the current plan path. Re-present with the same 3 options. Repeat until approved or skipped.

If Skip: remove this feature from the batch. Revert Feature Tracker status to pending if applicable. Continue with the next feature's plan.

3.5c. Complex Phase Upgrade Gate (with within-session auto-apply)

Before invoking save-plan for an approved plan, check whether to upgrade complex phases to Opus executor. This gate uses session-scoped memory for the batch run: the user's answer applies to subsequent batch entries without re-prompting.

Session memory model — at batch start, initialize complexUpgradeSessionAnswer = null. As batch entries are processed, update this variable based on user answers. The session variable is independent of the persistent preference (which is updated only via the remember-this follow-up).

Filter: Build the list of phases in the current plan with **Complexity:** complex. If empty, skip this step entirely and proceed to save-plan.

Check session memory first: If complexUpgradeSessionAnswer is set (from an earlier batch entry):

• If yes: silently mark all complex phases in this plan for modelOverride: "opus" (no prompt). Display brief status: Preference: complex phase upgrade applied to remaining batch entries (session auto-apply). Proceed to save-plan.
• If no: silently skip the upgrade for this plan (no prompt). Proceed to save-plan.

If session memory is null, do profile detection and the standard preference lookup:

Profile detection: Read the project's CLAUDE.md ## Arness block for Code agent model profile:. Branch:

• If all-opus: silently skip this gate. Display status: Preference: complex phase upgrade silenced — profile is all-opus (no upgrade needed). Set complexUpgradeSessionAnswer = no (so subsequent entries also silently skip — they'll have the same profile). Proceed to save-plan.
• If balanced or custom: continue.
• If field missing or unknown: treat as unknown and continue.

Two-tier preference lookup for pipeline.complex-phase-upgrade per ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-ensure-config/references/preferences-schema.md:

1. Read .arness/workflow.local.yaml — if file exists and key present, use that value.
2. Else read ~/.arness/workflow-preferences.yaml — if file exists and key present, use that value.
3. Else treat as null (first encounter).

Branch on the resolved value:

• always: auto-mark every complex phase in this plan for modelOverride: "opus". Set complexUpgradeSessionAnswer = yes so subsequent entries auto-apply. Display status. Proceed to save-plan.
• never: skip this gate. Set complexUpgradeSessionAnswer = no. Proceed to save-plan.
• ask: show the gate below. Do NOT show the remember-this follow-up.
• null (first encounter): show the gate below. After the user answers, show the remember-this follow-up.

Gate (shown when value is ask, null, or invalid):

Ask (using AskUserQuestion):

"N phases in F-XXX are rated complex (rationale: ...). Upgrade ALL of them to Opus for execution? Reviewer dispatches stay on configured tier. This answer will apply to subsequent batch entries in this session."

Options:

1. Yes, upgrade complex phases (Recommended for known-complex work) — applies to this plan AND silently to subsequent batch entries
2. No, keep configured tier — no override; applies to this plan AND silently to subsequent batch entries

If Yes: mark every complex phase in this plan for modelOverride: "opus". Set complexUpgradeSessionAnswer = yes. If No: no override applied. Set complexUpgradeSessionAnswer = no.

Follow-up (only when preference was null — first encounter): After the gate, ask:

Ask (using AskUserQuestion):

"Should Arness remember this choice for future sessions?"

Options:

1. Yes, always upgrade complex phases (saves always to preferences — applies to this batch and all future sessions)
2. Yes, never upgrade complex phases (saves never to preferences — applies to this batch and all future sessions)
3. No, ask me each time (saves ask — within this batch the session-scoped answer above still controls subsequent entries; future batch sessions will fire the gate again on the first complex plan)

Write the chosen value to ~/.arness/workflow-preferences.yaml under pipeline.complex-phase-upgrade per the standard write protocol in preferences-schema.md.

After the gate completes, proceed to save-plan invocation.

---

Step 4: Summary

Present a summary table after all features are processed:

Batch Planning Complete: [completed]/[total] features ready

| Feature | Tier | Source | Sketch | Plan Path |
|---------|------|--------|--------|-----------|
| F-001: [Name] | swift | auto-planned | N/A | .arness/plans/SWIFT_[name]/ |
| F-003: [Name] | standard | auto-planned | N/A | .arness/plans/STANDARD_[name]/ |
| F-005: [Name] | thorough | interactive | Done | .arness/plans/[project]/ |

Source column:

• auto-planned — plan generated by batch-planning (Step 2.6), worker handles execution
• interactive — spec reviewed interactively, plan saved via save-plan

Sketch detection (thorough features): Check if arness-sketches/<feature>/ exists with a status file indicating kept → Done. Otherwise → N/A. Swift and standard features always show N/A for sketch.

If any features were skipped, list them separately: "Skipped: F-XXX (spec error), F-YYY (user skipped)"

---

Step 5: Ship Plans

Before launching batch-implement, all planning artifacts must be on main so workers can find them.

Read ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-batch-planning/references/plan-shipping.md and follow its procedure. This handles:

• Creating a plans branch (if on main)
• Staging and committing all plan artifacts
• Pushing and creating a PR (platform-dependent)
• Waiting for the user to confirm the PR is merged
• Checking out main and pulling

If Git is no: skip shipping. Inform the user that plans are local only and batch-implement requires git. Offer to exit or implement features one at a time via /arn-implementing.

---

Step 6: Handoff

After plans are on main (PR merged and pulled):

Ask (using AskUserQuestion):

"Plans are on main. Launch batch implementation?"

Options:

1. Launch batch implementation — Invoke Skill: arn-code:arn-code-batch-implement
2. Not yet ��� Exit

If Launch batch implementation: invoke Skill: arn-code:arn-code-batch-implement.

If Not yet: "Run /arn-code-batch-implement when ready. All plans are saved on main."