plan-driven-development
Skill4 starsChanged 4 months agoMITView on GitHub
Execute complex, long-running development work through a living ExecPlan organized into phases and bounded tasks. Use when one overall goal requires multiple dependent tasks or must continue across phases or sessions.
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- build-incrementalSkill
- code-simplifySkill
- create-or-clone-repositorySkill
- design-firstSkill
- implementation-workflowSkill
- manage-git-worktreesSkill
- setup-wiki-backed-project-skillsSkill
- subagent-supervisionSkill
- task-briefSkill
- test-driven-debugSkill
- tidy-firstSkill
- write-personal-wikiSkill
- write-project-wikiSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 17 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈17
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use this workflow when one overall goal requires multiple coordinated tasks organized into phases, especially when tasks have dependencies …
- Very specific: line 26
Use $task-brief as needed to clarify the overall goal, context, constraints, or completion conditions before creating the ExecPlan.
- Distinctive: line 37
Keep each Phase and Task cohesive and appropriately scoped.
- Distinctive: line 39
After drafting the ExecPlan, review its granularity and dependencies, and revise it as needed.
- Distinctive: line 45
Check: Existing-model inference passes validation.
- Distinctive: line 50
Check: New-model inference passes validation.
- Distinctive: line 53
Check: The result meets the requirements: RTF: XX and P90 latency < Y ms.
- Distinctive: line 57
Check: The pull request has been created.
- Distinctive: line 59
Create the ExecPlan using the instructions and template below.
- Very specific: line 65
After the user confirms the ExecPlan, set Status to active and work through its phases and tasks in order.
- Very specific: line 67
Keep Current and Last updated current.
- Distinctive: line 69
After completing all tasks and checks in a phase, present the result and supporting evidence to the user.
- Distinctive: line 71
Keep the ExecPlan current at every meaningful stopping point so work can continue from it in a later session.
- Distinctive: line 75
Treat the ExecPlan as a living plan rather than a fixed specification.
- Distinctive: line 77
Add or adjust phases and tasks in response to discoveries during the work or requests from the user.
- Distinctive: line 79
When a decision or discovery changes later work:
- Very specific: line 83
Update Current and Last updated.
- Distinctive: line 85
Keep only information that affects coordination or subsequent work.
- Very specific: line 87
If the work becomes materially blocked, set Status to blocked and record the blocker and required next action.
- Distinctive: line 91
After all phases are complete:
- Distinctive: line 97
Do not mark the ExecPlan complete while required tasks or phase checks remain unresolved.
- Distinctive: line 101
Create the ExecPlan at:
- Very specific: line 105
If creating .agent-work/, create .agent-work/.gitignore containing only *.
≈ “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
Plan-Driven Development
Execute complex development work through a living ExecPlan. Use it to coordinate phases, bounded tasks, progress, and plan revisions.
When to Use
Use this workflow when one overall goal requires multiple coordinated tasks organized into phases, especially when tasks have dependencies or the work must continue across sessions.
Typical use cases include:
- End-to-end work for a single pull request.
- Initial implementation of an MVP.
- Performance optimization against defined targets.
Workflow
1. Clarify the Task
Inspect relevant repository evidence and identify major dependencies, risks, and sequencing constraints.
Use $task-brief as needed to clarify the overall goal, context, constraints, or completion conditions before creating the ExecPlan.
2. Define the ExecPlan
Develop an ExecPlan of the work.
Decompose the ExecPlan into appropriately sized Phases and Tasks.
- A Phase is a milestone with a clear goal that is meaningful for the user to review.
- A Task is an implementation or work unit for the agent, including the tests or verification appropriate to that unit.
Keep each Phase and Task cohesive and appropriately scoped.
After drafting the ExecPlan, review its granularity and dependencies, and revise it as needed.
Example: add support for a new model to an inference server.
- Phase 1: Validate inference with an existing model
- Task 1.1: Verify the inference server with an existing model.
- Check: Existing-model inference passes validation.
- Phase 2: Implement inference for the new model
- Task 2.1: Add the new model implementation and run an end-to-end forward test.
- Task 2.2: Add the startup path for the new model.
- Task 2.3: Run smoke tests and verify inference behavior.
- Check: New-model inference passes validation.
- Phase 3: Meet the throughput requirements
- Task 3.1: Iterate on inference optimization and benchmarking.
- Check: The result meets the requirements: RTF: XX and P90 latency < Y ms.
- Phase 4: Ship the pull request
- Task 4.1: Refactor the changes and complete an independent review.
- Task 4.2: Push the branch and open the pull request.
- Check: The pull request has been created.
Create the ExecPlan using the instructions and template below.
Present the completed ExecPlan to the user and wait for confirmation before starting execution.
3. Execute the Plan
After the user confirms the ExecPlan, set Status to active and work through its phases and tasks in order.
Keep Current and Last updated current. Perform the appropriate verification for each task, and record material decisions or discoveries in the ExecPlan.
After completing all tasks and checks in a phase, present the result and supporting evidence to the user. Wait for confirmation before proceeding.
Keep the ExecPlan current at every meaningful stopping point so work can continue from it in a later session.
4. Revise the Plan
Treat the ExecPlan as a living plan rather than a fixed specification.
Add or adjust phases and tasks in response to discoveries during the work or requests from the user.
When a decision or discovery changes later work:
- Record it under
Decisions and Discoveries. - Revise affected dependencies and checks.
- Update
CurrentandLast updated.
Keep only information that affects coordination or subsequent work. Do not duplicate details already captured in task-specific records or artifacts.
If the work becomes materially blocked, set Status to blocked and record the blocker and required next action.
5. Complete the Work
After all phases are complete:
- Confirm that the overall goal and completion conditions are satisfied.
- Record the outcome, supporting evidence, and remaining issues under
Result. - Set
Statustocomplete,CurrenttoComplete, and updateLast updated.
Do not mark the ExecPlan complete while required tasks or phase checks remain unresolved.
ExecPlan
Create the ExecPlan at:
.agent-work/plans/{YYYY-MM-DD}-{short-task-name}.md
If creating .agent-work/, create .agent-work/.gitignore containing only *. Do not modify the repository root .gitignore.
Use this template:
# {Plan title}
Status: draft
Current: Draft
Last updated: {YYYY-MM-DD}
## Goal
{State the overall goal and completion conditions confirmed with the user.}
## Context and Constraints
{Record the context, material constraints, dependencies, and explicit non-goals needed to execute the plan.}
## Phases
### Phase 1: {Phase title}
**Goal and Scope**
- {State what this phase achieves, what it includes, and what it intentionally excludes.}
**Tasks**
- [ ] Task 1.1: {Bounded task}
- [ ] Task 1.2: {Bounded task}
**Checks**
- [ ] Check 1: {Condition that confirms the phase is complete.}
### Phase 2: {Phase title}
**Goal and Scope**
- {State what this phase achieves, what it includes, and what it intentionally excludes.}
**Tasks**
- [ ] Task 2.1: {Bounded task}
- [ ] Task 2.2: {Bounded task}
**Checks**
- [ ] Check 1: {Condition that confirms the phase is complete.}
## Decisions and Discoveries
- {Record only decisions or discoveries that change subsequent work.}
## Result
{At completion, summarize the outcome, supporting evidence, and remaining issues.}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.

