plan-and-scope
Skill4 starsChanged 3 months agoMITView on GitHub
Creating a structured, phased implementation plan before coding: goals, in/out scope, dependencies, risks. Apply at the start of any new feature, refactor, or project.
In this repository53 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- actionableSkill
- astro-bootstrapSkill
- astro-patternsSkill
- autopilotSkill
- axon-code-intelSkill
- brainstormingSkill
- commit-conventionsSkill
- cross-repo-contextSkill
- django-bootstrapSkill
- django-patternsSkill
- executeSkill
- find-sessionSkill
- flutter-bootstrapSkill
- flutter-patternsSkill
- full-featureSkill
- intelSkill
- nextjs-bootstrapSkill
- nextjs-fullstack-bootstrapSkill
- nextjs-fullstack-patternsSkill
- nextjs-mui-bootstrapSkill
- nextjs-patternsSkill
- nextjs-shadcn-bootstrapSkill
- orchestratorSkill
- phase-breakdownSkill
- prdSkill
- reactSkill
- recallSkill
- reflectSkill
- relaySkill
- rememberSkill
- scaffoldSkill
- scratchSkill
- tailwindSkill
- ux-specSkill
- ux-to-promptsSkill
- verify-astroSkill
- verify-djangoSkill
- verify-flutterSkill
- verify-nextjs-fullstackSkill
- verify-nextjs-muiSkill
- verify-nextjs-shadcnSkill
- verify-nextjsSkill
- verifySkill
- visual-feedbackSkill
- work-disciplineSkill
- worktreesSkill
- wrapSkill
- write-as-friendSkill
- write-as-humanSkill
- writing-clearlySkill
- writing-skillsSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 0 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 20
If a PRD exists (*-prd.md), read it — scope and goals are already defined.
- Very specific: line 21
If a UX spec exists (*-ux-spec.md), read it — reference states, flows, and affordances when defining phase tasks.
- Very specific: line 89
Keep phases small — the phase-breakdown skill owns the sizing rule (target: 1-3 hours of focused execution, reviewable in a single PR).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Skill: Plan and Scope
Purpose
Guide the creation of a structured, phased implementation plan before any code is written.
When to Use
At the start of any new feature, refactor, or project. Always plan before executing.
Process
1. Clarify the Goal
- What is the end-user outcome?
- What are the constraints (time, tech, compatibility)?
- What already exists that we're building on?
- If a PRD exists (
*-prd.md), read it — scope and goals are already defined. Focus on dependencies, risks, and phasing. - If a UX spec exists (
*-ux-spec.md), read it — reference states, flows, and affordances when defining phase tasks.
2. Define the Scope
- List what IS in scope (be specific)
- List what is NOT in scope (be explicit — this prevents creep)
- Identify assumptions that need validation
3. Map Dependencies
- What existing code/APIs/services does this touch?
- Are there cross-repo dependencies (backend ↔ frontend)?
- What needs to exist before this can start?
- Repo strategy: Will this be a monorepo (single
fullstackprofile) or separate repos per concern (e.g.,django-api+nextjs)? Ask the user — this affects how/scaffoldcreates sub-projects and how phases are organized.
4. Identify Risks
- What could go wrong?
- What are we unsure about technically?
- Where might the plan need to change?
5. Produce the Plan Document
Output a plan.md with this structure:
# Plan: [Feature Name]
## Goal
One paragraph describing the desired outcome.
## Scope
### In Scope
- ...
### Out of Scope
- ...
## Phases
Grouping and ordering only. Each phase's internal structure — objective, input,
tasks, output, suggested skills, branch, verification checklist — follows the
`phase-breakdown` skill; don't duplicate those fields here. Tag every phase with
its `[directory/]` and mark parallel groups and sync points.
## Parallel Group A (Phases 1-2)
### Phase 1: [Backend — Name] [server/]
### Phase 2: [Frontend — Name] [web/]
## Sync Point: [e.g., Integration Summary]
## Phase 3: [Name] [directory/]
...
## Repo Strategy
Monorepo / Separate repos: [choice]
Sub-projects: [e.g., api (django-api), web (nextjs)]
## Dependencies
- ...
## Risks & Open Questions
- ...
## Cross-Repo Notes
- Backend contract changes needed: Y/N
- Frontend integration summary required: Y/NKey Principles
- Plans are living documents — update them as you learn
- Each phase should be independently reviewable (own branch, own PR)
- A plan that's too detailed upfront is as bad as no plan — aim for clarity on WHAT, flexibility on HOW
- Keep phases small — the
phase-breakdownskill owns the sizing rule (target: 1-3 hours of focused execution, reviewable in a single PR). If a phase feels too big, split it.
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.

