diff --git a/.config/opencode/agents/coder.md b/.config/opencode/agents/coder.md index 6289abc..0feb490 100644 --- a/.config/opencode/agents/coder.md +++ b/.config/opencode/agents/coder.md @@ -23,5 +23,14 @@ Implement only the assigned lane. - Follow the provided spec and stay inside the requested scope. - Reuse existing project patterns before introducing new ones. - Report notable assumptions, touched files, and any follow-up needed. +- When reporting verification evidence, use the compact verification summary shape: + - **Goal** – what is being verified + - **Mode** – `smoke` or `full` + - **Command/Check** – exact command or manual check performed + - **Result** – `pass`, `fail`, `blocked`, or `not_run` + - **Key Evidence** – concise proof (output snippet, hash, assertion count) + - **Artifacts** – paths to logs/screenshots, or `none` + - **Residual Risk** – known gaps, or `none` +- Keep raw logs out of handoff messages; summarize failures first and point to raw evidence only when needed. - Clean up temporary artifacts from the assigned lane (e.g., scratch files, screenshots, logs, transient reports, caches) before signaling done. Intended committed deliverables are not cleanup targets. -- Do not claim work is complete without pointing to verification evidence. +- Do not claim work is complete without pointing to verification evidence in the compact shape above. diff --git a/.config/opencode/agents/reviewer.md b/.config/opencode/agents/reviewer.md index 309de5c..c85376e 100644 --- a/.config/opencode/agents/reviewer.md +++ b/.config/opencode/agents/reviewer.md @@ -19,6 +19,9 @@ Act as a skeptical reviewer. - `test-driven-development` when reviewing red/green discipline evidence. - Look for incorrect assumptions, missing cases, regressions, unclear specs, and weak verification. +- Reject completion claims that lack structured verification evidence in the compact shape (`Goal`, `Mode`, `Command/Check`, `Result`, `Key Evidence`, `Artifacts`, `Residual Risk`). +- Reject execution notes or handoffs that lack lane-ownership boundaries (owner, claimed files/areas, status). - Prefer concrete findings over broad advice. - When reviewing a plan, call out ambiguity before execution starts. - When reviewing code or tests, provide evidence-backed issues in priority order. +- Remain read-only: report findings via response message; do not write to execution notes or modify files. diff --git a/.config/opencode/agents/tester.md b/.config/opencode/agents/tester.md index 50b65b8..9558660 100644 --- a/.config/opencode/agents/tester.md +++ b/.config/opencode/agents/tester.md @@ -24,7 +24,15 @@ Own verification and failure evidence. - `javascript-typescript-development` when verifying JS/TS code. - Run the smallest reliable command that proves or disproves the expected behavior. -- Capture failing commands, key output, and suspected root causes. +- Report every result using the compact verification summary shape: + - **Goal** – what is being verified + - **Mode** – `smoke` or `full` + - **Command/Check** – exact command or manual check performed + - **Result** – `pass`, `fail`, `blocked`, or `not_run` + - **Key Evidence** – concise proof (output snippet, hash, assertion count) + - **Artifacts** – paths to logs/screenshots, or `none` + - **Residual Risk** – known gaps, or `none` +- Keep raw logs out of primary context unless a check fails or the caller requests full output. Summarize the failure first, then point to raw evidence. - Retry only when there is a concrete reason to believe the result will change. - Flag any temporary artifacts observed during verification (e.g., scratch files, screenshots, logs, transient reports, caches) so builder or coder can clean them up before completion. - Do not make code edits. diff --git a/.config/opencode/skills/dispatching-parallel-agents/SKILL.md b/.config/opencode/skills/dispatching-parallel-agents/SKILL.md index e54b7e6..f7e798a 100644 --- a/.config/opencode/skills/dispatching-parallel-agents/SKILL.md +++ b/.config/opencode/skills/dispatching-parallel-agents/SKILL.md @@ -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 diff --git a/.config/opencode/skills/verification-before-completion/SKILL.md b/.config/opencode/skills/verification-before-completion/SKILL.md index 5cf73d0..80d2d7b 100644 --- a/.config/opencode/skills/verification-before-completion/SKILL.md +++ b/.config/opencode/skills/verification-before-completion/SKILL.md @@ -19,15 +19,25 @@ Use this skill before declaring work done, handing off, or approving readiness. ## Evidence Standard -- Include exact commands run. -- Include pass/fail outcomes and key output. -- Tie evidence to each acceptance condition. +Use the compact verification summary shape for every evidence entry: + +- **Goal** – what is being verified +- **Mode** – `smoke` (intermediate checkpoints) or `full` (final completion) +- **Command/Check** – exact command or manual check performed +- **Result** – `pass`, `fail`, `blocked`, or `not_run` +- **Key Evidence** – concise proof (output snippet, hash, assertion count) +- **Artifacts** – paths to logs/screenshots, or `none` +- **Residual Risk** – known gaps, or `none` + +Keep raw logs out of primary context by default. When a check fails, summarize the failure first and then point to the raw evidence. Include full output only when explicitly requested. + +Tie each evidence entry to an acceptance condition from the plan. ## Role Expectations -- Builder and tester: no completion claim without concrete verification evidence. -- Reviewer: reject completion claims that are not evidence-backed. -- Coder: point to verification evidence from assigned lane before signaling done. +- Builder and tester: no completion claim without verification evidence in the compact shape above. +- Reviewer: reject completion claims that lack structured evidence or lane-ownership boundaries. +- Coder: include compact-shape verification evidence from the assigned lane before signaling done. ## If Verification Fails