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
- etr/groundworktheir own version, first seen Nov 8, 2026
- rumotion/ai-agent-project-templatetheir own version, first seen Nov 1, 2026
- griffinhilly/claude-code-synthesistheir own version, first seen Nov 1, 2026
- fitlab-ai/agent-infratheir own version, first seen Oct 27, 2026
- anaidenko/claude-notify-resumetheir own version, first seen Oct 15, 2026
- Yesterday-AI/ytstacktheir own version, first seen Oct 13, 2026
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.
AWSSkillship
Finalize dev work on an issue branch — update docs, push, and open a PR.
Also in 3 projects that use this
MicrosoftSkillhandoff
Compact the current conversation into a handoff document for another agent to pick up.
Also in 4 projects that use this
GoogleSkillcode-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
Other versions12 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 12
- ModelEngine-Group/fit-framework★ 2.1ksame name
- fitlab-ai/agent-infra★ 87same name
- griffinhilly/claude-code-synthesis★ 67same name
- jezweb/vite-flare-starter★ 49same name
- etr/groundwork★ 45same name
- LevNas/ccmemo★ 4same name
- Yesterday-AI/ytstack★ 2same name
- anaidenko/claude-notify-resume★ 1same name
- NAVNAV221/ai-native-codebase★ 1same name
- rumotion/ai-agent-project-template★ 1same name
2 more not listed
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
- plan-projectSkill
- planSkill
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
- Distinctive: line 33
Before writing code, understand what we're building and how.
- Distinctive: line 53
Consider edge cases and error handling
- Very specific: line 61
Keep the implementation steps checklist in task.md current as steps are completed
- Distinctive: line 66
Update the execution log whenever:
- Distinctive: line 72
Do not let updates accumulate.
- Distinctive: line 91
When the task is done:
- Distinctive: line 95
Verify each acceptance criterion is met
- Distinctive: line 97
Ensure the PR is ready for review
- Distinctive: line 110
Update the milestone plan if this task revealed new information
- Distinctive: line 111
Create decision documents for any significant decisions made
“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.
Files
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.mdcurrent 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}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.

