Development Planning (/ar:planprocess)

The user's request is the task description for everything below.

Harness-specific plan lifecycle

Claude Code: Use EnterPlanMode and ExitPlanMode where this skill instructs; ExitPlanMode is the approval boundary.
Pi: Do not call EnterPlanMode or ExitPlanMode on Pi because Pi exposes neither tool. Write or refine the durable plan note directly, report its exact path for approval, and after approval start execution with /ar pp <path>.
Native task tracking is conditional: Before following any task-operation instruction below, use only a mutation tool that the current session actually exposes. Claude uses TaskCreate/TaskUpdate; Pi and Prime use those tools only when the autorun extension registered them; Codex uses the flat update_plan checklist only when exposed (update_plan is unavailable in Codex Plan mode). If no native task mutation tool is available, keep progress in the durable Markdown checklist, do not call or retry an unavailable task tool, and report that native task state was not updated. Every unqualified TaskCreate, TaskUpdate, dependency, and TaskList instruction below is conditional on those capabilities.
Other harnesses: Use a native plan-mode boundary and native task tracking only when those tools actually exist; otherwise use the same durable-note approval and checklist workflow as Pi with that harness's documented autorun command spelling.

</purpose>

CRITICAL RULES — SURVIVE COMPACTION

If this session was compacted, these rules STILL apply without exception:

