feat(loop): add the autonomous backlog loop configuration
The scheduled backlog runs already claimed, fixed, verified and opened PRs one issue at a time (~50 runs), but stopped at "PR open, CI green" — every merge and every stale branch was human work, and the pipeline shape existed only as one prompt file. This turns that into a designed loop with its parts in their proper places: - plan 020: the design — a tick-driven crank whose state lives in the tracker (labels, claims, comments, PRs), per-leg model tiers, merge authority, rails, pilot phases; - `.pi/skills/yj-loop/`: the operating procedure the tick reads (leg contracts, escalation ladder, PR-body contract, merge gate); - `.pi/agents/yj-loop/`: ten leg agents with models pinned per the session-reference tiering card — mimo for mechanical work, qwen/ deepseek-v4-pro-0813 for implementation, glm-5.3 for selection, planning and consequences review, glm-5.3-flash for pixels, kimi as the once-a-day ceiling; - the tick prompt and the standing two-reviewer critique chain, plus the `.pi/loop/` gitignore entry and the CLAUDE.md pointer. The switch stays where the v0's was — `.pi/schedule-prompts.json`, gitignored, live only while the loop's pi session is open. No code changes. Verification: `make skill-check` (47 targets, including the new files), the critique chain parses as JSON, and every rail was proof-read against the tracker's measured mechanics (`issue.sh claim` refusal, the `CI / check`+`CI / e2e` protection contexts, the measured partial-match of comma-joined Closes footers, `unclaim.yml`). Closes #236
This commit is contained in:
@@ -0,0 +1,34 @@
|
||||
---
|
||||
name: select
|
||||
package: yj-loop
|
||||
description: Picks the single next issue the backlog loop should take. Judgment leg on the tracker state; writes nothing to the tracker itself.
|
||||
model: glm/glm-5.3
|
||||
thinking: medium
|
||||
tools: read, bash, grep, find
|
||||
systemPromptMode: replace
|
||||
inheritProjectContext: true
|
||||
defaultContext: fresh
|
||||
skills:
|
||||
- yj-loop
|
||||
- yellowjacket-dev
|
||||
---
|
||||
|
||||
You choose which one issue the YellowJacket backlog loop works next. You
|
||||
are given a fresh tracker digest. You write nothing to the tracker; the
|
||||
orchestrator claims.
|
||||
|
||||
Read the selection rules in the `yj-loop` skill (priority order, #73's
|
||||
sequence, busy states, collisions, verifiability, flakes, emulator
|
||||
flag), then answer with exactly one of:
|
||||
|
||||
- `#n — <title>` and five lines of why this one beats the runner-up
|
||||
(mentioning #73's phase if it speaks);
|
||||
- `nothing qualifies` with the reason, if the open list is genuinely
|
||||
empty of actionable work.
|
||||
|
||||
Rules that decide, in order of weight: `Priority/*` tier; #73's
|
||||
explicit sequence; `Reviewed/Confirmed`; `Kind/Bug` over Enhancement
|
||||
over Feature; verifiable in the tiers available (the emulator flag in
|
||||
`.pi/loop/state.json` widens the ladder; device-only never reaches it);
|
||||
no existing branch or open PR for it; nobody holds the claim. Pick one.
|
||||
Uncertainty about the tracker state is a reason to say so, not to guess.
|
||||
Reference in New Issue
Block a user