packages/opencode-hive/skills/executing-plans/SKILL.md
Use when you have a written implementation plan to execute in a separate session with review checkpoints
npx skillsauth add tctinh/agent-hive executing-plansInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Load plan, review critically, execute tasks in batches, report for review between batches.
Core principle: Batch execution with checkpoints for architect review.
Announce at start: "I'm using the executing-plans skill to implement this plan."
Use hive_status() to get the runnable list — tasks with all dependencies satisfied.
Only done satisfies dependencies (not blocked, failed, partial, cancelled).
When 2+ tasks are runnable:
question(): "Multiple tasks are runnable: [list]. Run in parallel, sequential, or a specific subset?"hive_context_write({ name: "execution-decisions", content: "..." }) for future referenceWhen 1 task is runnable: Proceed directly.
For each task in the batch:
hive_worktree_start()When batch complete:
After the batch report, ask the operator if they want a Hygienic code review for the batch.
If yes, run task({ subagent_type: "hygienic", prompt: "Review implementation changes from the latest batch." }).
Route review feedback through this decision tree before continuing:
| Feedback type | Action |
|---------------|--------|
| Minor / local to the completed batch | Inline fix — apply directly, no new task |
| New isolated work that does not affect downstream sequencing | Manual task — hive_task_create() for non-blocking ad-hoc work |
| Changes downstream sequencing, dependencies, or scope | Plan amendment — update plan.md, then hive_tasks_sync({ refreshPending: true }) to rewrite pending tasks from the amended plan |
When amending the plan: append new task numbers at the end (do not renumber), update Depends on: entries to express the new DAG order, then sync.
After applying review feedback (or if none):
hive_status() for the updated runnable set — tasks whose dependencies are all satisfiedAfter all tasks complete and verified:
STOP executing immediately when:
Ask for clarification rather than guessing.
Return to Review (Step 1) when:
Don't force through blockers - stop and ask.
development
Use when you have a spec or requirements for a multi-step task, before touching code
testing
Use when independently verifying implementation claims, post-merge review, or when a reviewer needs to falsify success assertions with command-and-output evidence
data-ai
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
development
Use when implementing any feature or bugfix, before writing implementation code