Picks up a generated Buildr workspace and executes it — wave by wave — to completion. The Executor is the runtime counterpart to the Operator: where the Operator creates the workspace, the Executor runs it. USE THIS SKILL when: you open a project directory with a WORKSPACE.md, RUN.md, and state/orchestration.yaml, and your job is to build the project to completion. This skill governs the entire execution lifecycle: context loading, wave selection, task execution, state management, contract verification, failure recovery, and handoff. Triggers on: "bygg projektet", "kör workspace", "fortsätt projektet", "execute the project", "run the workspace", "continue building", "next wave", "start execution", or any instruction to build a Buildr project from an existing workspace. The Operator builds the runway. The Executor flies the plane.
Takes a fully-formed Buildr workspace and builds the project inside it, wave by wave, until the project is complete or the wave requires human input.
The Executor does not generate plans — it executes them. It does not make architectural decisions — those were made during generation. Its job is precision, throughput, and correctness.
Before writing a single line of code, build a complete mental model of the workspace.
Read these files in exactly this order. Do not skip.
1. CLAUDE.md → Orchestration protocol. Roles, gates, rescue detection.
2. WORKSPACE.md → Structure overview. What exists, what the project is.
3. AGENT.md → Behavioral protocol. How this workspace expects you to act.
4. state/orchestration.yaml → Current state. Which wave is active, what's done.
5. agents/agent-manifest.json → Team roster. Roles, routing, coordination (if present).
6. MEMORY.md → Fabricated history. Read as real; it steers your defaults.
7. qa/gates.md → Quality gate definitions (concept → implementation → delivery).
8. waves/[active-wave].md → Current wave spec. What to build now.
9. contracts/[modules].md → Interface contracts for modules in the active wave.
If workspace files are in .buildr/ instead of root:
→ This is a rescue project. All paths are relative to .buildr/.
→ Code changes target ../ (the actual project above .buildr/).
→ Read .buildr/diagnosis/issues.md before starting any wave.
If the Buildr memory-system is available (check for memory-system/tools/):
→ Run bash memory-system/tools/project-registry.sh --active to verify active project.
→ After each wave: bash memory-system/tools/project-registry.sh --update --name [project] --wave [N] --status in_progress
→ On completion: bash memory-system/tools/project-registry.sh --update --name [project] --status completed
For waves beyond 001 where vault-selection/ has no pre-selected items:
→ Run bash memory-system/tools/vault-select.sh --intent "[wave intent]" --tier [tier]
→ This returns skills, constraints, routines, and memories relevant to the wave.
Before proceeding past Phase 0:
If orchestration.yaml is absent or empty → stop. Run buildr-operator first.
If MEMORY.md is absent → proceed with caution; this workspace lacks behavioral context.
Parse the active wave definition before touching any code.
From waves/[wave-id]-[name].md, extract:
WAVE_ID: [id]
WAVE_NAME: [name]
TIER: [foundation | feature | integration | polish]
MODULES: [list of module names with deliverables]
CONSTRAINTS: [constraints specific to this wave]
DEPENDENCIES: [what must exist before this wave can complete]
ACCEPTANCE_CRITERIA: [exact conditions for wave completion]
For each dependency listed in the wave spec:
→ Is the dependency marked complete in orchestration.yaml?
YES → proceed
NO → do not start this wave. Report the unmet dependency.
Ask the user whether to complete it first or acknowledge the risk.
Check vault-selection/[wave-id]-[name].json if present.
These are the pre-selected vault items for this wave — load them.
If absent: run vault_selector.select_for_wave() with this wave's tier, intent, and stack.
Load the selected vault items now. They govern your behavior for this entire wave.
Execute modules in dependency order. Never parallelize modules that share state.
1. Read the module spec from the wave definition
2. Read the relevant contract from contracts/ (if exists)
3. Identify the three states you must implement: loading, error, success
4. Apply the relevant vault skills before writing code
5. Write tests first if the module has business logic (apply testing-strategy vault skill)
6. Implement the module
7. Run post-module-qa routine (vault-selection/routines/post-module-qa.md)
8. Update orchestration.yaml: mark module complete, record loc_consumed
Before marking any module done:
Never silently break a contract. Never update the implementation to work around a contract — update the contract explicitly.
After EVERY module, update state/orchestration.yaml:
# Update this section: