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