changes
This commit is contained in:
@@ -9,7 +9,10 @@ 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. 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`.
|
||||
5. Finish by updating the execution note to `Status: done` or `Status: blocked` and summarizing what changed.
|
||||
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. 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.
|
||||
|
||||
Do not create a commit unless the user explicitly asks.
|
||||
Automatic commits are required during `/build` as defined above.
|
||||
|
||||
Reference in New Issue
Block a user