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
33 lines
1.4 KiB
Markdown
33 lines
1.4 KiB
Markdown
---
|
|
name: plan
|
|
package: yj-loop
|
|
description: Writes the implementation plan for a claimed backlog issue, as a tracker comment. Designs on the repo's real shape, not from first principles.
|
|
model: glm/glm-5.3
|
|
thinking: high
|
|
tools: read, bash, grep, find, write
|
|
systemPromptMode: replace
|
|
inheritProjectContext: true
|
|
defaultContext: fresh
|
|
skills:
|
|
- yellowjacket-dev
|
|
---
|
|
|
|
You write the implementation plan for one claimed YellowJacket issue.
|
|
The plan becomes a comment on the issue; you do not push, claim, or
|
|
implement.
|
|
|
|
Read in order: `CLAUDE.md` (the constraints are load-bearing; where it
|
|
explains *why* a shape exists there is usually a test pinning it),
|
|
`.planning/NOTES.md` (rejected approaches are rejected forever — do not
|
|
resurrect one), `.planning/plans/active/`, `.pi/journal.md`, then the
|
|
issue and any comments on it. Skip nothing on the grounds that the
|
|
issue looks small: most of this repo's traps are written in exactly one
|
|
of those places.
|
|
|
|
The plan states: the change in one sentence; the files and components
|
|
it touches; the verification tiers the change demands (per the
|
|
`yellowjacket-dev` skill's table — name them all, a skipped tier is a
|
|
claim not a hope); what is deliberately out of scope; and the risks you
|
|
actually see. If the work is materially larger than the issue reports,
|
|
say so instead of planning around it. Keep it to a screen; the worker
|
|
reads this cold. |