/execute
Execute validated plans with isolated agents and two-stage review
$ npx -y skills add elb-pr/claudikins-kernel --agent claude-codeShips with claudikins-kernel. Installing the plugin gets this command.
How it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/execute
Context preview
What this command does when you run it.
Execute validated plans with isolated agents and two-stage review
Command definition
execute.mdname: claudikins-kernel:execute
description: Execute validated plans with isolated agents and two-stage review
argument-hint: <plan-path> | --resume | --status [--model opus|sonnet]
model: opus
agent_outputs:
- agent: babyclaude
capture_to: .claude/task-outputs/
merge_strategy: none
- agent: spec-reviewer
capture_to: .claude/reviews/spec/
merge_strategy: none
- agent: code-reviewer
capture_to: .claude/reviews/code/
merge_strategy: none
- agent: conflict-resolver
capture_to: .claude/conflict-resolutions/
merge_strategy: none
allowed-tools:
- Read
- Grep
- Glob
- Task
- Bash
- AskUserQuestion
- TodoWrite
- Skill
skills:
- git-workflow
output-schema:
type: object
properties:
session_id:
type: string
status:
type: string
enum: [completed, paused, aborted]
plan_source:
type: string
tasks_completed:
type: integer
tasks_total:
type: integer
batches_completed:
type: integer
batches_total:
type: integer
branches_merged:
type: array
items:
type: string
branches_remaining:
type: array
items:
type: string
required: [session_id, status, tasks_completed, tasks_total]claudikins-kernel:execute Command
You are orchestrating a task execution workflow with isolated agents and human checkpoints between batches.
Flags
| Flag | Effect | | --------------- | --------------------------------------------------- | | `--resume` | Resume from last checkpoint | | `--status` | Show current execution status | | `--abort` | Abort current execution (saves checkpoint) | | `--batch N` | Override batch size (default: from plan) | | `--model M` | Model for agents: `opus` or `sonnet` (default: opus)| | `--skip-review` | Skip code review (spec review still runs) | | `--dry-run` | Parse plan and show execution order without running | | `--timing` | Show task and batch durations | | `--trace` | Show execution trace at completion |
Merge Strategy
None - task outputs are saved per-task, not merged.
Philosophy
> "5-7 agents per SESSION, not 30 per batch. Features are the unit of work." - Boris
- One task = one branch (isolation prevents pollution)
- Fresh context per task (context: fork)
- Two-stage review (spec compliance, then code quality)
- Human checkpoints between batches (not individual tasks)
- Commands own git (agents never checkout/merge/push)
Load Skill
First, load the git-workflow skill for methodology:
Skill(git-workflow)
This provides:
- Task decomposition patterns
- Review criteria and thresholds
- Batch checkpoint decision trees
- Circuit breaker and tracing patterns
State Management
State file: `.claude/execute-state.json`
{
"session_id": "exec-YYYY-MM-DD-HHMM",
"plan_source": "path/to/plan.md",
"started_at": "ISO timestamp",
"status": "initialising|executing|paused|completed|aborted",
"current_batch": 1,
"current_task": null,
"tasks": [...],
"batches": [...],
"last_checkpoint": null
}Phase 0: Initialisation
Flag Handling
Check for flags first:
--status → Run execute-status.sh hook, display status, exit
--resume → Load checkpoint, resume from saved state
--abort → Save checkpoint, mark aborted, exit
--dry-run → Parse and display, don't execute
--model → Set agent model (opus|sonnet), stored in execute-state.json
Model Selection
If `--model` flag is provided, use the specified model. Otherwise, prompt the user:
AskUserQuestion({
question: "Which model should agents use for this execution?",
header: "Model Selection",
options: [
{ label: "Opus", description: "Most capable — best for complex tasks (uses more session quota)" },
{ label: "Sonnet", description: "Fast and capable — good for straightforward tasks (lighter on quota)" }
]
})Store the selected model in `execute-state.json` as `"model": "opus"|"sonnet"`. All `Task()` calls for babyclaude, spec-reviewer, and code-reviewer must use this value.
Plan Loading
1. Get plan path from argument or find most recent in `.claude/plans/` 2. Validate EXECUTION_TASKS markers exist (hook: validate-plan-format.sh) 3. Parse task table between markers 4. Build dependency graph
**On validation failure:**
Plan missing EXECUTION_TASKS markers.
The plan must include:
<!-- EXECUTION_TASKS_START -->
| # | Task | Files | Deps | Batch |
...
<!-- EXECUTION_TASKS_END -->
Run claudikins-kernel:outline to generate a properly formatted plan.
Dependency Graph
Build from parsed table:
{
"tasks": [
{
"id": "1",
"name": "Create schema",
"files": ["prisma/schema.prisma"],
"deps": [],
"batch": 1
},
{
"id": "2",
"name": "Add service",
"files": ["src/services/user.ts"],
"deps": ["1"],
"batch": 1
},
{
"id": "3",
"name": "Create routes",
"files": ["src/routes/user.ts"],
"deps": ["2"],
"batch": 2
}
],
"batches": [
{ "id": 1, "tasks": ["1", "2"], "status": "pending" },
{ "id": 2, "tasks": ["3"], "status": "pending" }
]
}Pre-Execution Validation
Per batch-size-verification.md:
if tasks.length > 15:
WARN "Large execution (${tasks.length} tasks). Consider splitting."
[Continue] [Abort]
if any_batch.tasks.length > 7:
WARN "Batch ${batch.id} exceeds 7 tasks. Review batch boundaries."
[Continue] [Adjust batches] [Abort]LOC Estimation
Per review-criteria.md (400 LOC threshold):
Estimate task LOC from file list.
If estimated > 400 LOC:
WARN "Task ${task.id} may exceed review threshold (~${estimate} LOC)"
[Proceed] [Split task] [Accept with caveat]Context Budget Validat
Read more
name: claudikins-kernel:execute
description: Execute validated plans with isolated agents and two-stage review
argument-hint: <plan-path> | --resume | --status [--model opus|sonnet]
model: opus
agent_outputs:
- agent: babyclaude
capture_to: .claude/task-outputs/
merge_strategy: none
- agent: spec-reviewer
capture_to: .claude/reviews/spec/
merge_strategy: none
- agent: code-reviewer
capture_to: .claude/reviews/code/
merge_strategy: none
- agent: conflict-resolver
capture_to: .claude/conflict-resolutions/
merge_strategy: none
allowed-tools:
- Read
- Grep
- Glob
- Task
- Bash
- AskUserQuestion
- TodoWrite
- Skill
skills:
- git-workflow
output-schema:
type: object
properties:
session_id:
type: string
status:
type: string
enum: [completed, paused, aborted]
plan_source:
type: string
tasks_completed:
type: integer
tasks_total:
type: integer
batches_completed:
type: integer
batches_total:
type: integer
branches_merged:
type: array
items:
type: string
branches_remaining:
type: array
items:
type: string
required: [session_id, status, tasks_completed, tasks_total]claudikins-kernel:execute Command
You are orchestrating a task execution workflow with isolated agents and human checkpoints between batches.
Flags
| Flag | Effect | | --------------- | --------------------------------------------------- | | `--resume` | Resume from last checkpoint | | `--status` | Show current execution status | | `--abort` | Abort current execution (saves checkpoint) | | `--batch N` | Override batch size (default: from plan) | | `--model M` | Model for agents: `opus` or `sonnet` (default: opus)| | `--skip-review` | Skip code review (spec review still runs) | | `--dry-run` | Parse plan and show execution order without running | | `--timing` | Show task and batch durations | | `--trace` | Show execution trace at completion |
Merge Strategy
None - task outputs are saved per-task, not merged.
Philosophy
> "5-7 agents per SESSION, not 30 per batch. Features are the unit of work." - Boris
- One task = one branch (isolation prevents pollution)
- Fresh context per task (context: fork)
- Two-stage review (spec compliance, then code quality)
- Human checkpoints between batches (not individual tasks)
- Commands own git (agents never checkout/merge/push)
Load Skill
First, load the git-workflow skill for methodology:
Skill(git-workflow)
This provides:
- Task decomposition patterns
- Review criteria and thresholds
- Batch checkpoint decision trees
- Circuit breaker and tracing patterns
State Management
State file: `.claude/execute-state.json`
{
"session_id": "exec-YYYY-MM-DD-HHMM",
"plan_source": "path/to/plan.md",
"started_at": "ISO timestamp",
"status": "initialising|executing|paused|completed|aborted",
"current_batch": 1,
"current_task": null,
"tasks": [...],
"batches": [...],
"last_checkpoint": null
}Phase 0: Initialisation
Flag Handling
Check for flags first:
--status → Run execute-status.sh hook, display status, exit --resume → Load checkpoint, resume from saved state --abort → Save checkpoint, mark aborted, exit --dry-run → Parse and display, don't execute --model → Set agent model (opus|sonnet), stored in execute-state.json
Model Selection
If `--model` flag is provided, use the specified model. Otherwise, prompt the user:
AskUserQuestion({
question: "Which model should agents use for this execution?",
header: "Model Selection",
options: [
{ label: "Opus", description: "Most capable — best for complex tasks (uses more session quota)" },
{ label: "Sonnet", description: "Fast and capable — good for straightforward tasks (lighter on quota)" }
]
})Store the selected model in `execute-state.json` as `"model": "opus"|"sonnet"`. All `Task()` calls for babyclaude, spec-reviewer, and code-reviewer must use this value.
Plan Loading
1. Get plan path from argument or find most recent in `.claude/plans/` 2. Validate EXECUTION_TASKS markers exist (hook: validate-plan-format.sh) 3. Parse task table between markers 4. Build dependency graph
**On validation failure:**
Plan missing EXECUTION_TASKS markers. The plan must include: <!-- EXECUTION_TASKS_START --> | # | Task | Files | Deps | Batch | ... <!-- EXECUTION_TASKS_END --> Run claudikins-kernel:outline to generate a properly formatted plan.
Dependency Graph
Build from parsed table:
{
"tasks": [
{
"id": "1",
"name": "Create schema",
"files": ["prisma/schema.prisma"],
"deps": [],
"batch": 1
},
{
"id": "2",
"name": "Add service",
"files": ["src/services/user.ts"],
"deps": ["1"],
"batch": 1
},
{
"id": "3",
"name": "Create routes",
"files": ["src/routes/user.ts"],
"deps": ["2"],
"batch": 2
}
],
"batches": [
{ "id": 1, "tasks": ["1", "2"], "status": "pending" },
{ "id": 2, "tasks": ["3"], "status": "pending" }
]
}Pre-Execution Validation
Per batch-size-verification.md:
if tasks.length > 15:
WARN "Large execution (${tasks.length} tasks). Consider splitting."
[Continue] [Abort]
if any_batch.tasks.length > 7:
WARN "Batch ${batch.id} exceeds 7 tasks. Review batch boundaries."
[Continue] [Adjust batches] [Abort]LOC Estimation
Per review-criteria.md (400 LOC threshold):
Estimate task LOC from file list.
If estimated > 400 LOC:
WARN "Task ${task.id} may exceed review threshold (~${estimate} LOC)"
[Proceed] [Split task] [Accept with caveat]Context Budget Validat
Showing the first part of this file.
SRE thinking applied to Claude Code, based on Boris Cherny's Q&A. It enforces a strict 4-stage pipeline with gates between each step. You literally cannot skip verification. You cannot ship without approval.

