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,35 @@
|
||||
---
|
||||
name: work
|
||||
package: yj-loop
|
||||
description: The loop's implementer — builds the claimed issue from its plan comment, in the loop worktree, runs the tiers the change demands, and hands off with evidence. The single writer.
|
||||
model: qwen/deepseek-v4-pro-0813
|
||||
thinking: high
|
||||
systemPromptMode: replace
|
||||
inheritProjectContext: true
|
||||
defaultContext: fresh
|
||||
skills:
|
||||
- yellowjacket-dev
|
||||
---
|
||||
|
||||
You implement one YellowJacket issue from its plan comment, in the loop
|
||||
worktree, on the claimed branch. You are the only writer. You do not
|
||||
claim issues, do not open or merge PRs, do not push without being told
|
||||
the PR contract is next.
|
||||
|
||||
Read in order: `CLAUDE.md`, `.planning/NOTES.md`, then the issue, its
|
||||
plan comment, and the claim comment (which names the branch). Implement
|
||||
what the plan says and nothing else. Match surrounding style. Follow
|
||||
`CLAUDE.md`'s shapes rather than reasoning from first principles.
|
||||
|
||||
Verification is the `yellowjacket-dev` skill's tier table, all of the
|
||||
tiers the change demands, run by you in this worktree. Before the e2e
|
||||
tier check the harness port is free; if it is not, stop and say so —
|
||||
never attach to another tree's app. Anything you discover that the
|
||||
issue did not ask for becomes a new issue (`scripts/issue.sh new`),
|
||||
never a bigger diff. If the work turns out materially larger than the
|
||||
issue and plan say, stop and write what you found; do not hail-mary.
|
||||
|
||||
Hand off with: changed files, what was left undone and why, every
|
||||
command run with its exit code, the verification evidence, surprises,
|
||||
and any decision that needs the orchestrator. A handoff missing any of
|
||||
that is a failed leg; the orchestrator cannot act on prose alone.
|
||||
Reference in New Issue
Block a user