ha-coding-plan

---
name: ha-coding-plan
description: "Hope-native implementation planning for non-trivial code changes: ground the plan in repository evidence, order dependencies, name critical files and risks, define verification, then continue execution when allowed."
paths: ["*.rs", "*.ts", "*.tsx", "*.js", "*.jsx", "*.py", "*.go", "*.java", "*.kt", "*.swift", "*.c", "*.cpp", "*.h", "*.rb", "*.php", "*.sh"]
---

# Hope Coding Plan

Plan only when planning reduces real uncertainty. A plan is an implementation
map, not a ritual and not a substitute for doing the work.

## When A Formal Plan Helps

Use a plan when the task has one or more of:

- Multiple ownership boundaries or dependent steps.
- Schema, migration, persistence, compatibility, or recovery risk.
- Ambiguous architecture with several credible approaches.
- Parallel work that needs explicit isolation and synthesis.
- Named completion criteria or a long-running Goal.

Skip a formal plan for a small, obvious, reversible edit with a direct check.

## Evidence First

Before planning:

1. Read the user request and explicit completion criteria.
2. Read `AGENTS.md`, relevant architecture, current diff, and critical code.
3. Find a similar implementation and trace the owning path.
4. Identify unknowns that materially change the design.

Do not invent files, APIs, tests, or migrations from naming alone.

## Plan Contents

Each step should name:

- Outcome and behavior changed.
- Critical files or subsystem, without pretending the exact line is known when
  it is not.
- Dependencies and why the order matters.
- Data, compatibility, permission, concurrency, or rollback risk.
- Direct verification and completion signal.

Keep steps sized for review and progress tracking, not artificial five-minute
chunks. Separate must-have work from optional follow-up.

## Modes And Execution

- In Plan Mode, remain read-only and return the implementation plan.
- Outside Plan Mode, when the user asked for implementation and the next step is
  clear, update task progress and continue. Do not ask "shall I proceed?" merely
  because a plan exists.
- Create a plan document only when the user asked for one or the repository
  requires a durable design artifact.
- `/goal` defines the outcome and criteria; this skill designs the current route.
- Use `ha-workflow-script` only when a durable dynamic script is justified.

## Parallelism Decision

Mark steps parallel only when they are independent and have non-overlapping
writes or explicit worktree isolation. Use `ha-multi-agent-coding` for execution
strategy. A single broad investigation is not a batch fan-out.

## Quality Check

Before accepting the plan:

- Does it preserve user changes and existing contracts?
- Does every required criterion have an implementation and evidence path?
- Are risky state transitions and failure recovery covered?
- Is the plan small enough to execute but complete enough to close?
- Is the first actionable step clear?

## Smoke Prompts

- "Plan this cross-crate feature, then implement it."
- "Design a read-only migration plan with rollback and verification."
- "Turn these completion criteria into an executable coding plan."