agentleFS
arumaekawaarumaekawa/codex-skills/skills/plan-driven-development/SKILL.md

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.

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
  1. Distinctive:

    Use this workflow when one overall goal requires multiple coordinated tasks organized into phases, especially when tasks have dependencies …

    line 12
  2. Very specific:

    Use $task-brief as needed to clarify the overall goal, context, constraints, or completion conditions before creating the ExecPlan.

    line 26
  3. Distinctive:

    Keep each Phase and Task cohesive and appropriately scoped.

    line 37
  4. Distinctive:

    After drafting the ExecPlan, review its granularity and dependencies, and revise it as needed.

    line 39
  5. Distinctive:

    Check: Existing-model inference passes validation.

    line 45
  6. Distinctive:

    Check: New-model inference passes validation.

    line 50
  7. Distinctive:

    Check: The result meets the requirements: RTF: XX and P90 latency < Y ms.

    line 53
  8. Distinctive:

    Check: The pull request has been created.

    line 57
  9. Distinctive:

    Create the ExecPlan using the instructions and template below.

    line 59
  10. Very specific:

    After the user confirms the ExecPlan, set Status to active and work through its phases and tasks in order.

    line 65
  11. Very specific:

    Keep Current and Last updated current.

    line 67
  12. Distinctive:

    After completing all tasks and checks in a phase, present the result and supporting evidence to the user.

    line 69
  13. Distinctive:

    Keep the ExecPlan current at every meaningful stopping point so work can continue from it in a later session.

    line 71
  14. Distinctive:

    Treat the ExecPlan as a living plan rather than a fixed specification.

    line 75
  15. Distinctive:

    Add or adjust phases and tasks in response to discoveries during the work or requests from the user.

    line 77
  16. Distinctive:

    When a decision or discovery changes later work:

    line 79
  17. Very specific:

    Update Current and Last updated.

    line 83
  18. Distinctive:

    Keep only information that affects coordination or subsequent work.

    line 85
  19. Very specific:

    If the work becomes materially blocked, set Status to blocked and record the blocker and required next action.

    line 87
  20. Distinctive:

    After all phases are complete:

    line 91
  21. Distinctive:

    Do not mark the ExecPlan complete while required tasks or phase checks remain unresolved.

    line 97
  22. Distinctive:

    Create the ExecPlan at:

    line 101
  23. Very specific:

    If creating .agent-work/, create .agent-work/.gitignore containing only *.

    line 105

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 Current and Last 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:

  1. Confirm that the overall goal and completion conditions are satisfied.
  2. Record the outcome, supporting evidence, and remaining issues under Result.
  3. Set Status to complete, Current to Complete, and update Last 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.}

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.