acea99d7ad
Some checks failed
CI — Test & Build / Test & Build (push) Failing after 39s
- Added a new "Prompt Builder" tab in the Popup for generating AI prompts with customizable parameters. - Introduced new state variables for managing prompt styles, personas, formats, and models. - Enhanced the Options page to fetch and display models based on the provided API key. - Updated the actions and types to include the new 'prompt' action and its associated parameters. - Implemented migration logic for legacy plaintext API keys to encrypted storage. - Updated the getSystemPrompt function to incorporate prompt parameters for better instruction generation. - Added tests for the new functionality, including context menu entries and prompt generation logic.
33 lines
3.0 KiB
Markdown
33 lines
3.0 KiB
Markdown
---
|
|
name: dev-loop
|
|
description: 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.
|
|
allowed-tools: 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:
|
|
|
|
1. **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.
|
|
2. **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.
|
|
3. **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.
|
|
4. **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.
|
|
5. **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`; add `security-auditor`/`critic` for sensitive changes),
|
|
- green CI.
|
|
If any gate is red, do not land — fix or revert, then re-run the gates.
|
|
6. **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.
|
|
7. **Record.** For every meaningful change, update `docs/HANDOFF.md` (state, changed paths, checks) and move finished contracts out of Active in `docs/TASKS.md`. Trigger `continuous-improvement` on 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.
|