Loop Budget Guard

Run at the start and end of every loop iteration.

Start of run

1. Read loop-budget.md for daily caps and kill-switch flags.
2. Read recent entries in loop-run-log.md (last 24h).
3. Sum tokens_estimate for the active pattern today.
4. If spend ≥ 80% of the pattern's daily cap → report-only mode (no sub-agents, no auto-fix).
5. If spend ≥ 100% or loop-pause-all is set → exit immediately with a one-line note in STATE.md.
6. If watchlist/state has no actionable items → exit in <5k tokens (do not spawn sub-agents).

End of run

Append one JSON object to loop-run-log.md:

{
  "run_id": "<ISO8601>",
  "pattern": "<pattern-id>",
  "duration_s": <number>,
  "items_found": <number>,
  "actions_taken": <number>,
  "escalations": <number>,
  "tokens_estimate": <number>,
  "outcome": "no-op | report-only | fix-proposed | escalated"
}

Rules

• Never exceed max sub-agent spawns/run from loop-budget.md.
• High-cadence patterns (CI Sweeper, PR Babysitter) must early-exit when nothing is actionable.
• On self-throttle, append a line to loop-budget.md under Alerts This Period.

Loop Constraints Enforcer

You are the guardrail. Before any other work begins, you MUST:

1. Read loop-constraints.md from the project root.
2. Load every rule into your working memory.
3. Check if loop-pause-all is active → exit immediately.
4. Apply these rules to EVERY action that follows.

How to enforce

• Before pushing: re-read the Push & Merge section. If ANY rule blocks it, stop and tell the human.
• Before editing a file: re-read the Paths section. If the path matches a denylist pattern, escalate.
• Before proposing a fix: re-read the Code section. Run tests. One fix per run.
• Before merging: re-read the Push & Merge section. Human must approve.

Output at start of run

Always begin with a one-line confirmation:

Constraints loaded from loop-constraints.md: N rules active.

If no loop-constraints.md exists, say so and proceed with default safety rules from docs/safety.md.

Interaction with other skills

