chore(claude): track skills and add the pr-queue orchestration skill - #374
Conversation
.gitignore excluded everything under .claude/ except scripts/ and settings.json, so skills could not be committed at all. Cloud sessions start from a fresh clone and only see what is tracked, so a skill that lives on one machine is a skill the cloud agents do not have. The skill covers orchestrating this repo's open PR queue: where durable state lives (a per-session GitHub issue plus a status comment per PR, so context can be compacted without losing the queue), session tagging so concurrent orchestrator sessions stay separable, subscription handling, CodeRabbit triage, and subagent briefing. It also records the traps that have cost real time here: worktrees branch from main rather than the feature branch, bun run setup drifts the lockfile, get_status hides failing jobs that get_check_runs shows, and CodeRabbit's committable suggestions are not always correct even when the finding is. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 3 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Per-PR status comments were a second place for state to live, and a second place for it to go stale. The tracker issue is the single view, so each PR row carries what was going to be in the comment: unresolved findings and their disposition, and what is needed from the human on that PR. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The tag was defined as a slice of the session id and then written to a file inside a scratchpad path that already contains the session id, so reading it back told the orchestrator nothing it did not have. The file could only go stale or go missing. Derive the tag; find the tracking issue by searching for it rather than remembering its number. Subagents take the tag from their brief, which works whether or not they share the orchestrator's scratchpad. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The derived tag resolves searches but is unreadable aloud, so the issue title now carries a short word alongside it. The name needs no uniqueness or coordination, since the tag still does all the resolving. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The skill instructed agents to follow CLAUDE.md while carrying eleven em dashes itself, which cost it standing on the point. Commit messages had held to rule 15 all along; the prose had not, and the tracker issue was worse than the skill. Adds the rule explicitly, since the orchestrator writes far more prose than a normal session and rule 15 lists commits, PR descriptions and docs without naming issue bodies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 participants
Why this touches .gitignore
.gitignoreexcluded everything under.claude/exceptscripts/andsettings.json, so skills could not be committed at all, and none were. Cloud sessions start from a fresh clone and see only what is tracked, so a skill that lives on one machine is a skill the cloud agents do not have. This adds!/.claude/skills/.The skill
.claude/skills/pr-queue/SKILL.mdcovers orchestrating the open PR queue, written from what this repo actually does rather than generic advice.Where state lives. Not in the repo. A per-session GitHub issue holds queue-level state (PR table, decisions waiting, parked questions) and each PR carries one status comment edited in place. That way an orchestrator's context can be compacted without losing track of what is in flight, what was already declined and why, and what is waiting on a human.
Session tagging. Several orchestrator sessions can run at once, so each owns a tag derived from its session id and stamps it on every artifact it creates. One search resolves a whole session's work.
Triage rules. Verify every CodeRabbit finding against current code before acting, and reply with evidence on every decline. Recorded because the false-positive rate is real: of 8 findings on #368, 3 were wrong or out of scope, and one that was correct came with a suggested diff that would have disabled the timeout it was fixing.
Traps that have cost time here. Agent worktrees branch from
mainrather than the feature branch.bun run setupdrifts the lockfile under bun 1.3.x.get_statusshows only CodeRabbit and has reported green over two failing jobs thatget_check_runsshowed. Migrations collide silently because the filenames differ.Scope
Documentation and one
.gitignoreline. No source, build, or CI changes.pr-queue session pq-db6c36c3Generated by Claude Code