// Create a project plan for a new initiative. Use when starting a new project, defining goals, breaking work into milestones, and doing initial technical due diligence.
Add a new AI coding agent to Agent Sandbox. Creates all required files (Dockerfile, templates, CI, docs) and wires the agent into the CLI, proxy, and build system.
Break a milestone into discrete tasks. Use when starting work on a milestone that has been defined in the project plan.
Entry point for the three-tier planning system. Use when starting planning work at any level - project, milestone, or task.
Plan and track execution of a task. Use when starting implementation of a task defined in a milestone plan.
| name | plan-project |
| description | Create a project plan for a new initiative. Use when starting a new project, defining goals, breaking work into milestones, and doing initial technical due diligence. |
Part of the three-tier planning system. See /plan for an overview.
This skill guides the creation of a high-level project plan. The output defines goals, approach, architecture, and milestones. It is intentionally broad; detailed planning happens later during milestone planning and task planning as work progresses.
The final artifact is docs/plan/project.md.
The project plan can be updated as work progresses. When significant changes are made, update the plan to reflect current state and always create a decision record in docs/plan/decisions/. The decision records serve as the history of how the plan evolved.
Work through these phases interactively with the user. Do not rush ahead. Each phase should be a conversation.
Clarify what we're building and why.
Capture answers in a working draft. Confirm understanding before proceeding.
Explore the solution space before committing to an approach.
Document options considered, not just the chosen path.
Identify risks and unknowns early.
Flag items that need spikes or proof-of-concept work.
Outline how the pieces fit together. Focus on decisions that are hard to reverse, affect milestone boundaries, or require early validation.
Leave internal implementation details for milestone and task planning. The goal is knowing enough to draw milestone boundaries correctly and flag what needs early de-risking.
For modifications to existing systems, define how to deploy safely.
Skip this phase for greenfield projects with no existing users.
Divide the work into logical chunks.
Each milestone should have a clear goal and boundary.
When all phases are complete, compile into docs/plan/project.md using this structure:
# Project: {Name}
## Problem Statement
{What problem are we solving and why}
## User Requirements
{Direct requests and requirements from customers or potential users}
## Success Criteria
{How we'll know we succeeded}
## Constraints
{Resources, technical, organizational limitations}
## Approach
{Chosen approach and rationale}
### Alternatives Considered
{Other options explored and why they were not chosen}
### Literature Review
{Links to similar systems, architectures, or prior art reviewed during planning. Include brief notes on what was learned from each.}
## Architecture Overview
{High-level description of components and how they interact}
## Technical Risks
{Unknowns, feasibility concerns, dependencies}
## Rollout Plan
{Migration path, incremental rollout strategy, rollback plan. Omit for greenfield projects.}
## Milestones
### Milestone 1: {Name}
{Goal and scope}
### Milestone 2: {Name}
{Goal and scope}
{Continue as needed}
## Open Questions
{Anything unresolved that needs future attention}