Menu
Use when implementing a fix for a known GitHub issue end-to-end on the Breeze repo — "work on issue
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | issue-to-pr |
| description | Use when implementing a fix for a known GitHub issue end-to-end on the Breeze repo — "work on issue |
Execution runbook that carries one already-chosen GitHub issue from claim to
a reviewed, open PR. Triage already happened (see gh-queue); this skill runs
after the decision to work an issue is made.
Repo: LanternOps/breeze. Two hard boundaries: the worker never merges and
the worker never closes the issue — those stay the user's call.
issue-fixer agent picking up a number.gh-queue.github-issues skill. Follow it; don't restate it.digraph issue_to_pr {
"Read full issue + comments" [shape=box];
"Eligible?" [shape=diamond];
"ABORT — report back" [shape=box];
"Assign to self" [shape=box];
"Worktree off fresh main" [shape=box];
"Fix (debug/brainstorm)" [shape=box];
"Verify: tests + typecheck" [shape=box];
"Commit / push / PR (Closes #N)" [shape=box];
"/pr-review-toolkit:review-pr" [shape=box];
"Findings?" [shape=diamond];
"Comment: what the review ran" [shape=box];
"STOP — hand off (no merge, no close)" [shape=doublecircle];
"Read full issue + comments" -> "Eligible?";
"Eligible?" -> "ABORT — report back" [label="no"];
"Eligible?" -> "Assign to self" [label="yes"];
"Assign to self" -> "Worktree off fresh main";
"Worktree off fresh main" -> "Fix (debug/brainstorm)";
"Fix (debug/brainstorm)" -> "Verify: tests + typecheck";
"Verify: tests + typecheck" -> "Commit / push / PR (Closes #N)";
"Commit / push / PR (Closes #N)" -> "/pr-review-toolkit:review-pr";
"/pr-review-toolkit:review-pr" -> "Findings?";
"Findings?" -> "Fix (debug/brainstorm)" [label="yes, address"];
"Findings?" -> "Comment: what the review ran" [label="clean"];
"Comment: what the review ran" -> "STOP — hand off (no merge, no close)";
}
If invoked with a specific issue number, skip to step 1. If asked to "find something to work on" / "grab an issue off the backlog", select one yourself:
# Open issues with the signals needed to rank them.
gh issue list --repo LanternOps/breeze --state open --limit 60 \
--json number,title,assignees,labels,createdAt,comments
Rank candidates, best first. Prefer an issue that is:
Skip (don't even open a worktree):
tracking/epic/meta, needs-design/question/discussion/RFC.ci-red, broad "X is broken on main") unless explicitly asked.Then run the step 1 guard on your top candidate — that's the real gate (it catches already-shipped fixes and in-flight PRs that ranking can't see). If the top candidate aborts on the guard, move to the next candidate; repeat until one passes or the list is exhausted. Report which issues you considered and why you skipped each — don't silently pick one and hide the rest.
When selecting several to fan out, cap the count and state the cap.
gh issue view N --repo LanternOps/breeze --comments \
--json number,title,body,state,assignees,labels,comments
# PRs that reference it — ANY state, not just open (a merged/closed PR may have
# already shipped the fix; --state open would never show it).
gh pr list --repo LanternOps/breeze --state all --search "N in:body" \
--json number,title,state,headRefName,mergedAt
Read the whole issue and every comment. ABORT and report back (do not start work) if any of these is true:
@me login, resolved with
gh api user --jq .login — not a separate agent identity. An issue
assigned to that account is "assigned to you" and is eligible (work it);
only an issue assigned to a different login is "someone else" → abort. If
you're a subagent, you have no GitHub identity of your own, so never read the
operator's own assigned issues as belonging to a third party.main
saying "fixed in #NNN" / "merged to main") → the fix likely already
shipped and the issue is open only awaiting reporter confirmation. Verify
against origin/main before concluding either way — a gh pr list --state open
miss does NOT mean no fix exists. Don't open a duplicate no-op PR.Aborting is a success, not a failure. Report why so the orchestrator/user can decide. Guessing past a guard wastes a worktree and a review cycle.
gh issue edit N --repo LanternOps/breeze --add-assignee @me
REQUIRED SUB-SKILL: Use superpowers:using-git-worktrees. The main working
copy at /Users/toddhebebrand/breeze is shared across sessions and drifts —
verify your base is fresh main before branching (a stale base has nearly
shipped dozens of unrelated commits in a PR).
Spawn-location trap (read this): When an orchestrator fans you out, your
CWD is very likely already inside an existing worktree under
.claude/worktrees/ that belongs to a different task. That is NOT your
workspace. Do not edit there, and do not reach back into the shared
/Users/toddhebebrand/breeze checkout (it may be on a stale branch). Always
git fetch origin main, then create your own new worktree off
origin/main, cd into it, and confirm git rev-parse HEAD equals
origin/main before you branch. Editing the spawn worktree or the shared
checkout has silently reverted other in-flight PRs' files.
Branch naming (AGENTS.md — no codex/ / claude/ prefixes):
fix/N-short-slug, feat/N-short-slug, docs/short-slug, chore/short-slug.
Fresh worktrees need pnpm install and the gitignored .env.test symlink —
without it RLS forge tests pass vacuously on a BYPASSRLS connection. Prefix
node-pinned commands: PATH=$HOME/.nvm/versions/node/v22.20.0/bin:$PATH.
superpowers:systematic-debugging (find root cause before patching).superpowers:brainstorming first if the issue left design open.CLAUDE.md (policies in the same migration, idempotent, never edit a
shipped migration). Touching the Go agent → write to agent/, not apps/agent/.REQUIRED SUB-SKILL: breeze-testing for what to cover.
pnpm exec vitest run <path>.npx tsc --noEmit (and astro check if .astro
changed — plain tsc skips Astro files).cd agent && go test -race ./internal/<pkg>/....Do not proceed to the ready comment on red tests. REQUIRED SUB-SKILL:
superpowers:verification-before-completion.
Use commit-commands:commit-push-pr (or do it by hand). The PR body must
include Closes #N. PR title follows fix(scope): summary (#N) /
feat(scope): summary (#N). Required trailers:
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>🤖 Generated with [Claude Code]… line.Run /pr-review-toolkit:review-pr on the PR. Address every real finding (loop
back to step 4 → re-verify). Re-run review if you made non-trivial changes.
Assignee stays you. Post a comment on the PR (not the issue) in the
bold-section style (github-issues / comment-style conventions). The comment's
job is to record what the last review run was and its outcome — NOT a
generic "ready for review" banner.
**Review run:** /pr-review-toolkit:review-pr (code-reviewer, silent-failure-hunter, pr-test-analyzer)
**Findings:** 2 raised → both addressed in <sha>; 0 outstanding.
**Tests:** apps/api affected suite green (`vitest run routes/foo.test.ts`, 14 passed); `tsc --noEmit` clean.
**Status:** review-clean, awaiting maintainer merge.
If review surfaced nothing, say that explicitly ("0 findings") rather than omitting the line — a missing line reads as "didn't run it."
Report the PR number + a one-line summary to the orchestrator/user. Then stop.
The worker does NOT merge and does NOT close the issue. Merge (--admin,
gated on green required checks) and closure (after the reporter/user verifies)
are the user's judgment calls — see the merge/hold rules. The issue stays
open and assigned to you until then.
@me account is not poaching — work it; see step 1.)main too. Open-only is a blind spot.origin/main.| Rationalization | Reality |
|---|---|
| "A commit means it's done, close it." | A commit isn't verification. Reporter/user closes. |
| "Green CI means I can merge." | Merge is gated on the user's hold/judgment rules, not just CI. |
| "Aborting wastes the dispatch." | Aborting on a guard is the correct, cheap outcome. Guessing is expensive. |
| "Full suite is red so my change is broken." | The full API suite is flaky in parallel — verify via affected files single-fork. |
To work several issues at once, the in-session agent acts as orchestrator:
Decide the issue numbers BEFORE dispatch — never let multiple workers self-select in parallel. Each worker's step-0 selection ranks the backlog the same way and claims aren't visible at selection time, so parallel self-selecting agents converge on the same top issue and open duplicate PRs (observed: 3 agents → PRs #1917/#1918/#1919, all on #1896). Get a distinct set one of two ways:
gh issue edit <N> --add-assignee @me)
so the set is reserved. Only then dispatch.Any orchestrator-level eligibility pre-check has the same blind spot as the
worker's: gh pr list --state open won't reveal an already-merged fix, so
don't pre-declare an issue "eligible" on that basis — the worker's full guard
(comments + --state all + origin/main) is the real gate.
REQUIRED SUB-SKILL: superpowers:dispatching-parallel-agents — spawn one
issue-fixer agent per already-chosen number, each in its own worktree
(isolation prevents branch/DB collisions; see the worktree skill). Every agent
gets a concrete number — none self-selects.
Each agent runs this runbook independently and returns its PR number (or its
abort reason). A worker that finds its handed number already assigned to @me
(because the orchestrator pre-claimed it) treats that as eligible — that's the
reservation working, not a poach.
Collect the results into one summary table for the user. The orchestrator does not merge or close either — same boundary applies.
Do not auto-expand the list beyond what the user named. If you self-selected
from a label, log/state the cap and which issues were dropped.
Anti-pattern (do not do this): dispatching 2+
issue-fixeragents that each run step-0 selection, trusting a "skip already-claimed issues" instruction to keep them apart. Selection precedes any visible claim, so the guard can't see a sibling's pick — they collide. Distinctness is the orchestrator's job, settled before dispatch.
Use when cutting, shipping, or announcing a Breeze RMM release — "cut a release", "ship vX.Y.Z", "release notes for X", "what do self-hosters need to know", "draft the release announcement", "do the release write-up". Orchestrates the whole release-comms pass: a self-hoster-focused GitHub Release body (breaking changes, required env vars, migrations), then /update-breeze-release-notes (marketing site), /update-breeze-docs (technical docs), and a Discord announcement. Also covers the post-release deploy + agent-fleet promote steps that the tag alone does NOT do.
Quick reference for the Breeze RMM Go agent architecture, commands, configuration, build process, and data flows. Use when working on agent code, debugging agent issues, or understanding how the agent communicates with the API.
Use when reviewing, triaging, or managing the incoming GitHub backlog on the Breeze repo — PRs, Discussions, AND Issues. Stateful manager with a shared queue file, contributor profiles, parallel pr-review-toolkit dispatch, GraphQL discussion recipes, comment-style conventions, and session-log bookkeeping. Auto-detects object type from the request; bare invocation triages all three. Triggers on "review PR", "PR queue", "triage PRs/discussions/issues", "review discussions", "check open issues", "what's waiting on me", "gh queue", "repo queue", "review
Comprehensive security review for Breeze RMM. Multi-tenant isolation audit, authentication/authorization hardening, public exploitability assessment, input validation, rate limiting, WebSocket security, secrets management, and OWASP top-10 coverage. Use when reviewing code for security issues, hardening endpoints, auditing tenant isolation, checking for vulnerabilities, or before deploying security-sensitive changes.
Use when debugging agent issues, investigating agent errors, checking agent connectivity, or reviewing agent diagnostic logs. Use when asked to check what an agent is doing or why it is failing.
Quick reference for the Breeze RMM AI Agent system architecture, MCP tools, streaming chat, cost tracking, guardrails, and MCP server. Use when working on AI features, debugging chat issues, adding new tools, or understanding the AI data flow.