name: gameplan description: Guides creating detailed execution plans for features, refactors, and code changes. Use when user requests a gameplan, or when user invokes /gameplan.

Gameplan Skill

Create a comprehensive execution plan before implementing significant code changes.

When to Use

• User explicitly requests a gameplan or invokes /gameplan
• Planning a new feature, refactor, or significant code change
• Changes span multiple files or have complex dependencies

Process

1. Understand the Request

Before writing anything, gather context:

• Read the relevant existing code to understand current state
• Identify all files that might be affected
• Ask clarifying questions to eliminate ambiguity

Ask questions NOW, not later. The plan must be executable without further clarification.

2. Create the Plan File

Create a markdown file in the plans/ directory named after the feature:

• Use kebab-case: feature-name.md
• Examples: physics-refactor.md, auth-system.md, performance-optimization.md

3. Required Sections

Every gameplan must include these four sections:

Current State

Describe what the codebase looks like now:

• List relevant files with their paths
• Describe the current architecture/approach
• Note any pain points or limitations being addressed

Desired Changes

Describe what we want to achieve:

• Clear description of the end goal
• Why this change is being made
• Any constraints or requirements

Files to Modify

List every file that needs changes:

- `src/path/to/file.ts` - Brief description of changes needed
- `src/another/file.ts` - What will be added/modified/removed

Be specific about function names, classes, and line-level changes where possible.

Execution Order

Specify what can be done in parallel vs sequentially:

## Parallel Work (no dependencies)
- File A and File B can be modified independently

## Sequential Work (has dependencies)
1. First: Create new interfaces in types.ts
2. Then: Update implementations that depend on those interfaces
3. Finally: Update tests

Quality Checklist

Before finalizing the plan, verify:

• No open questions remain
• All affected files are listed
• Current state accurately reflects the code (you read it, not guessed)
• Execution order accounts for all dependencies
• Another developer could execute this plan without asking questions