Help us improve
Share bugs, ideas, or general feedback.
From vibekit
Executes an approved implementation plan task-by-task, dispatching one fresh subagent per task with an RTCO brief, then validates output through schema check, self-review, and plan-compliance review before marking complete.
npx claudepluginhub rizukirr/vibekit --plugin vibekitHow this skill is triggered — by the user, by Claude, or both
Slash command
/vibekit:exec-dispatchThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Execute an approved plan one task at a time. Each task runs in a **fresh subagent** with no prior conversation history — only the RTCO brief and the plan excerpt. On return, the output passes through schema validation, self-review, and plan-compliance review before the task is marked complete.
Executes written implementation plans: loads and critically reviews them, runs tasks in dependency order with parallel dispatch, separate worker-validator subagents, and verifies completion.
Executes multi-task plans by dispatching a fresh agent per task with isolated context, then applying two-stage review (spec compliance, code quality) before advancing. Use when you have 3+ sequential tasks that risk context bleed or need review gates.
Executes multi-phase implementation plans by dispatching tasks to sub-agents, tracking progress per-task in plan.json, and coordinating sequential phases.
Share bugs, ideas, or general feedback.
Execute an approved plan one task at a time. Each task runs in a fresh subagent with no prior conversation history — only the RTCO brief and the plan excerpt. On return, the output passes through schema validation, self-review, and plan-compliance review before the task is marked complete.
One task per agent. One commit per task. No batching.
After plan-write has saved a plan and the user has chosen the subagent-driven execution option.
Do not invoke if:
docs/plans/YYYY-MM-DD-<feature-name>.md, approved.If any prerequisite fails, stop and report what is missing.
For each task in the plan, in order:
→ verify: <criterion>. If absent, vague ("works", "looks right"), or non-checkable, REJECT the task: stop the loop, surface the gap to the user, and route back to plan-write to repair the plan. Do not dispatch tasks lacking a verify clause.status discriminator: complete → step 5; needs_input → enter the NEEDS_INPUT halt-and-resume protocol (see §NEEDS_INPUT halt-and-resume protocol), then return to step 4 with the new return.Every dispatched brief has exactly these sections:
ROLE: <specific implementer identity matching the task domain>
TASK: Implement Task N — <task title> — from <plan path>.
CONSTRAINTS:
- Implement ONLY Task N. Do not touch any other task's files or tests.
- Follow every step in the task, in order, without skipping or reordering.
- TDD: write the failing test first and run it to confirm it fails before any implementation.
- After each code change, run the test command shown in the task and include the last 20 lines of output in your report.
- Make exactly one commit per logical change, using the commit message shown in the task.
- Edit ONLY files named in the task's "Files" section. No adjacent edits, no drive-by refactors.
- Match existing code style; do not "improve" formatting or comments unrelated to the task.
- Do not delete pre-existing dead code; if you notice some, mention it in OUTPUT.unexpected.
- Do not install new dependencies or modify package manifests unless the task explicitly says so.
- The task header's `→ verify:` clause is the success criterion; the task is not done until that criterion is observably met.
- If any step fails or produces output that does not match the task's "Expected" value, stop and report the failure. Do not improvise a fix.
CONTEXT:
Plan path: <path>
Plan commit SHA: <sha of HEAD for the plan file at dispatch time>
Task id: Task N
Instruction: read the plan file at <path> at commit <sha>, locate the section headed `### Task N:`, and follow every step in order. Do not paraphrase the plan; execute it as written.
Repo state: <branch, worktree, any user-visible constraints>
OUTPUT (return exactly this JSON schema):
{
"task_number": <int>,
"task_title": "<string>",
"files_created": ["<path>"],
"files_modified": ["<path>"],
"tests_added_or_changed": ["<path>"],
"test_commands_run": [
{"command": "<string>", "result": "pass|fail", "output_tail": "<last 20 lines verbatim>"}
],
"commits": [{"sha": "<string>", "subject": "<string>"}],
"unexpected": "<string — anything that deviated from the plan, empty if none>"
}
Every CONSTRAINT is verbatim. Every CONTEXT file path is verbatim. The OUTPUT schema is byte-identical to what the return-side filter will validate against.
Tool requirement. Because the plan is embedded by reference at a specific commit SHA, the dispatched subagent needs read access to the git object database — typically Read, Grep, Glob, and a Bash allowlist entry for git show and git log. If your runtime scopes tools per subagent, include those before dispatch, otherwise the agent cannot resolve the plan at the named commit and the task will fail with a permission error rather than a work error.
On receiving the subagent's output:
files_created and files_modified path exists on disk after the run.commits.sha resolves in the repo and matches the subject.test_commands_run.output_tail is preserved verbatim — do not paraphrase, do not trim.unexpected is a string (empty if nothing unexpected). Never null.When report-filter returns an accepted variant B (status: "needs_input") result, the dispatch loop enters this protocol instead of proceeding to the review gates. The protocol is bounded, verbatim-surfaced, and resumes via fresh re-dispatch.
The return claims rolled_back: true. Cross-check with the actual repo state:
git status --porcelain
git log --oneline <pre-task-sha>..HEAD
If git status shows uncommitted changes OR git log shows commits made during this task attempt that were not reverted, REJECT with delta: rolled_back claimed but <evidence> shows uncommitted/unreverted state. The subagent must roll back fully or the halt is rejected as malformed.
Each task starts with a NEEDS_INPUT budget of 2. Each accepted halt decrements the budget. If the current return is the third halt on this task (budget would go negative), do NOT surface to the user — escalate as a task failure with this verbatim message:
Task escalated — NEEDS_INPUT budget exhausted. Two prior halts have not produced a path forward. The plan or brief is likely structurally broken. Options: (1) roll back the task and route back to plan-write to repair the plan; (2) accept the unresolved ambiguity as a known-risk and continue with explicit user direction.
Print exactly this block, with field values quoted verbatim from the return — do not paraphrase, do not "clean up" the question:
> **Task <N> halted — needs input.**
>
> **Blocking step:** <blocking_step>
> **Ambiguity type:** <ambiguity_type>
> **Question:** <question>
>
> **What the subagent already tried:** <tried>
>
> **Options:**
> - **A.** <options[0].summary>
> - **B.** <options[1].summary>
> <... additional options if present ...>
>
> **Subagent recommendation:** <recommendation>
>
> Reply with an option label or your own answer. Halts remaining on this task: <budget_remaining>.
This wrapper joins the never-compress list. Never paraphrase, trim, or hide it.
Free-form. The user MAY reply with:
A, B, …) → fold the corresponding options[].summary into the augmented brief as the resolution.plan-write with the question and user response as new context. Do not attempt to re-dispatch.Re-run brief-compiler for the same task with one addition to the CONTEXT block:
Prior NEEDS_INPUT halt:
Question: "<question verbatim>"
User answer: "<answer verbatim>"
Halts remaining: <budget_remaining>
CONSTRAINTS unchanged from the original brief — the four NEEDS_INPUT bullets remain, since the subagent may halt again up to budget. OUTPUT schema unchanged — still the discriminated union.
Same procedure as the original step 3 of the dispatch loop. Fresh agent, no history of the prior attempt. The augmented CONTEXT is the only carryover.
Return to step 4 of the main dispatch loop. The new return goes through report-filter, gets routed by status, and either completes the task or triggers another NEEDS_INPUT cycle (up to budget).
Two reviews run after the filter accepts the report. Both must pass before the task is marked complete.
Check, by reading the report and the actual repo state:
→ verify: criterion is observably met (cite the evidence — passing test name, command output, etc.).files_created or files_modified.git diff --name-only against the pre-task state and cross-check).result: pass in its final run.test_commands_run.output_tail contains genuine test runner output (PASS/FAIL line, timing, counts), not a narrative summary.commits list matches git log for commits added during this task.unexpected is empty OR describes a deviation serious enough to surface to the user.Any unchecked box → stop. Do not proceed to Gate 2.
Read-only enforcement. "Read-only" is expressed in the brief's CONSTRAINTS but cannot be enforced by the brief alone. Where the runtime supports tool-allowlisting per subagent, restrict the dispatched agent to read-only tools (Read, Grep, Glob, and git read commands) and omit Edit, Write, and any shell that can mutate the repo. On runtimes without per-agent allowlists, the brief's CONSTRAINTS are the only guard — note this in the run log so users know the limitation.
Dispatch a small, read-only subagent with this brief:
ROLE: Plan-compliance reviewer, read-only.
TASK: Verify that Task N in <plan path> was implemented correctly.
CONSTRAINTS:
- Read-only. No edits, no commits.
- Base judgment on the actual repo state and the git history, not on the implementer's report.
- If any step in the plan was skipped, reordered, or implemented differently, flag it.
CONTEXT:
Plan path: <path>
Plan commit SHA: <sha of HEAD for the plan file at dispatch time>
Task id: Task N
Instruction: read the plan at <path> at commit <sha>, locate `### Task N:`, and compare against the implementer's commits below.
Implementer commits: <list of sha — subject>
OUTPUT:
{
"verdict": "pass|fail",
"findings": [{"severity": "block|warn", "description": "<string>", "evidence": "<file:line or commit sha>"}]
}
Verdict = pass + no block findings → task is accepted. Mark the task's checkboxes in the plan. Commit the plan update with message chore: complete Task N — <title>.
Verdict = fail OR any block finding → task is not accepted. Surface the findings to the user and ask whether to:
Do not silently retry. Do not silently accept a failing verdict.
Default is strictly sequential. Parallelism is opt-in per group, signaled by HTML-comment markers in the plan file. Tasks outside any group remain sequential.
<!-- parallel-group: <name>
rationale: <one-line justification — why these tasks are independent> -->
### Task K: ... → verify: ...
### Task K+1: ... → verify: ...
### Task K+M: ... → verify: ...
<!-- /parallel-group -->
<name> is kebab-case. The opening marker carries a rationale: line — plan authors must justify why the wrapped tasks are actually independent. plan-write is the source of truth for the grammar; exec-dispatch parses the markers.
For every parallel group, before fanning out:
→ verify: clause (already mandatory globally — re-check here).If any invariant fails, do not "best-effort" the group. Halt and surface the specific violation; user re-plans.
_authoring/quad-adapter.md)This skill's parallel mode requires: parallel subagent dispatch + per-subagent tool allowlist.
| Runtime | Parallel dispatch | Per-agent allowlist | Behavior on parallel-group |
|---|---|---|---|
| Claude Code | yes (Task fan-out) | yes | Native parallel; each task gets its own subagent. |
| Codex | yes (worker panes) | partial | Native parallel; allowlist enforced via brief CONSTRAINTS where per-agent tooling is unavailable. |
| Gemini CLI | no | no | Sequential fallback in declared task order, with verbatim degradation warning emitted before dispatch (see below). |
| opencode | provider-dependent | yes | Detect at dispatch time; sequential fallback if provider lacks parallel agents, with the same warning. |
| Pi | no | no | Sequential fallback in declared task order, with verbatim degradation warning emitted before dispatch. |
When the runtime cannot dispatch in parallel, emit this warning verbatim before running the group:
Capability degraded. Running on
<runtime>which lacks parallel subagent dispatch. Parallel-group<name>will execute sequentially in declared task order. Result is functionally equivalent; wall-clock will be longer. To opt out of this group entirely on this runtime, remove theparallel-groupmarkers in the plan and re-run.
This warning joins the never-compress list. Never paraphrase, trim, or hide it.
For every task in the group, in parallel:
<name>: . The files those tasks own are forbidden to this brief."report-filter to each return independently. A REJECT on one task does not block the others — they continue.chore: complete parallel-group <name>.If the capability gate selected sequential fallback:
chore: complete parallel-group <name> (sequential fallback).A NEEDS_INPUT halt inside a parallel-group does NOT halt the group. Sibling tasks continue executing. The halted task waits for the user's answer; on resume, it rejoins the group's completion-tracking. Group-fail-closed semantics still apply: if the halted task ultimately fails (budget exhausted, user routes to replan), the whole group is treated as failed and surfaced to the user per §Parallel dispatch procedure step 6.
--no-verify or --amend unless the user explicitly approves.plan-write with the halt question and user response as new context. Do not attempt to re-dispatch.unexpected field + escalation path.All N tasks complete. Plan: <path>. Commits: <first sha>..<last sha>.
Next: run the verify-gate skill to confirm the feature meets the spec.
Do not claim done without that final step.