Orchestrate plan-task
Breaks the next task from a plan into an implementable task file. Use when decomposing a multi-step plan into ordered work units.
install
source · Clone the upstream repo
git clone https://github.com/haowjy/orchestrate
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/haowjy/orchestrate "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/plan-task" ~/.claude/skills/haowjy-orchestrate-plan-task && rm -rf "$T"
manifest:
skills/plan-task/SKILL.mdsource content
Plan Task
Create the next implementable task from a plan.
When Invoked
Step 1: Read Inputs
Use these prompt variables:
— source plan to read{{PLAN_FILE}}
Resolve output directory:
- Always use a path next to the plan:
.<dir-of-PLAN_FILE>/tasks - Create the output directory if it does not exist.
Step 2: Read Progress
Gather context on what is already completed:
- Read
and inspect status/phase tracking sections.{{PLAN_FILE}} - If
exists, read it for prior completed tasks.<resolved-tasks-dir>/progress.md - If
exists, use it as context for continuity.<resolved-tasks-dir>/task.md
Step 3: Determine Completion
If all phases/steps in the plan are complete:
- Write only the text
toALL_DONE
.<resolved-tasks-dir>/task.md - Stop here.
Step 4: Create Task File
Determine the next logical task from the plan.
Write
<resolved-tasks-dir>/task.md. Include whatever structure makes sense, but the task file should give an implementing agent everything it needs:
- Context: why this task is next
- Scope: what to implement — files, functions, integration points
- Acceptance criteria: how to verify it's done
- Constraints: architectural limits, gotchas
A good task is self-contained: the codebase must be in a working state when done. Size is secondary — focus on logical completeness, not line count.