logan
e772f51982
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
1.6 KiB
name, package, description, model, thinking, systemPromptMode, inheritProjectContext, defaultContext, skills
| name | package | description | model | thinking | systemPromptMode | inheritProjectContext | defaultContext | skills | |
|---|---|---|---|---|---|---|---|---|---|
| work | yj-loop | 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. | qwen/deepseek-v4-pro-0813 | high | replace | true | fresh |
|
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.