On Claude Code, call ExitPlanMode when ALL planning tasks are complete — this is Claude Code’s approval boundary. On Pi, report the durable plan note path and wait for explicit user approval.
When TaskCreate is exposed, ALL plan steps require TaskCreate. If another native checklist mutation tool is exposed, track every step with that tool instead. Otherwise, use the durable Markdown checklist as required by the capability rule above.
ALL user instructions must be directly quoted as a numbered list at the top of the plan file. Every distinct message, with sub-items for context if needed.
NEVER delete content from plan files. Only add or make micro-edits. Read before editing. Verify after.
After plan acceptance: Create [TDD] and [EXEC] tasks for every implementation step before writing any code (the scaffold is plannew's §10).
Keep tasks updated: Before starting any step, TaskUpdate(status="in_progress"). When done, TaskUpdate(status="completed").

1. Foundation (Read First)

1.1 Key Principles

Acronym	Meaning	Question to Ask
TDD	Test-Driven Development	Tests written first? Location specified?
DRY	Don't Repeat Yourself	No code duplication? Reusing utilities?
OODA	Observe-Orient-Decide-Act	Cycle followed before each decision?
KISS	Keep It Simple	Simplest solution that works?
YAGNI	You Aren't Gonna Need It	No premature optimization?
SOLID	Single responsibility, Open/closed, Liskov, Interface segregation, Dependency inversion	Each principle addressed?
RAII	Resource Acquisition Is Initialization	Resources properly managed?
WOLOG	Without Loss Of Generality	Solution generalizes appropriately?

1.2 Definition of Concrete

All outputs should include where applicable:

File paths: /path/to/file.ts or ./relative/path.ts
Line references: file.ts:42-56
Function/class names: handleRequest() in handler.ts:15-28
Error messages: "socket hang up (ECONNRESET)"
Testable commands: npm test -- --grep "auth"
Sources and references: External sources (web URIs, external file URIs, web searches, documentation, research papers) must be recorded with full URIs and cited in plan output

1.3 Quality Standards

Sequential improvement: Each iteration builds on previous insights
Superb quality: All solutions meet highest standards with thorough justification
Direct quotes: Show WHY assessments are made, not just WHAT
Verifiable outcomes: Reasoning transparent and reproducible
Compelling cases: Selections demonstrate clear superiority

2. Setup

2.1 Plan Mode Check

Claude Code only: If not already in plan mode, use EnterPlanMode now. Pi: remain in the current mode and write the durable plan note directly.

2.2 Planning Task Setup — STOP: MUST DO BEFORE ANY PLANNING

STOP. Before writing one word of plan content, complete ALL steps below. Do not skip. Do not defer.

Step A — Establish the planning boundary: On Claude Code, call EnterPlanMode if needed. On Pi, do not call a plan-mode tool; use the durable plan note.

Step B — Record ALL user instructions as a numbered list at the top of the plan file. Every distinct message must appear with sub-items for context if necessary:

## User Messages (exact quotes, in order)

1. "first message the user sent"
   - Context: what prompted this; what was happening at the time
2. "second message — a correction or clarification"
   - Context: what changed from the previous message

Include EVERY distinct user message that shaped this plan. Do not summarize or merge messages.

Step C — Create [PLANNING] tasks for EVERY step AND substep via TaskCreate:

TaskCreate(subject="[PLANNING] Step N: [name]", activeForm="Planning [name]...")
TaskCreate(subject="[PLANNING] Step N.M: [substep]", activeForm="Planning [substep]...")
TaskCreate(subject="[PLANNING] Req: [distinct-requirement]") for each requirement
Wire dependencies: TaskUpdate(taskId=N, addBlockedBy=[N-1]) for sequential steps

Step D — Verify: Call TaskList and confirm ALL [PLANNING] tasks visible before continuing.

Step E — Track Progress:

Start each task: TaskUpdate(taskId, status="in_progress")
Finish each task: TaskUpdate(taskId, status="completed")

3. MODE: PLANNING (Not Execution)

Execute rigorous methodology step by step. Do NOT execute code changes until plan approved.

Self-Check Questions (answer YES to all before proceeding):

Is the code clean, robust, and concise?
Has the full plan file been brought up to date with latest insights?
Does the plan integrate beautifully with existing code and patterns?
Have you consolidated to match best approach per §1.1 Principles with concrete outputs per §1.2?
Is it superbly designed for architect, maintainer, AND user audiences?
Are different backends handled transparently, seamlessly, and robustly for future API changes?

</requirements>

4. Process Steps

PERSISTENT RULE: After EVERY step AND substep of your plan (both during creation and execution), you must output the exact string "Wait," then execute §5 Wait Process "out loud" step by step and substep by substep.

Step 1: Identify Expertise Areas

List expertise areas needed. Act as expert. Output in plan: State expertise explicitly.

Step 2: Generate Best Practices

For each expertise area separately, write:

10 general best practices
10 task-specific best practices

Output in plan under "## Best Practices" as numbered list.

Step 3: Explore Context

Understand existing work. Determine right integration point. Avoid duplication.

Step 4: Launch Explore Subagents

Use Task tool to launch parallel Explore subagents (up to 3) to understand:

Existing implementations and patterns
Related components and dependencies
Testing patterns and conventions

CRITICAL - Verify Subagent Findings:

Use Read tool to verify EVERY file reference
Confirm code snippets match actual content
Do NOT trust unverified claims
CITE file:line-range for verified findings
Mark unverifiable findings as "[UNVERIFIED]"

Step 5: Launch Plan Subagent

Use Task tool with Plan subagent to design implementation from exploration results.

Step 6: Describe Logic Flow

Trace logic flow through the description. Show data/control flow.

Step 7: Use Actual Quotes

Quote actual code with file:line-range references. No paraphrasing.

Step 8: Critique Work

Critique overall + line-by-line against ALL best practices (§1.1) and quality standards (§1.3).

Step 9: Propose Multiple Solutions

Propose ≥3 distinct solutions to each issue. Choose best with compelling justification.

Step 10: Thread Management

Each thread of updates (different approaches/solutions being refined) needs a unique name with incrementing version number (<taskname>-v1, <taskname>-v2, ...). This enables referencing specific iterations: "In auth-solution-v2 we tried X, but auth-solution-v3 uses Y".

Step 11: Final Verification - Completeness Check

Verify ALL cases from the user's request:
1. Primary use case implemented
2. ALL edge cases from requirements included
3. ALL languages/platforms mentioned covered
4. ALL file types/formats specified handled
5. ALL user examples addressed
6. No requirements silently dropped
Check your work. Do not hallucinate.
Verify all file references with Read tool
Confirm code examples are syntactically correct
Ensure no steps skipped (check TaskList)
If ANY case missing: Return to relevant step. Do NOT proceed incomplete.

Step 12: Plan Output

Create concrete step-by-step plan with checkbox items. Add all to TaskList via TaskCreate.

5. Wait Process (Sequential Improvement Methodology)

After outputting "Wait," execute these 8 steps:

Elaborate Best Practices: Elaborate and refine best practices lists (create new lists if none exist yet) as numbered list for current context; keep refining as new circumstances develop
Comprehensive Critique: Harshly and constructively critique overall + line-by-line against every single best practice and criteria
Pre-mortem Analysis: Identify potential failure modes, edge cases, weaknesses. Assume disaster → determine what went wrong → prevent those outcomes
Multiple Solution Generation: Propose ≥3 superb quality concrete solutions (high-level + specific code quotes) to each identified issue in your task, critiques, and pre-mortem analysis
Synthesized Solution Building: Synthesize insights from all cumulative context including all previous critiques, the original work (if applicable), all previous proposed solutions, and all accumulated best practices to create refined solutions that incorporate lessons learned from the complete analysis
Sequential Quality Enhancement: Each proposal must be superb quality, building on benefits of previous iterations
Best Solution Selection: Choose the optimal solution from all proposals including the original, synthesized, or combinations of all proposals, in ranked order with compelling justification
Error Correction Protocol: On error: immediately TaskCreate(fix) → TaskUpdate ALL steps from error point onward (failed_step and all subsequent steps) back to "pending" or "in_progress" status → Update dependencies (addBlockedBy) for reset steps to reflect corrected sequence → execute corrective steps → return to the step that produced the error and redo from there

6. Checkbox Management

Create plan with checkboxes → Put all in TaskList via TaskCreate
Execute each checkbox → Execute Wait Process after completion
Check off only when: Execution complete AND error correction complete
On errors: Continue until resolved, then check off

</workflow>

<output_contract>

7. Output Format

Plan Structure

Summary: 2-3 sentences (goal + approach)
Checklist: Concrete items with file:line-range references
Dependencies: What must be done first?
Risks: What could go wrong?
Verification: How to test each step?

Code Block Format

// File: /path/to/file.ext
// Line: XX-YY (where this code goes)
// Purpose: Brief description

[actual code here - not pseudocode]

Requirement: Every implementation step needs ≥1 code block showing exact change.

</output_contract>

8. Subagent Guidelines

Subagent Type	When to Use
Explore	Codebase exploration, finding patterns, understanding implementations
Plan	Designing approaches, alternatives, architectural decisions
code-architect	Complex architectural planning (Claude Code `feature-dev` plugin, when installed)
code-explorer	Deep analysis of existing features (same plugin)
code-reviewer	Code quality, bugs, security review (Claude Code `pr-review-toolkit` plugin, when installed)
pr-test-analyzer	Test coverage analysis (same plugin)

Parallel execution: Launch multiple in single message when tasks are independent.

</delegation>

<acceptance_protocol>

9. Plan Acceptance and Execution Protocol

When the plan is ready for approval, use the harness-specific boundary above: Claude Code calls ExitPlanMode; Pi reports the durable note path and waits for explicit approval before /ar pp <path>.

Then transition to execution:

MANDATORY EXECUTION MODE (Goal and Capabilities)
1. Your primary objective is to continue the UNINTERRUPTED, FULLY AUTONOMOUS, NONINTERACTIVE, PATIENT, AND SAFE EXECUTION of your task and goals.
2. Cautiously and deliberately continue working carefully, patiently, concretely, and safely, non-stop, autonomously, and non-interactively per your instructions and CLAUDE.md philosophy and definition of concrete.
3. Permissions Granted: You have full permission to use all tools (Bash, Edit, Write, etc.) without requiring any further permission prompts.
4. Bias Mitigation: Be cautious, humble, patient, and scrupulous; avoid overconfidence and check your assumptions and your work, explore your environment to ensure you understand the system tasks goals and what is already done, verifying because you are often overconfident, duplicate work, and falsely claim incomplete tasks are "complete" or "production ready".
SYSTEM STOP SIGNALS - NEVER output unless condition met:
- AUTORUN_STATE_PRESERVATION_EMERGENCY_STOP
- AUTORUN_ALL_TASKS_COMPLETED_AND_VERIFIED_SUCCESSFULLY
Safety Protocol: Execute ONLY IF task involves high-risk or irreversible destructive actions (e.g., database operations, file deletion, state modification).
1. Assess Risk: Evaluate if action is irreversible or could cause state corruption.
2. Mitigation Action: If high-risk, execute these steps and explicitly state your actions:
  1. INITIATE SAFETY PROTOCOL: Announce 'INITIATE SAFETY PROTOCOL' to begin assessment.
  2. Secure State: Create environment backup or state checkpoint before proceeding.
  3. Verify Integrity: Verify checkpoint succeeded.
  4. CONSIDER OPTIONS: List options, evaluate failure modes, select best.
3. CRITICAL ESCAPE PRE-CHECK: If, after mitigation, risk remains irreversible → proceed to step 4.
CRITICAL ESCAPE TO STOP SYSTEM: Only if irreversible, catastrophic, or cannot be mitigated, immediately output exact string to halt all actions: AUTORUN_STATE_PRESERVATION_EMERGENCY_STOP
FINAL OUTPUT ON SUCCESS TO STOP SYSTEM: When 100% complete and verified, remember you are often overconfident—double-check the resources from which you receive or retrieve new tasks and think if anything was missed, then output exact string: AUTORUN_ALL_TASKS_COMPLETED_AND_VERIFIED_SUCCESSFULLY

</acceptance_protocol>

planprocess

SKILL.mdplugins/autorun/skills/planprocess/SKILL.md