alex/dotfiles
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: standardize verification handoffs and lane claims

Browse Source
This commit is contained in:
alex wiesner
2026-03-13 21:41:00 +00:00
parent a3045255a7
commit c02e386846
5 changed files with 52 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
.config/opencode/skills/dispatching-parallel-agents/SKILL.md
View File

@@ -10,26 +10,29 @@ Use this skill before parallel fan-out.
## Isolation Test (Required)
Parallel lanes are allowed only when lanes do not share:
Before fan-out, verify that no two lanes share:
- files under active mutation
- **Claimed Files/Areas** under active mutation (paths or named workflow surfaces from the lane-claim entries)
- APIs or schemas being changed
- verification steps that must run in sequence
- **Sequential verification dependencies** (verification steps that must run in order across lanes)
If any of these overlap, run sequentially.
Overlapping claimed files/areas or sequential verification dependencies **forbid** parallel fan-out. Run those lanes sequentially.
## Workflow
1. Define lanes with explicit scope, inputs, and outputs.
2. Assign a single integrator (usually builder) for merge and final validation.
3. Require each lane to provide verification evidence, not just code output.
4. Integrate in dependency order.
5. Run final end-to-end verification after integration.
1. **Builder creates lane-claim entries** in the execution note before fan-out, recording for each lane: `Owner`, `Status` (→ `active`), `Claimed Files/Areas`, `Depends On`, and `Exit Condition`.
2. Run the isolation test above against the claimed files/areas and dependencies. Abort fan-out on any overlap.
3. Define lane scope, inputs, and outputs for each subagent.
4. Assign a single integrator (usually builder) for merge and final validation.
5. Each lane must return **compact verification evidence** in the shared shape (`Goal`, `Mode`, `Command/Check`, `Result`, `Key Evidence`, `Artifacts`, `Residual Risk`) — not just code output.
6. Integrate in dependency order; update lane statuses to `released` or `done`.
7. Run final end-to-end verification (`full` mode) after integration.
## Planner/Builder Expectations
- Planner: design parallel lanes only when isolation is demonstrable.
- Builder: load this skill before fan-out and enforce lane boundaries strictly.
- **Planner**: define intended lanes and claimed files/areas in the approved plan when parallelization is expected.
- **Builder**: load this skill before fan-out, create or update lane-claim entries in the execution note, mark them `active`/`released`/`done`/`blocked`, and enforce lane boundaries strictly.
- Claims are advisory markdown metadata, not hard runtime locks. Do not invent lockfiles or runtime enforcement.
## Red Flags