Create working plan

Objective

Analyze the requested feature, enhancement or change and determine the best implementation approach before writing code.

For non-trivial tasks, document the implementation plan in a temporary workspace that serves as the single source of truth throughout the implementation.

Context

Before planning:

1. If project rules are available, read and follow them.
2. Otherwise, infer the project's conventions from the existing codebase.
3. Respect the project's architecture, coding patterns, conventions and documented design decisions.
4. Do not assume the project follows current best practices.
5. Prefer solutions that fit naturally into the existing architecture.

Planning Workspace

For implementations that:

• span multiple files;
• require multiple implementation steps;
• involve significant architectural decisions;
• are expected to require multiple interactions;

create a temporary Markdown workspace.

Create the workspace inside the project's .cursor directory.

If the project already defines a workspace convention, follow it. Otherwise, create:

.cursor/work/current-task.md

Create a workspace only when it provides meaningful value. Do not create one for small, self-contained changes — use the plan-implementation skill instead.

The workspace is temporary and exists only to support the current implementation.

Treat the workspace as the single source of truth for the current implementation.

Consult the workspace before making implementation decisions and update it whenever the implementation plan, progress or assumptions change.

Keep it synchronized with the implementation as work progresses.

Delete it when the implementation is complete unless explicitly instructed to keep it.

The workspace should contain:

• Objective
• Current Understanding
• Decisions
• Assumptions
• Affected Components
• Implementation Plan
• Progress (completed, in progress and remaining work)
• Open Questions
• Risks
• Notes

Planning Process

1. Understand the requested change.
2. Identify assumptions and ambiguities.
3. Identify the affected components.
4. Analyze dependencies and potential side effects.
5. Evaluate implementation options when meaningful trade-offs exist.
6. Recommend the preferred approach and explain why.
7. Break the work into logical implementation steps.
8. Identify risks and validation requirements.

Do not begin implementing until the approach is sufficiently understood.

Planning Guidelines

Ask questions only when missing information blocks the implementation.

Do not invent requirements.

Avoid unnecessary complexity.

Prefer incremental, reversible changes over large rewrites.

Reuse existing components, abstractions and patterns whenever appropriate.

Keep the implementation plan concise and focused.

Clearly distinguish facts, assumptions and recommendations.

When multiple approaches are viable, explain the trade-offs and recommend one.

Do not generate implementation code unless explicitly requested.

Output

For tasks that do not require a workspace:

Summary

Briefly describe the recommended implementation strategy.

Assumptions

List any assumptions made during planning.

Affected Components

List the files, modules or systems likely to be affected.

Implementation Plan

Provide the implementation as an ordered list of steps.

Risks

Identify technical risks, edge cases or migration concerns.

Validation

Describe how the implementation should be verified.

Open Questions

List only questions that must be answered before implementation.

For tasks that require a workspace:

1. Create the temporary workspace.
2. Populate it with the implementation plan.
3. Present a concise summary in the conversation.
4. Keep the workspace updated throughout the implementation.
5. Remove the workspace when the implementation is complete unless explicitly instructed otherwise.