Cursor Plan

Cursor Plan

A persistent, reviewable analog to Cursor's Plan Mode. Claude Code's native plan mode is ephemeral; this skill produces a committed plan artifact the team can review in a PR before any code is touched.

When to use

• Multi-file refactors, migrations, or new features
• Anything where getting the approach wrong is expensive to unwind
• When the user explicitly asks to plan, scope, or design first

For a one-line fix, skip this and just make the change.

Workflow

1. Clarify intent (only if needed)

Resolve genuine ambiguity with at most one or two concise questions. If the request is clear, proceed without asking.

2. Investigate read-only

Do NOT edit any files in this phase. Gather context with Grep, Glob, and Read. For large or unfamiliar codebases, spawn an Explore subagent via Task to map the relevant area and return a summary, keeping the main context lean.

Identify:

• Every file the change will touch (cite exact path:line where relevant)
• Existing patterns/conventions to follow
• Hidden coupling, callers, tests, and config affected

3. Write the plan artifact

Save to .claude/plans/<YYYY-MM-DD>-<short-slug>.md using the template below. Create the .claude/plans/ directory if it does not exist.

# Plan: <title>

- **Date:** <YYYY-MM-DD>
- **Author:** Claude Code (cursor-plan)
- **Status:** Proposed

## Goal
One or two sentences. What "done" looks like.

## Affected files
- `path/to/file.ts` - what changes and why
- ...

## Approach
The chosen approach in prose. Note alternatives considered and why they were
rejected.

## Steps
1. <ordered, verifiable step>
2. ...

## Risks and rollback
- <risk> -> <mitigation>
- Rollback: how to revert (git, /rewind, feature flag, etc.)

## Out of scope
- <explicitly not doing>

## Verification
- Commands to run (build, lint, tests) and the expected result

4. Stop and present

Summarize the plan in chat and link the file path. Do not begin implementation until the user approves. Ask for approval explicitly.

5. Execute against the plan

Once approved, implement step by step, marking steps complete in the plan file as you go. If reality diverges from the plan, pause, update the plan, and note the deviation rather than silently improvising.

Rules

• No file edits during the investigation phase.
• Always cite exact path:line for claims about existing code.
• Keep the plan file committable: concise, accurate, no transient chatter.
• One plan = one focused objective. Split unrelated work into separate plans.