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

docs: structure planning and execution state

Browse Source
This commit is contained in:
alex wiesner
2026-03-13 21:36:55 +00:00
parent 9d7961f334
commit a3045255a7
6 changed files with 36 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
.config/opencode/commands/build.md
View File

@@ -7,13 +7,15 @@ model: github-copilot/gpt-5.4
Execute the latest approved plan for: $ARGUMENTS
1. Read the latest matching `plans/<slug>` note with `Status: approved`.
2. Create or update `executions/<slug>` with `Status: in_progress` before changing code.
3. Delegate implementation to `coder`, verification to `tester`, review to `reviewer`, and docs or memory updates to `librarian` where appropriate.
4. Builder owns commit creation during `/build`: create automatic commits at meaningful completed implementation checkpoints.
5. Reuse existing git safety rules and avoid destructive git behavior; do not add push automation.
6. If no new changes exist at a checkpoint, skip commit creation rather than creating empty or duplicate commits.
7. Follow the plan exactly. If the plan is contradictory, missing a dependency, or fails verification twice, stop, capture evidence, set the execution note to blocked, and send the work back to `planner`.
8. Before creating the final completion commit, clean up temporary artifacts generated during the build (e.g., scratch files, screenshots, logs, transient reports, caches). Intended committed deliverables are not cleanup targets.
9. Finish by creating a final completion commit when changes remain, then update the execution note to `Status: done` or `Status: blocked` and summarize what changed.
2. Create or update `executions/<slug>` with the structured sections defined in `AGENTS.md` (Plan, Execution State, Lane Claims, Last Verified State, Verification Ledger). Set `Status: in_progress` before changing code.
3. Before parallel fan-out, populate Lane Claims with owner, status, claimed files/areas, dependencies, and exit conditions. Overlapping claimed files/areas or sequential verification dependencies forbid parallel fan-out.
4. Delegate implementation to `coder`, verification to `tester`, review to `reviewer`, and docs or memory updates to `librarian` where appropriate.
5. Builder owns commit creation during `/build`: create automatic commits at meaningful completed implementation checkpoints.
6. Reuse existing git safety rules and avoid destructive git behavior; do not add push automation.
7. If no new changes exist at a checkpoint, skip commit creation rather than creating empty or duplicate commits.
8. Record verification evidence in the Verification Ledger using the compact shape (Goal, Mode, Command/Check, Result, Key Evidence, Artifacts, Residual Risk). Default to `smoke` for intermediate checkpoints; require `full` before final completion or setting status to `done`.
9. Follow the plan exactly. If the plan is contradictory, missing a dependency, or fails verification twice, stop, capture evidence, set the execution note to blocked, and send the work back to `planner`.
10. Before creating the final completion commit, clean up temporary artifacts generated during the build (e.g., scratch files, screenshots, logs, transient reports, caches). Intended committed deliverables are not cleanup targets.
11. Finish by creating a final completion commit when changes remain, then update Last Verified State and set the execution note to `Status: done` or `Status: blocked` and summarize what changed.
Automatic commits are required during `/build` as defined above.

7
.config/opencode/commands/continue.md
View File

@@ -8,5 +8,8 @@ Continue the highest-priority unfinished work for this repository.
1. Inspect basic-memory for incomplete work under `plans/`, `executions/`, `findings/`, and `decisions/`.
2. If the current primary agent is `planner`, resume the most relevant plan that is `Status: draft` or `Status: blocked` and drive it toward an approved spec.
3. If the current primary agent is `builder`, resume the most relevant execution note that is `Status: in_progress` or `Status: blocked`. If there is no approved plan, stop and hand the work back to `planner`.
4. Refresh the open findings ledger and update note statuses as you work.
5. Return the resumed slug, current status, next checkpoint, and any blocker.
4. When resuming a structured execution note, read Execution State and report: objective, current phase, next checkpoint, blockers, and last updated by. Check Lane Claims for active/blocked lanes and flag any claim conflicts (overlapping files/areas).
5. When the execution note is legacy or freeform (missing structured sections like Execution State or Lane Claims), degrade gracefully: read what exists, infer status from available content, and do not invent conflicts or synthesize missing sections without evidence.
6. When the execution note shows only `smoke` verification in the Last Verified State or Verification Ledger and a `full` verification step is still required before completion, surface this explicitly: report that full verification is pending and must run before the execution can be marked `done`.
7. Refresh the open findings ledger and update note statuses as you work.
8. Return the resumed slug, current status, next checkpoint, any blocker, any lane claim conflicts, and any pending full-verification requirement.

4
.config/opencode/commands/plan.md
View File

@@ -10,6 +10,8 @@ Create or update an execution-ready plan for: $ARGUMENTS
2. Use `researcher`, `explorer`, and `reviewer` as needed.
3. Write the canonical plan to basic-memory under `plans/<slug>`.
4. Include: objective, scope, assumptions, constraints, task breakdown, parallel lanes, verification oracle, risks, and open findings.
5. Set `Status: approved` only when `builder` can execute the plan without guesswork. Otherwise leave it blocked and explain why.
5. When parallelization or phased verification matters, define intended lanes with claimed files/areas, inter-lane dependencies, and verification intent (including `smoke` vs `full` mode where the distinction affects execution).
6. Ensure the plan gives builder enough information to create the structured `executions/<slug>` note without guessing lane ownership, claimed areas, or verification expectations.
7. Set `Status: approved` only when `builder` can execute the plan without guesswork. Otherwise leave it blocked and explain why.
Return the plan slug and the key execution checkpoints.