loop-executor
Scannednpx machina-cli add skill Ibrahim-3d/conductor-orchestrator-superpowers/loop-executor --openclawLoop Executor Agent — Step 3: EXECUTE
Implements the tasks defined in a verified plan.md. This agent writes code, creates files, and updates plan.md after every completed task.
Pre-Execution Checklist
Before writing any code:
- Read
plan.md— find first[ ]task (skip all[x]tasks) - Confirm plan was evaluated (check for Plan Evaluation Report in plan or track metadata)
- If no evaluation found → STOP → request Conductor run loop-plan-evaluator first
Execution Protocol
For Each Task
1. Mark task [~] in plan.md (in progress)
2. Read acceptance criteria
3. Implement the task
4. Verify acceptance criteria met
5. Update plan.md immediately:
- Mark [x]
- Add commit SHA
- Add summary of what was done
6. Commit code changes
7. Move to next [ ] task
plan.md Update Format (MANDATORY after every task)
- [x] Task 3: Build signup form component <!-- abc1234 -->
- Created src/components/auth/signup-form.tsx
- Added email validation (regex), password min 8 chars
- Integrated with authApi.signUp() from mock API client
- Acceptance: ✅ Form renders, validates, submits
TDD Integration
For tasks involving business logic, follow TDD from the tdd-implementation skill:
RED → Write failing test for the task's acceptance criteria
GREEN → Write minimal code to pass
REFACTOR → Clean up while tests stay green
Apply TDD to:
- Dependency resolution logic
- Lock/unlock/outdated propagation
- Price calculations and tier enforcement
- API request/response handling
- Form validation logic
Skip TDD for:
- CSS/styling tasks
- Static content
- Third-party library wrappers
Commit Protocol
Commit at these checkpoints:
- After each completed task (with plan.md update in same commit)
- After each completed phase
- Message format:
feat([scope]): [what was done]
Scope Discipline During Execution
While executing, if you discover work not in the plan:
## Discovered Work
- [ ] [Description of discovered work]
- Reason: [Why this is needed]
- Recommendation: [Add to current track / Create new track]
Add to plan.md under "Discovered Work" section. Do NOT silently implement it.
Business Doc Sync Awareness
While executing, if a task makes any of these changes, flag it for Step 5.5 (Business Doc Sync):
- Pricing tier, price point, or feature list changes
- AI model, SDK, or cost structure changes
- New package or tier additions
- Persona, GTM, or revenue assumption changes
- Asset pipeline changes (add/remove/modify assets)
Add a note in the execution summary:
**Business Doc Sync Required**: Yes/No
**Reason**: [e.g., "Added premium tier with Pro model"]
**Affected Docs**: [list from business-docs-sync skill registry]
See .claude/skills/business-docs-sync/SKILL.md for the full sync registry and protocol.
Error Handling During Execution
If a task cannot be completed:
- Mark task
[!]with explanation - Document the blocker in plan.md
- Continue with non-blocked tasks if possible
- Report blockers in execution summary
Execution Summary
After completing all tasks (or hitting a blocker):
## Execution Summary
**Track**: [track-id]
**Tasks Completed**: [X]/[Y]
**Tasks Blocked**: [count, if any]
**Commits**: [list of commit SHAs]
**Discovered Work**: [count, if any]
**Ready for**: Step 4 (Evaluate Execution) → hand off to loop-execution-evaluator
Metadata Checkpoint Updates
The executor MUST update the track's metadata.json at key points:
On Start
{
"loop_state": {
"current_step": "EXECUTE",
"step_status": "IN_PROGRESS",
"step_started_at": "[ISO timestamp]",
"checkpoints": {
"EXECUTE": {
"status": "IN_PROGRESS",
"started_at": "[ISO timestamp]",
"agent": "loop-executor",
"tasks_completed": 0,
"tasks_total": "[count from plan.md]",
"commits": []
}
}
}
}
After Each Task (Critical for Resumption)
{
"loop_state": {
"checkpoints": {
"EXECUTE": {
"status": "IN_PROGRESS",
"tasks_completed": 3,
"tasks_total": 10,
"last_task": "Task 1.3",
"last_commit": "abc1234",
"commits": [
{ "sha": "abc1234", "message": "feat: add form", "task": "Task 1.3" }
]
}
}
}
}
On Completion
{
"loop_state": {
"current_step": "EVALUATE_EXECUTION",
"step_status": "NOT_STARTED",
"checkpoints": {
"EXECUTE": {
"status": "PASSED",
"completed_at": "[ISO timestamp]",
"tasks_completed": 10,
"tasks_total": 10,
"last_task": "Task 3.2",
"last_commit": "def5678",
"commits": [...]
},
"EVALUATE_EXECUTION": {
"status": "NOT_STARTED"
}
}
}
}
Update Protocol
- Read current
metadata.jsonat start - Update
tasks_completed,last_task,last_commitafter EACH task - On completion: Advance
current_steptoEVALUATE_EXECUTION - Write back to
metadata.json
Resumption Support
If executor is restarted mid-execution:
- Read
metadata.json.checkpoints.EXECUTE.last_task - Find that task in
plan.md - Continue from the NEXT
[ ]task after the last completed one - Do NOT re-execute
[x]tasks
Handoff
After execution completes, the Conductor dispatches the loop-execution-evaluator to verify everything was built correctly.
Source
git clone https://github.com/Ibrahim-3d/conductor-orchestrator-superpowers/blob/master/skills/loop-executor/SKILL.mdView on GitHub Overview
Loop Executor implements tasks defined in a verified plan.md, writing code, creating files, and updating the plan after every task. It runs sequentially, commits at checkpoints, and uses TDD for business logic where applicable. This keeps execution traceable and aligned with plan evaluation results.
How This Skill Works
On start, the agent reads plan.md to find the first uncompleted task. For each task, it marks it in progress, reads acceptance criteria, implements the task, and verifies the criteria are met. It then updates plan.md with a completed mark, the commit SHA, and a summary, followed by a commit. It moves to the next task until all are done or blockers arise, applying TDD to relevant logic and skipping CSS/styling tasks.
When to Use It
- When plan.md has passed evaluation and there is a verified plan ready for execution
- When you need tasks to be implemented in strict sequence with plan.md tracking
- When per-task commits and plan.md updates are required at every checkpoint
- When business-logic tasks benefit from TDD-driven development
- When a discovered work possibility may require updating the plan and creating a new track
Quick Start
- Step 1: Read plan.md and locate the first [ ] task (skip [x] tasks)
- Step 2: Mark the task as in progress, read acceptance criteria, and implement it
- Step 3: Verify criteria, update plan.md with [x], record the commit SHA, and proceed to the next task
Best Practices
- Confirm that plan evaluation exists before starting execution
- Process the first [ ] task and proceed sequentially through plan.md
- After each task, update plan.md with [x], include commit SHA, and a concise summary
- Apply TDD to business-logic tasks (dependency resolution, calculations, API handling, etc.) and skip CSS/static tasks
- Document any discovered work in plan.md under Discovered Work and flag for business-doc-sync if needed
Example Use Cases
- Build signup form component as defined in Plan.md Task 3, then update plan.md and commit the changes
- Implement input validation and API integration using a mock client, verify acceptance criteria, and commit
- Add price calculation logic with tests (TDD), refactor to pass tests, and update plan.md after completion
- Encounter a discovered work (e.g., new authentication flow); add to plan.md under Discovered Work and create a new track if required
- Consolidate two small tasks into a single commit at a checkpoint while updating plan.md accordingly