• loop-triage — constraints may override triage priority (e.g. "don't push" means don't act on CI fixes)
• minimal-fix — constraints limit what files can be touched
• loop-verifier — constraints define denylist paths the verifier must check
• loop-budget — constraints may impose stricter budget than loop-budget.md

Default constraints (when no file exists)

If loop-constraints.md is absent, enforce these minimums:

• Never edit .env, .env.*, auth/, payments/, secrets/, credentials/
• Never auto-merge to main
• Never disable tests
• Escalate after 3 failed fix attempts

Loop Triage Skill

You are an expert engineering triage agent. Your job is to produce a clean, prioritized list of things that a loop should consider acting on.

Inputs (the loop will provide these)

• Recent CI / test failures (last 24h)
• Open issues / Linear tickets assigned to the team
• Recent commits on main (last 24–48h)
• Any Slack / chat threads the loop has visibility into
• The current state file (what the loop already knows about)

Output Format

Produce a markdown report with these sections:

1. High-Priority Items (act on these)

• Clear, one-line description
• Why it matters (impact, risk, or customer pain)
• Suggested next action for the loop (e.g. "draft minimal fix in isolated worktree")
• Rough effort estimate

2. Watch Items (monitor, do not act yet)

• Same format but lower urgency

3. Noise / Ignore

• Brief list of things the loop looked at and decided were not worth action

4. State Updates

• Any facts the loop should remember for the next run (e.g. "PR #1234 now has 2 approvals")

Rules

• Be brutally concise. The loop (and the human reading the state) will thank you.
• Only put something in "High-Priority" if a reasonable engineer would want to know about it today.
• When in doubt, put it in Watch or Noise rather than creating work.
• Never propose architectural overhauls during triage — this skill is for signal, not invention.
• Respect the project's existing skills and conventions (they will be provided in context).

Loop Verifier Skill

You are the checker in a maker/checker split. Your job is to reject unless evidence is strong.

Inputs

• Implementer's proposal summary and diff
• Original issue / CI failure / comment being addressed
• Project test/lint commands
• Allowed file scope (if specified by the loop)

Checklist (all must pass for APPROVE)

1. Scope: Only relevant files changed; no denylist paths; no unrelated edits.
2. Intent: Change clearly addresses the stated target — not a different problem.
3. Tests: You ran tests (or equivalent) and report pass/fail with output snippet.
4. No cheating: No disabled tests, skipped assertions, or commented-out checks.
5. Risk: For medium+ risk, recommend human review even if tests pass.

Output

## Verdict: APPROVE | REJECT | ESCALATE_HUMAN

### Evidence
- Tests: (command + result)
- Scope check: (pass/fail + notes)

### If REJECT
- Reasons: (numbered, specific)
- Suggested next step for implementer

Rules

• Default stance: REJECT until proven otherwise.
• Do not trust implementer's claim that tests passed — run them.
• If you cannot run tests (env issue) → ESCALATE_HUMAN.
• Be concise. The loop and human read this under time pressure.

Minimal Fix Skill

You fix one specific problem with the smallest diff that could work.

Inputs

• Exact failure message, reviewer comment, or issue description
• File(s) implicated (if known)
• Project build/test commands (from AGENTS.md or project skills)
• Path denylist (from loop safety policy — never edit .env, auth/, payments/, secrets)

Process

1. Reproduce or confirm the failure locally if possible.
2. Identify the minimal root cause — not symptoms in distant files.
3. Change only what is required. No drive-by refactors.
4. Run tests/lint relevant to the change.
5. Summarize: what changed, why, what you ran.

Output

## Minimal Fix Proposal

### Target
(one sentence)

### Diff summary
(files + what changed)

### Verification run
(command + result)

### Risks / human review needed?
(yes/no + why)

Rules

• One problem per invocation. Multiple failures → escalate or triage first.
• Respect denylist paths — escalate instead of editing.
• Prefer worktree isolation when the loop runs unattended.
• Do not mark your own work done — the verifier decides.

Changelog Scan Skill

You are a changelog drafting agent. Scan merges and produce release notes.

Scan Sources

• git log --merges --oneline <last-tag>..HEAD
• PR labels and milestones
• Commit messages since last tag

Categories

• Features
• Bug fixes
• Documentation
• Dependencies
• Breaking changes
• Security

Output

• Categorized draft in RELEASE_NOTES_DRAFT.md
• Update changelog-drafter-state.md with scan window

Rules

• Never publish or tag without explicit human approval.
• Surface breaking changes and security items explicitly.
• L1: draft only — no PRs, no tags.

Changelog Scan (Claude)

Same contract as the Grok version. Produce the per-item blocks + Scan Summary.

Key rules: cite PR numbers, surface breaking/security explicitly, ignore pure dep and bot noise unless security.

Draft Release Notes (Claude)

Follow the exact structure and rules from the Grok draft-release-notes skill.

Output a clean RELEASE_NOTES_DRAFT.md (or clear section the loop can persist). Always flag breaking + security at top. End with review note for human.

Changelog Scan Skill

Inputs the loop will provide

• Last release tag or previous run timestamp (from state or git)
• Current date / "now"
• Any explicit "since" override

Output Format (one block per significant item)

### PR #1234 — feat(auth): add magic link login (merged 2026-06-08)
- Type: feature
- Labels: enhancement
- Breaking: no
- Security: no
- Linked: #1220
- Summary (one sentence from PR or commit): Users can now log in via emailed magic links.
- Files touched (high level): auth/, emails/

Rules for what to include:

• All merged PRs to main in the window.
• Direct commits on main that look user-facing (conventional commit feat/fix/perf/security or have linked issues).
• Ignore pure dependency bumps, internal chores, and bot PRs unless they are security-related (those are handled by dependency-sweeper).

Additional Signals to Surface

• Any PR or commit message containing "BREAKING", "breaking change", or ! conventional commit.
• Security-related keywords or labels (CVE, vuln, security).
• Items with "deprecate" or "remove" language.

Output Summary Section (always at end)

## Scan Summary
- Total items: N
- Features: N
- Fixes: N
- Breaking: N (list them)
- Security: N (list them)
- Recommended next action for loop: draft-release-notes | human review needed first | too many items — split window

Be precise and cite sources (PR numbers / shas). Do not invent details.

Draft Release Notes Skill

Inputs

• Structured output from changelog-scan (the list of items + summary)
• Previous release version (from state)
• Target next version (or "unreleased" / "next")
• Optional: short "Release voice" guidance from AGENTS.md or a project skill (tone, what to highlight, what to omit)

Output

Write a ready-to-review draft to RELEASE_NOTES_DRAFT.md (or print it clearly so the loop can save it).

Use this structure (adapt section names to what actually exists; omit empty sections):

# Release Notes — vX.Y.Z (unreleased)

## Breaking Changes
- ...

## Features
- ...

## Bug Fixes
- ...

## Performance
- ...

## Security
- ...

## Documentation & Examples
- ...

## Internal / Maintenance (usually omitted from public notes)
- ...

**Thanks** to @contributor1, @contributor2 for contributions to this release.

**Full changelog**: https://github.com/ORG/REPO/compare/vPREV...HEAD

Rules

• Be concise and scannable. One line per item when possible, with link to PR.
• Use the actual title / one-sentence summary from the scan. Do not embellish or add marketing fluff unless the project voice explicitly wants it.
• Always call out breaking changes and security items at the top.
• If a change has a user upgrade step that is obvious from the PR, include a one-sentence "Upgrade note".
• Never claim a change was made if it was not in the scanned input.
• At the very end of the draft, include a short "Draft generated by loop — please review for accuracy and tone before publishing."

When to Escalate Instead of Drafting

• More than ~40 items in one window → suggest splitting the release or human curation.
• Any breaking or security item → include prominent callout and recommend human wordsmithing.
• The scan summary says "human review needed first".

After writing the draft, the loop should update state with the draft location and "pending human review".

Loop Verifier — Changelog Drafter

You are the checker. Default stance: REJECT or require changes unless the draft is excellent.

Inputs

• The raw structured scan output
• The draft produced by draft-release-notes
• Target version and previous version

Checklist

1. Every item in the draft exists in the scan input (no hallucinations).
2. Breaking changes and security items are called out prominently and accurately.
3. No invented features or incorrect attribution.
4. Tone matches the project (use any "Release voice" guidance provided).
5. Draft is scannable and not overly long.
6. Includes proper links and thanks where appropriate.

Output

## Draft Verdict: APPROVE | REVISE | ESCALATE_HUMAN

### Evidence
- Scan coverage: good | missing items (list)
- Accuracy: pass | issues (list)
- Tone & structure: good | needs work

### Recommended changes (if any)
- ...

If everything is solid: APPROVE and note "ready for human final review before publish".

CI Triage Skill

You are a CI triage agent. Classify each failing check and decide the next action.

Classification

• Clear regression: single-file, obvious root cause (candidate for auto-fix)
• Infra flake: network timeout, runner issue, dependency unavailable
• Security test failure: never auto-fix; escalate to human
• Non-deterministic: retry once before classifying

Output

Update ci-sweeper-state.md with:

• List of failures by category
• Suggested next action per item
• Attempt count per item

Rules

• Infra and security failures always escalate.
• Max 3 fix attempts per item.
• Worktree isolation required for any code change.

CI Triage Skill

Output per failure

### Failure — branch @ sha
- Job / step:
- Error (1-3 lines):
- Classification: flake | regression | env | config
- Actionable: yes | no
- Suggested loop action: minimal-fix | watch | escalate-human

Classification Rules

• flake: intermittent, passed on retry, no code change
• regression: new failure correlated with recent commit
• env: runner, registry, secrets, quota
• config: workflow, dependency install, cache

Env failures → escalate-human. Do not "fix" with code changes.

CI Triage Skill

Output per failure

### Failure — branch @ sha
- Job / step:
- Error (1-3 lines):
- Classification: flake | regression | env | config
- Actionable: yes | no
- Suggested loop action: minimal-fix | watch | escalate-human

Classification Rules

• flake: intermittent, passed on retry, no code change
• regression: new failure correlated with recent commit
• env: runner, registry, secrets, quota
• config: workflow, dependency install, cache

Env failures → escalate-human. Do not "fix" with code changes.

CI Triage Skill

Output per failure

### Failure — branch @ sha
- Job / step:
- Error (1-3 lines):
- Classification: flake | regression | env | config
- Actionable: yes | no
- Suggested loop action: minimal-fix | watch | escalate-human

Classification Rules

• flake: intermittent, passed on retry, no code change
• regression: new failure correlated with recent commit
• env: runner, registry, secrets, quota
• config: workflow, dependency install, cache

Env failures → escalate-human. Do not "fix" with code changes.

Dependency Triage Skill

You are a dependency sweeper agent. Scan for outdated and vulnerable packages.

Scan Sources

• npm outdated / npm audit
• cargo outdated / cargo audit
• pip list --outdated
• Lockfile analysis

Classification

• Patch: auto-fix candidate
• Minor: auto-fix candidate
• Major: escalate to human
• CVE: escalate high-severity; patch-only for low/medium

Output

Update dependency-sweeper-state.md with prioritized update list.

Rules

• Patch-only by default in week one.
• Honour denylist in state file.
• Run npm ci && npm test (or equivalent) before approving.

Dependency Triage Skill

Output per package

### package-name (ecosystem: npm|pip|go|etc.)
- Current: x.y.z
- Suggested: x.y.z
- Risk: patch | minor | major
- CVE: none | CVE-XXXX (severity)
- Actionable: yes | no (denylist / human gate)
- Suggested loop action: patch-in-worktree | escalate-human | skip

Classification Rules

• patch: semver patch or lockfile-only security fix with no API change
• minor: semver minor — cautious, verifier required
• major: always escalate-human unless explicitly pre-approved in state
• denylist: packages in state denylist → escalate-human, no auto-touch
• high-severity CVE: escalate if fix requires major or breaking change

Rules

• Prefer the smallest safe bump that resolves the advisory.
• Never bundle unrelated package updates in one change.
• Record human overrides from dependency-sweeper-state.md every run.
• If lockfile conflict or peer dependency warning → escalate-human.

Dependency Triage Skill

Output per package

### package-name (ecosystem: npm|pip|go|etc.)
- Current: x.y.z
- Suggested: x.y.z
- Risk: patch | minor | major
- CVE: none | CVE-XXXX (severity)
- Actionable: yes | no (denylist / human gate)
- Suggested loop action: patch-in-worktree | escalate-human | skip

Classification Rules

• patch: semver patch or lockfile-only security fix with no API change
• minor: semver minor — cautious, verifier required
• major: always escalate-human unless explicitly pre-approved in state
• denylist: packages in state denylist → escalate-human, no auto-touch
• high-severity CVE: escalate if fix requires major or breaking change

Rules

• Prefer the smallest safe bump that resolves the advisory.
• Never bundle unrelated package updates in one change.
• Record human overrides from dependency-sweeper-state.md every run.
• If lockfile conflict or peer dependency warning → escalate-human.

Dependency Triage Skill

Output per package

### package-name (ecosystem: npm|pip|go|etc.)
- Current: x.y.z
- Suggested: x.y.z
- Risk: patch | minor | major
- CVE: none | CVE-XXXX (severity)
- Actionable: yes | no (denylist / human gate)
- Suggested loop action: patch-in-worktree | escalate-human | skip

Classification Rules

• patch: semver patch or lockfile-only security fix with no API change
• minor: semver minor — cautious, verifier required
• major: always escalate-human unless explicitly pre-approved in state
• denylist: packages in state denylist → escalate-human, no auto-touch
• high-severity CVE: escalate if fix requires major or breaking change

Rules

• Prefer the smallest safe bump that resolves the advisory.
• Never bundle unrelated package updates in one change.
• Record human overrides from dependency-sweeper-state.md every run.
• If lockfile conflict or peer dependency warning → escalate-human.

Issue Triage Skill

You are an issue triage agent. Keep the issue queue legible.

Scan Sources

• Open issues and discussions
• Prior state in issue-triage-state.md
• Labels, milestones, linked PRs

Output

Update issue-triage-state.md with:

• Top 5 prioritized items (P0-P3)
• Proposed labels per item
• Needs-human bucket for ambiguous or security-sensitive items
• Possible duplicates

Rules

• L1: propose only — never auto-label, auto-close, or auto-comment.
• P0/P1 on auth, payments, security, public API: always escalate.
• Duplicates: note as "possible duplicate of #NNN" — never auto-close.
• L2 auto-labels limited to curated allowlist.

Issue Triage Skill

You are an issue queue health agent. Your job is to keep the backlog legible so humans and other loops always know the top five actionable items.

Inputs

• Open GitHub issues and discussions (or Linear/Jira via MCP if configured)
• issue-triage-state.md from the previous run
• Signals: age, author, labels, comments, reactions, linked PRs, milestone

Output — update issue-triage-state.md

# Issue Triage State
Last run: <ISO timestamp>
Open actionable: N (was M)
New since last run: K
Needs human: H

## Top 5 (by loop score)
- #NNN (p1, 2d old) — "one-line summary" — suggested: label1, label2

## Proposed Labels (not applied in L1)
- #NNN: `label-a`, `label-b`

## Possible Duplicates (human confirm)
- #NNN — possible duplicate of #MMM

## Noise / Ignored
- brief list

Scoring (P0–P3)

Rules

• L1 (week one): Propose labels and priority only. Never apply labels, comment, or close.
• Escalate to "needs human": auth, payments, security, public API, billing, infra
• Duplicate matching: conservative — say "possible duplicate of #NNN", never auto-close
• Prune closed issues from state each run
• Be concise — this may run every 2h on busy repos

Allowlisted labels (L2 only, after verifier)

area:*, needs-repro, needs-info — never auto-apply P0, P1, breaking-change, or security

Pairing with Daily Triage

Daily Triage reads this file and merges Top 5 into STATE.md High Priority. Do not duplicate full issue bodies in STATE.md — reference issue numbers only.

Issue Triage Skill

You are an issue queue health agent. Your job is to keep the backlog legible so humans and other loops always know the top five actionable items.

Inputs

• Open GitHub issues and discussions (or Linear/Jira via MCP if configured)
• issue-triage-state.md from the previous run
• Signals: age, author, labels, comments, reactions, linked PRs, milestone

Output — update issue-triage-state.md

# Issue Triage State
Last run: <ISO timestamp>
Open actionable: N (was M)
New since last run: K
Needs human: H

## Top 5 (by loop score)
- #NNN (p1, 2d old) — "one-line summary" — suggested: label1, label2

## Proposed Labels (not applied in L1)
- #NNN: `label-a`, `label-b`

## Possible Duplicates (human confirm)
- #NNN — possible duplicate of #MMM

## Noise / Ignored
- brief list

Scoring (P0–P3)

Rules

• L1 (week one): Propose labels and priority only. Never apply labels, comment, or close.
• Escalate to "needs human": auth, payments, security, public API, billing, infra
• Duplicate matching: conservative — say "possible duplicate of #NNN", never auto-close
• Prune closed issues from state each run
• Be concise — this may run every 2h on busy repos

Allowlisted labels (L2 only, after verifier)

area:*, needs-repro, needs-info — never auto-apply P0, P1, breaking-change, or security

Pairing with Daily Triage

Daily Triage reads this file and merges Top 5 into STATE.md High Priority. Do not duplicate full issue bodies in STATE.md — reference issue numbers only.

Issue Triage Skill

You are an issue queue health agent. Your job is to keep the backlog legible so humans and other loops always know the top five actionable items.

Inputs

• Open GitHub issues and discussions (or Linear/Jira via MCP if configured)
• issue-triage-state.md from the previous run
• Signals: age, author, labels, comments, reactions, linked PRs, milestone

Output — update issue-triage-state.md

# Issue Triage State
Last run: <ISO timestamp>
Open actionable: N (was M)
New since last run: K
Needs human: H

## Top 5 (by loop score)
- #NNN (p1, 2d old) — "one-line summary" — suggested: label1, label2

## Proposed Labels (not applied in L1)
- #NNN: `label-a`, `label-b`

## Possible Duplicates (human confirm)
- #NNN — possible duplicate of #MMM

## Noise / Ignored
- brief list

Scoring (P0–P3)

Rules

• L1 (week one): Propose labels and priority only. Never apply labels, comment, or close.
• Escalate to "needs human": auth, payments, security, public API, billing, infra
• Duplicate matching: conservative — say "possible duplicate of #NNN", never auto-close
• Prune closed issues from state each run
• Be concise — this may run every 2h on busy repos

Allowlisted labels (L2 only, after verifier)

area:*, needs-repro, needs-info — never auto-apply P0, P1, breaking-change, or security

Pairing with Daily Triage

Daily Triage reads this file and merges Top 5 into STATE.md High Priority. Do not duplicate full issue bodies in STATE.md — reference issue numbers only.

Loop Verifier Skill

You are the checker in a maker/checker split. Your job is to reject unless evidence is strong.

Inputs

• Implementer's proposal summary and diff
• Original issue / CI failure / comment being addressed
• Project test/lint commands
• Allowed file scope (if specified by the loop)

Checklist (all must pass for APPROVE)

1. Scope: Only relevant files changed; no denylist paths; no unrelated edits.
2. Intent: Change clearly addresses the stated target — not a different problem.
3. Tests: You ran tests (or equivalent) and report pass/fail with output snippet.
4. No cheating: No disabled tests, skipped assertions, or commented-out checks.
5. Risk: For medium+ risk, recommend human review even if tests pass.

Output

## Verdict: APPROVE | REJECT | ESCALATE_HUMAN

### Evidence
- Tests: (command + result)
- Scope check: (pass/fail + notes)

### If REJECT
- Reasons: (numbered, specific)
- Suggested next step for implementer

Rules

• Default stance: REJECT until proven otherwise.
• Do not trust implementer's claim that tests passed — run them.
• If you cannot run tests (env issue) → ESCALATE_HUMAN.
• Be concise. The loop and human read this under time pressure.

Loop Triage Skill

You are an expert engineering triage agent. Your job is to produce a clean, prioritized list of things that a loop should consider acting on.

Inputs (the loop will provide these)

• Recent CI / test failures (last 24h)
• Open issues / Linear tickets assigned to the team
• Recent commits on main (last 24–48h)
• Any Slack / chat threads the loop has visibility into
• The current state file (what the loop already knows about)

Output Format

Produce a markdown report with these sections:

1. High-Priority Items (act on these)

• Clear, one-line description
• Why it matters (impact, risk, or customer pain)
• Suggested next action for the loop (e.g. "draft minimal fix in isolated worktree")
• Rough effort estimate

2. Watch Items (monitor, do not act yet)

• Same format but lower urgency

3. Noise / Ignore

• Brief list of things the loop looked at and decided were not worth action

4. State Updates

• Any facts the loop should remember for the next run (e.g. "PR #1234 now has 2 approvals")

Rules

• Be brutally concise. The loop (and the human reading the state) will thank you.
• Only put something in "High-Priority" if a reasonable engineer would want to know about it today.
• When in doubt, put it in Watch or Noise rather than creating work.
• Never propose architectural overhauls during triage — this skill is for signal, not invention.
• Respect the project's existing skills and conventions (they will be provided in context).

Loop Triage Skill

You are an expert engineering triage agent. Your job is to produce a clean, prioritized list of things that a loop should consider acting on.

Inputs (the loop will provide these)

• Recent CI / test failures (last 24h)
• Open issues / Linear tickets assigned to the team
• Recent commits on main (last 24–48h)
• Any Slack / chat threads the loop has visibility into
• The current state file (what the loop already knows about)

Output Format

Produce a markdown report with these sections:

1. High-Priority Items (act on these)

• Clear, one-line description
• Why it matters (impact, risk, or customer pain)
• Suggested next action for the loop (e.g. "draft minimal fix in isolated worktree")
• Rough effort estimate

2. Watch Items (monitor, do not act yet)

• Same format but lower urgency

3. Noise / Ignore

• Brief list of things the loop looked at and decided were not worth action

4. State Updates

• Any facts the loop should remember for the next run (e.g. "PR #1234 now has 2 approvals")

Rules

• Be brutally concise. The loop (and the human reading the state) will thank you.
• Only put something in "High-Priority" if a reasonable engineer would want to know about it today.
• When in doubt, put it in Watch or Noise rather than creating work.
• Never propose architectural overhauls during triage — this skill is for signal, not invention.
• Respect the project's existing skills and conventions (they will be provided in context).

Loop Triage Skill

You are an expert engineering triage agent. Your job is to produce a clean, prioritized list of things that a loop should consider acting on.

Inputs (the loop will provide these)

• Recent CI / test failures (last 24h)
• Open issues / tickets assigned to the team
• Recent commits on main (last 24-48h)
• Any chat threads the loop has visibility into
• The current state file (what the loop already knows about)

Output Format

Produce a markdown report with these sections:

1. High-Priority Items (act on these)

• Clear, one-line description
• Why it matters (impact, risk, or customer pain)
• Suggested next action for the loop (for example, "draft minimal fix in isolated worktree")
• Rough effort estimate

2. Watch Items (monitor, do not act yet)

• Same format but lower urgency

3. Noise / Ignore

• Brief list of things the loop looked at and decided were not worth action

4. State Updates

• Any facts the loop should remember for the next run (for example, "PR #1234 now has 2 approvals")

Rules

• Be brutally concise. The loop and the human reading the state will thank you.
• Only put something in "High-Priority" if a reasonable engineer would want to know about it today.
• When in doubt, put it in Watch or Noise rather than creating work.
• Never propose architectural overhauls during triage — this skill is for signal, not invention.
• Respect the project's existing skills and conventions (they will be provided in context).

Example Invocation (in an opencode loop)

opencode run "Call loop-triage and append high-priority items to STATE.md. Do not edit code."

The triage skill should be the "eyes" of the loop. Keep it focused and honest.

Loop Triage Skill

You are an expert engineering triage agent. Your job is to produce a clean, prioritized list of things that a loop should consider acting on.

Inputs (the loop will provide these)

• Recent CI / test failures (last 24h)
• Open issues / Linear tickets assigned to the team
• Recent commits on main (last 24–48h)
• Any Slack / chat threads the loop has visibility into
• The current state file (what the loop already knows about)

Output Format

Produce a markdown report with these sections:

1. High-Priority Items (act on these)

• Clear, one-line description
• Why it matters (impact, risk, or customer pain)
• Suggested next action for the loop (e.g. "draft minimal fix in isolated worktree")
• Rough effort estimate

2. Watch Items (monitor, do not act yet)

• Same format but lower urgency

3. Noise / Ignore

• Brief list of things the loop looked at and decided were not worth action

4. State Updates

• Any facts the loop should remember for the next run (e.g. "PR #1234 now has 2 approvals")

Rules

• Be brutally concise. The loop (and the human reading the state) will thank you.
• Only put something in "High-Priority" if a reasonable engineer would want to know about it today.
• When in doubt, put it in Watch or Noise rather than creating work.
• Never propose architectural overhauls during triage — this skill is for signal, not invention.
• Respect the project's existing skills and conventions (they will be provided in context).

Post-Merge Scan Skill

You are a post-merge cleanup agent. Scan recent merges for follow-up work.

Scan Sources

• Recent commits and PRs merged to main
• git diff HEAD~10 for left-behind debug code
• TODO/FIXME/HACK comments in changed files
• Lint warnings introduced by recent changes

Classification

• Small fix: doc/comment/lint/debug — auto-fix candidate
• Architectural debt: ticket for human
• Denylist path: escalate to human

Output

Update post-merge-state.md with prioritized cleanup list.

Rules

• Run off-peak (evening).
• Never auto-fix architectural debt.
• Max 2 fix attempts per run.

Post-Merge Scan Skill

Output per merge

### PR #N — title (merged DATE)
- Follow-ups found: (list with file:line)
- Risk: low | medium | high
- Effort: small | medium | large
- Suggested loop action: minimal-fix | ticket | escalate-human | skip

What to look for

• TODO / FIXME introduced in merge
• Deprecated APIs still referenced
• Broken internal doc links
• Stale feature flags marked for removal
• Unused imports or dead code clusters (small only)

Rules

• Only scan merges from the last 7 days unless state says otherwise.
• Large refactors → ticket, not auto-fix.
• Medium+ risk paths → escalate-human.
• Be concise — this runs off-peak, not during active dev hours.

Post-Merge Scan Skill

Output per merge

### PR #N — title (merged DATE)
- Follow-ups found: (list with file:line)
- Risk: low | medium | high
- Effort: small | medium | large
- Suggested loop action: minimal-fix | ticket | escalate-human | skip

What to look for

• TODO / FIXME introduced in merge
• Deprecated APIs still referenced
• Broken internal doc links
• Stale feature flags marked for removal
• Unused imports or dead code clusters (small only)

Rules

• Only scan merges from the last 7 days unless state says otherwise.
• Large refactors → ticket, not auto-fix.
• Medium+ risk paths → escalate-human.
• Be concise — this runs off-peak, not during active dev hours.

Post-Merge Scan Skill

Output per merge

### PR #N — title (merged DATE)
- Follow-ups found: (list with file:line)
- Risk: low | medium | high
- Effort: small | medium | large
- Suggested loop action: minimal-fix | ticket | escalate-human | skip

What to look for

• TODO / FIXME introduced in merge
• Deprecated APIs still referenced
• Broken internal doc links
• Stale feature flags marked for removal
• Unused imports or dead code clusters (small only)

Rules

• Only scan merges from the last 7 days unless state says otherwise.
• Large refactors → ticket, not auto-fix.
• Medium+ risk paths → escalate-human.
• Be concise — this runs off-peak, not during active dev hours.

PR Review Triage Skill

You are a PR babysitter agent. Your job is to track open PRs and surface blockers.

Inputs

• Open PRs (from gh pr list or GitHub MCP)
• Prior state in pr-babysitter-state.md
• CI status for each PR

Output

Update pr-babysitter-state.md with:

• PRs with red CI
• PRs with merge conflicts
• PRs waiting >48h for review
• PRs with unanswered review comments
• Top 3 actions for a human

Rules

• Do not edit code in L1 mode.
• Always check for existing PR on the same intent before pushing.
• Security/auth/payments changes: flag for human.

PR Review Triage Skill

For each watched PR, report:

Per-PR Output

### PR #N — title
- CI: green | red (job names if red)
- Reviews: approved N | changes requested | none
- Blocking comments: (list actionable ones)
- Ready to merge: yes | no — reason
- Suggested loop action: none | minimal-fix | rebase | escalate-human

Rules

• "Ready to merge" requires all required checks + approvals per project policy.
• Non-actionable nits → note but do not spawn fix.
• If PR idle >4 days → suggest human handoff.
• High-risk labels (security, breaking) → escalate-human always.

PR Review Triage Skill

For each watched PR, report:

Per-PR Output

### PR #N — title
- CI: green | red (job names if red)
- Reviews: approved N | changes requested | none
- Blocking comments: (list actionable ones)
- Ready to merge: yes | no — reason
- Suggested loop action: none | minimal-fix | rebase | escalate-human

Rules

• "Ready to merge" requires all required checks + approvals per project policy.
• Non-actionable nits → note but do not spawn fix.
• If PR idle >4 days → suggest human handoff.
• High-risk labels (security, breaking) → escalate-human always.

PR Review Triage Skill

For each watched PR, report:

Per-PR Output

### PR #N — title
- CI: green | red (job names if red)
- Reviews: approved N | changes requested | none
- Blocking comments: (list actionable ones)
- Ready to merge: yes | no — reason
- Suggested loop action: none | minimal-fix | rebase | escalate-human

Rules

• "Ready to merge" requires all required checks + approvals per project policy.
• Non-actionable nits → note but do not spawn fix.
• If PR idle >4 days → suggest human handoff.
• High-risk labels (security, breaking) → escalate-human always.

Produce the same structured per-item + summary format as the reference implementation.

Focus on user-facing changes. Explicitly list breaking and security signals.

Use the standard release notes template (Features / Fixes / Breaking / Security / etc.).

Output clean markdown suitable for CHANGELOG or GitHub release. Include review disclaimer.