Amber Continuous Improvement
Workflow
- Read repository instructions, the operating manual, progress/handoff, feature state, active session, and continuous-improvement state.
- Inspect repo state and treat pre-existing dirty files as user-owned.
- Run
amber loop recommend --goal "<objective>" --target <repo>. Recommendations are read-only; they do not authorize execution.
- Select one coherent, high-value, low-risk slice and validate its plan/gate state.
- Before editing, write a contract:
- Objective.
- Files in scope.
- Files out of scope.
- Expected result.
- Verification evidence.
- Approval gates.
- Use
docs/wiki/agent/workflow-packets.md for ambiguous or multi-track work.
- Implement only the contracted slice through the governed delivery lifecycle; preserve approval, isolation, and ledger gates.
- Run a separate review pass and record real verification evidence.
- Update progress, handoff, feature evidence, and continuous-improvement state when project state changes.
On failure, record the negative evidence and next recoverable action. Do not select a second slice to hide an incomplete first slice.
Evidence order: repository state, recommendation, selected slice contract, approval/isolation decision, changed-file scope, verification output, review findings, ledger and handoff updates.
Safe Defaults
- Prefer small patches over broad rewrites.
- Do not overwrite user-authored files without explicit approval.
- Do not delete, deploy, publish, change secrets, change dependencies, create migrations, or perform destructive git operations without approval.
- Do not execute Dynamic Workflows, dispatch subagents, orchestrate worktrees, or route models from the V1 Amber Protocol boundary.
Result Note Template
Date:
Task:
Workflow:
Changed files:
Evidence:
Review findings:
Skipped checks:
Next candidate:
Loop Triage Compatible Output (when used inside a daily-triage loop)
When invoked as part of a loop (e.g. via /loop or amber loop run), prefer producing output in this structure so it can be directly merged into a STATE.md or loop ledger:
High-Priority Items
Watch Items
Noise / Ignore
State Updates
- Last run:
- Amber health score / doctor summary
- Candidate next actions (with links to commands)
This aligns Amber continuous improvement with loop-engineering loop-triage skill conventions while respecting Amber's governance and dry-run boundaries.
1---2name: amber-continuous-improvement3description: Use when continuing a repository improvement goal, running an automation wakeup, or selecting the next safe Amber-backed improvement slice.4---56# Amber Continuous Improvement78## Workflow9101. Read repository instructions, the operating manual, progress/handoff, feature state, active session, and continuous-improvement state.112. Inspect repo state and treat pre-existing dirty files as user-owned.123. Run `amber loop recommend --goal "<objective>" --target <repo>`. Recommendations are read-only; they do not authorize execution.134. Select one coherent, high-value, low-risk slice and validate its plan/gate state.145. Before editing, write a contract:15 - Objective.16 - Files in scope.17 - Files out of scope.18 - Expected result.19 - Verification evidence.20 - Approval gates.216. Use `docs/wiki/agent/workflow-packets.md` for ambiguous or multi-track work.227. Implement only the contracted slice through the governed delivery lifecycle; preserve approval, isolation, and ledger gates.238. Run a separate review pass and record real verification evidence.249. Update progress, handoff, feature evidence, and continuous-improvement state when project state changes.2526On failure, record the negative evidence and next recoverable action. Do not select a second slice to hide an incomplete first slice.2728Evidence order: repository state, recommendation, selected slice contract, approval/isolation decision, changed-file scope, verification output, review findings, ledger and handoff updates.2930## Safe Defaults3132- Prefer small patches over broad rewrites.33- Do not overwrite user-authored files without explicit approval.34- Do not delete, deploy, publish, change secrets, change dependencies, create migrations, or perform destructive git operations without approval.35- Do not execute Dynamic Workflows, dispatch subagents, orchestrate worktrees, or route models from the V1 Amber Protocol boundary.3637## Result Note Template3839```text40Date:41Task:42Workflow:43Changed files:44Evidence:45Review findings:46Skipped checks:47Next candidate:48```4950## Loop Triage Compatible Output (when used inside a daily-triage loop)5152When invoked as part of a loop (e.g. via `/loop` or `amber loop run`), prefer producing output in this structure so it can be directly merged into a `STATE.md` or loop ledger:5354### High-Priority Items5556- ...5758### Watch Items5960- ...6162### Noise / Ignore6364- ...6566### State Updates6768- Last run: <timestamp>69- Amber health score / doctor summary70- Candidate next actions (with links to commands)7172This aligns Amber continuous improvement with loop-engineering `loop-triage` skill conventions while respecting Amber's governance and dry-run boundaries.
Bandersnatch0x