plan-project
Skill212 starsChanged 5 months agoMITView on GitHub
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.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- KodingDev/skillstheir own version, first seen Oct 2, 2026
- pi247/classic-PM-skillstheir own version, first seen Aug 21, 2026
- link7373/agentic-pmotheir own version, first seen Aug 9, 2026
- YUVARAJ-R-ai/my-claude-skillstheir own version, first seen Jun 30, 2026
- qkitzero/kage-bunshintheir own version, first seen Apr 5, 2026
- MooseDesign1/DDD-DesignDrivenDevelopmenttheir own version, first seen Mar 30, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- MooseDesign1/DDD-DesignDrivenDevelopment★ 9same name
- KodingDev/skills★ 2same name
- YUVARAJ-R-ai/my-claude-skills★ 2same name
- link7373/agentic-pmo★ 1same name
- pi247/classic-PM-skills★ 1same name
- qkitzero/kage-bunshin★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- add-agentSkill
- plan-milestoneSkill
- planSkill
- plan-taskSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 6 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 44
Document options considered, not just the chosen path.
- Distinctive: line 67
Leave internal implementation details for milestone and task planning.
- Very specific: line 94
When all phases are complete, compile into docs/plan/project.md using this structure:
“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Project Planning
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.
Output
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.
Process
Work through these phases interactively with the user. Do not rush ahead. Each phase should be a conversation.
Phase 1: Problem Definition
Clarify what we're building and why.
- What problem are we solving?
- Who is it for?
- What does success look like?
- What are the constraints (resources, technical, organizational)?
- What direct requests have come from customers or potential users?
- What are their stated requirements vs. underlying needs?
Capture answers in a working draft. Confirm understanding before proceeding.
Phase 2: Solution Exploration
Explore the solution space before committing to an approach.
- What are the possible approaches?
- What are the tradeoffs of each?
- Are there existing solutions or prior art to consider?
- What technologies or patterns are candidates?
Document options considered, not just the chosen path.
Phase 3: Technical Due Diligence
Identify risks and unknowns early.
- What are the biggest technical unknowns?
- Are there feasibility concerns that need validation?
- What dependencies exist (external services, APIs, libraries)?
- What could go wrong?
Flag items that need spikes or proof-of-concept work.
Phase 4: Architecture Sketch
Outline how the pieces fit together. Focus on decisions that are hard to reverse, affect milestone boundaries, or require early validation.
- What are the major components?
- How do they interact?
- What are the key interfaces or boundaries?
- What data flows through the system?
- What decisions are hard to change later (data models, public APIs, core abstractions)?
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.
Phase 5: Rollout Planning
For modifications to existing systems, define how to deploy safely.
- Is this a new system or a modification to an existing one?
- What is the migration path for existing users or data?
- Can changes be rolled out incrementally (feature flags, canary, percentage rollout)?
- What is the rollback plan if something goes wrong?
- Are there dependencies on external teams or systems for rollout?
Skip this phase for greenfield projects with no existing users.
Phase 6: Milestone Breakdown
Divide the work into logical chunks.
- What are the natural phases of delivery?
- What can be delivered incrementally?
- What are the dependencies between milestones?
- What is the rough sequence?
Each milestone should have a clear goal and boundary.
Project Plan Template
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}Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

