agentleFS
mattolsonmattolson/agent-sandbox/.agents/skills/plan-task/SKILL.md

plan-task

Skill212 starsChanged 5 months agoMITView on GitHub

Plan and track execution of a task. Use when starting implementation of a task defined in a milestone plan.

12 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ship, handoff and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • AWSSkill

    ship

    Finalize dev work on an issue branch — update docs, push, and open a PR.

    Also in 3 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 4 projects that use this

  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 9 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 9

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

    Before writing code, understand what we're building and how.

    line 33
  2. Distinctive:

    Consider edge cases and error handling

    line 53
  3. Very specific:

    Keep the implementation steps checklist in task.md current as steps are completed

    line 61
  4. Distinctive:

    Update the execution log whenever:

    line 66
  5. Distinctive:

    Do not let updates accumulate.

    line 72
  6. Distinctive:

    When the task is done:

    line 91
  7. Distinctive:

    Verify each acceptance criterion is met

    line 95
  8. Distinctive:

    Ensure the PR is ready for review

    line 97
  9. Distinctive:

    Update the milestone plan if this task revealed new information

    line 110
  10. Distinctive:

    Create decision documents for any significant decisions made

    line 111

“Common” is measured: kept by at least 6 in 10 of the 10 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.

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

Task Planning and Execution

Part of the three-tier planning system. See /plan for an overview.

This skill guides implementation of a single task, from initial planning through completion. It maintains an execution log that captures problems, decisions, and learnings along the way.

Inputs

Before starting, read:

  • The milestone plan containing this task
  • docs/plan/learnings.md - to incorporate lessons from previous work
  • Any relevant decision documents in docs/plan/decisions/

Output

Two files in docs/plan/milestones/{milestone}/tasks/{task}/:

  • task.md - The plan and final outcome (living document, update as things change)
  • execution-log.md - Running log updated during implementation (captures the journey)

The task plan is a living document. Update scope, approach, and checklist as things evolve. The execution log preserves history, so there's no need to treat the plan as a snapshot.

Lifecycle

A task moves through three phases:

Phase 1: Planning

Before writing code, understand what we're building and how. Planning is iterative - expect to refine the approach through discussion before it's finalized.

This phase requires your approval before proceeding to execution.

1.1 Context Review

  • Review the task's summary, scope, and acceptance criteria from the milestone plan
  • Review applicable learnings from previous tasks
  • Confirm understanding of what "done" looks like

1.2 Codebase Exploration

  • Identify the files and systems involved
  • Understand existing patterns and conventions
  • Note integration points with other code

1.3 Approach Design

  • Outline the implementation approach
  • Identify changes needed (new files, modifications, deletions)
  • Consider edge cases and error handling
  • Flag uncertainties that need resolution

Capture the plan in the task document. Review and iterate until the approach is solid, then get explicit approval before proceeding to implementation.

Phase 2: Execution

During implementation:

  • Keep the implementation steps checklist in task.md current as steps are completed
  • Maintain the execution log in execution-log.md

When to Update the Log

Update the execution log whenever:

  • A new issue is encountered - describe the issue and its solution
  • A key decision is made - capture the choice and rationale
  • A lesson is learned - note insights that apply to future work
  • 10 minutes have passed since the last update - review and capture any salient information

Do not let updates accumulate. Frequent, small updates are more valuable than infrequent summaries.

What to Capture

  • Issues and solutions: Problems encountered and how they were resolved
  • Decisions: Technical choices and their rationale
  • Scope changes: Anything that changed from the original plan and why
  • Observations: Things noticed that might be relevant later

Checkpoints

At natural breakpoints, review progress:

  • Is the approach still sound?
  • Have we discovered anything that changes the plan?
  • Are there decisions that should be recorded formally in docs/plan/decisions/?
  • Does the implementation steps checklist need updating (new steps, changed steps, removed steps)?

Phase 3: Completion

When the task is done:

3.1 Acceptance Verification

  • Verify each acceptance criterion is met
  • Confirm tests are passing
  • Ensure the PR is ready for review

3.2 Learning Capture

Review the execution log and extract learnings from this task:

  • What would we do differently next time?
  • What worked well that we should repeat?
  • What did we learn that applies to future tasks?

Consolidate and distill insights from the execution log entries into docs/plan/learnings.md.

3.3 Cleanup

  • Update the milestone plan if this task revealed new information
  • Create decision documents for any significant decisions made
  • Note if downstream tasks are affected

Task Document Template

Create at docs/plan/milestones/{milestone}/tasks/{task}/task.md:

# Task: {identifier} - {name}

## Summary

{From milestone plan}

## Scope

{From milestone plan, updated if changed}

## Acceptance Criteria

{From milestone plan}
- [ ] {Criterion 1}
- [ ] {Criterion 2}

## Applicable Learnings

{Lessons from previous work that apply to this task}

## Plan

### Files Involved

{List of files to create, modify, or delete}

### Approach

{How we're going to implement this}

### Implementation Steps

- [ ] {Step 1}
- [ ] {Step 2}
- [ ] {Step 3}

### Open Questions

{Uncertainties to resolve during implementation}

## Outcome

### Acceptance Verification

- [x] {Criterion 1 - verified}
- [x] {Criterion 2 - verified}

### Learnings

{What we learned from this task - also append to docs/plan/learnings.md}

### Follow-up Items

{Anything discovered that affects other tasks or the milestone plan}

Execution Log Template

Create at docs/plan/milestones/{milestone}/tasks/{task}/execution-log.md.

Entries are in reverse chronological order - newest at the top, so the latest activity is always visible first.

# Execution Log: {identifier} - {name}

## {Timestamp} - Latest entry

{Entry describing what happened}

**Issue:** {If applicable - describe the problem}
**Solution:** {How it was resolved}

**Decision:** {If applicable - what was decided and why}

**Learning:** {If applicable - insight for future work}

## {Timestamp} - Previous entry

{Earlier entry}

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.