444060c3eb
- Introduced `critic`, an independent adversarial reviewer for security and correctness. - Added `fable-orchestrator` to manage task routing and verification. - Implemented `gauntlet-critic` for fresh-context evaluation of gauntlet rounds. - Created `planner` for generating executable implementation plans with dependencies. - Developed `security-auditor` for application security reviews and audits. - Established `system-steward` to improve agent prompts and skills based on verified failures. - Added `dev-loop` skill for autonomous development loops over repositories. - Implemented `gauntlet-loop` skill for iterative quality benchmarking against reference standards. - Updated project settings to utilize the new orchestrator agent. - Created documentation for `GAUNTLET.md`, `PROGRESS.md`, and `REFERENCE_BAR.md` to track project status and quality benchmarks. - Added detailed prompting style guide to enhance understanding of prompt patterns and agentic loops.
3.0 KiB
name, description, allowed-tools
| name | description | allowed-tools |
|---|---|---|
| dev-loop | Run a bounded autonomous development loop (Steinberger-style) over one or more repositories or task queues — triage, pick the highest-value bounded task, land it only behind full gates, and stop cleanly. Use for continuous maintenance sessions or scheduled background dev runs, not one-off edits. | Read Grep Glob Bash Write Edit Skill Agent |
Operate a controlled maintenance loop that makes steady, verified progress without human babysitting — and without ever landing unverified or unauthorized work. Fable owns routing and acceptance; this skill is the loop discipline. Adapt the cadence to the runtime: a live session iterates continuously; a scheduled run (see the schedule skill) executes one pass per trigger.
Loop
While maintenance is active, on each cycle:
- Triage. List candidate work across the repositories/queues in scope (open tasks in
docs/TASKS.md, failing checks, TODOs, dependency alerts, review comments). Read each repository's latest state before acting. - One thread per repository. Reuse a single working context/branch per repository; do not fragment a repo across parallel threads. Do not interrupt coherent active work already in progress — pick it up where it is or leave it alone.
- Pick one bounded task. Choose the highest value-per-effort item that fits within granted permissions and a single cycle. Write or update its contract in
docs/TASKS.md. If it needs a decision you can't make, mark it decision-ready and move on. - Execute within permission. Delegate implementation to
builder(or do the minimal change) on the named files only. Never expand scope, and never take destructive or external actions without explicit authorization. - Landing gates — all required before anything lands:
- tests written/updated and passing,
- live proof the change does what it claims (run it, not just read it),
- independent review (
verifier; addsecurity-auditor/criticfor sensitive changes), - green CI. If any gate is red, do not land — fix or revert, then re-run the gates.
- Escalate, don't guess. Stop and surface anything touching product direction, access/permissions, security, cost, or irreversible action. Leave it decision-ready with the options laid out.
- Record. For every meaningful change, update
docs/HANDOFF.md(state, changed paths, checks) and move finished contracts out of Active indocs/TASKS.md. Triggercontinuous-improvementon a verified failure.
Stop condition
End the run when every in-scope item is one of: landed, decision-ready (blocked on the user), blocked (external dependency), or no work left. Do not invent work to stay busy — an idle, clean stop is a success. Report a one-screen summary: landed, awaiting-decision, blocked, and next cadence.
Scheduling
To run this unattended, pair it with the schedule skill (e.g. wake on a cron cadence, execute one pass, stop). Keep the per-run budget explicit (max tasks/turns) so a scheduled run can't sprawl.