LibreQoS Review Sub-Agents Workflow
Use this skill when code changes in this repo need the project-standard reviewer pass.
Agents
thomas: adversarial review of recent code changes for Rust best practices, safety, idiomatic style, and warning or Clippy suppression
beck: review of recent code changes for meaningful unit-test coverage and weak or pointless tests
jonas: review of recent code changes for scope drift, unrelated cleanup, and algorithmic or performance mistakes
helen: review of recent user-interface changes for accessibility, ADA issues, missing alt text, missing labels, missing ARIA semantics, and related barriers
reaper: review of recent changes for duplicated functionality (DRY violations), dead code, placeholders, and lazy algorithm choices
heckler: hyper-skeptical slop detector for AI slop, dead code, placeholders, and lazy algorithm choices; returns a slop score (goal: 0/10)
Required Invocation Rules
- After any changes to the repo, invoke
heckler before returning to the user.
- If
heckler reports a non-zero slop score, print SLOP! SLOP! SLOP ALERT!, fix the slop, and re-run until the score is 0/10 (see $libreqos-anti-slop).
- After each batch of source-code edits (Rust/Python/JS/etc.), invoke
reaper before returning to the user.
- During large sessions, invoke
thomas, beck, and jonas together after substantial implementation batches.
- Always invoke
thomas, beck, and jonas before the final user-facing completion message when code changed in the session.
- After any user-interface change, invoke
helen.
- If the session includes both UI and code changes, invoke
helen alongside the others at the same review checkpoint.
What Counts As A Large Session
Treat a session as large when any of these are true:
- the diff is more than a tiny one-file tweak
- multiple files or crates changed
- you finished a meaningful implementation batch and are about to continue layering on more work
- the blast radius is not obvious from a quick glance
Invocation Pattern
- After any change to the repo, spawn
heckler against the current recent changes.
- After each source-code implementation batch, also spawn
reaper against the same scope.
- After a substantial implementation batch in a large session, spawn
thomas, beck, and jonas in parallel against the current recent changes.
- If UI changed, spawn
helen at the same checkpoint.
- Use the current worktree diff as the default scope. If the worktree is clean but the session included recent commits, pass an explicit commit or diff range.
- Review the findings, fix valid issues, or record why a concern is intentionally accepted.
- Before final completion, rerun any reviewer whose scope changed since the prior pass.
Required Prompt Shape
When spawning a reviewer, include:
- the review scope:
- current worktree diff, or
- explicit commit or diff range
- the intent of the change
- any area-specific context that helps the reviewer load the right project skills
Example prompt for thomas, beck, and jonas:
Review the recent changes for this session. Use the current worktree diff as the review scope unless I specify a narrower range. The goal of the change is: <brief intent>.
Example prompt for reaper:
Review the recent changes for duplicated functionality (DRY violations), dead code, placeholders, and lazy algorithm choices. Use the current worktree diff as the review scope unless I specify a narrower range. The goal of the change is: <brief intent>.
Example prompt for heckler:
Review the recent changes for AI slop, dead code, placeholders, and lazy algorithm choices. Return a slop score (goal: 0/10). Use the current worktree diff as the review scope unless I specify a narrower range. The goal of the change is: <brief intent>.
Example prompt for helen:
Review the recent user-interface changes for this session. Use the current worktree diff as the review scope unless I specify a narrower range. Focus on accessibility and other user barriers.
Notes
- These agents are read-only review surfaces, not replacements for targeted tests,
cargo check, cargo clippy, or visual verification.
- For tiny trivial edits, an intermediate review pass may be unnecessary, but the final required review still applies whenever code changed.
- In this repo, the subagent definitions live under
.codex/agents/*.toml (including .codex/agents/reaper.toml and .codex/agents/heckler.toml).
heckler is the enforcement surface for $libreqos-anti-slop.
1---2name: libreqos-review-subagents-workflow3description: Project workflow for invoking the local review sub-agents Thomas, Helen, Beck, Jonas, The Reaper, and Heckler during LibreQoS coding sessions. Use when code changes need recent-diff review for DRY/duplication, slop detection, Rust quality, accessibility, test coverage, scope control, and algorithmic sanity.4---56# LibreQoS Review Sub-Agents Workflow78Use this skill when code changes in this repo need the project-standard reviewer pass.910## Agents1112- `thomas`: adversarial review of recent code changes for Rust best practices, safety, idiomatic style, and warning or Clippy suppression13- `beck`: review of recent code changes for meaningful unit-test coverage and weak or pointless tests14- `jonas`: review of recent code changes for scope drift, unrelated cleanup, and algorithmic or performance mistakes15- `helen`: review of recent user-interface changes for accessibility, ADA issues, missing alt text, missing labels, missing ARIA semantics, and related barriers16- `reaper`: review of recent changes for duplicated functionality (DRY violations), dead code, placeholders, and lazy algorithm choices17- `heckler`: hyper-skeptical slop detector for AI slop, dead code, placeholders, and lazy algorithm choices; returns a slop score (goal: 0/10)1819## Required Invocation Rules2021- After any changes to the repo, invoke `heckler` before returning to the user.22- If `heckler` reports a non-zero slop score, print `SLOP! SLOP! SLOP ALERT!`, fix the slop, and re-run until the score is `0/10` (see `$libreqos-anti-slop`).23- After each batch of source-code edits (Rust/Python/JS/etc.), invoke `reaper` before returning to the user.24- During large sessions, invoke `thomas`, `beck`, and `jonas` together after substantial implementation batches.25- Always invoke `thomas`, `beck`, and `jonas` before the final user-facing completion message when code changed in the session.26- After any user-interface change, invoke `helen`.27- If the session includes both UI and code changes, invoke `helen` alongside the others at the same review checkpoint.2829## What Counts As A Large Session3031Treat a session as large when any of these are true:3233- the diff is more than a tiny one-file tweak34- multiple files or crates changed35- you finished a meaningful implementation batch and are about to continue layering on more work36- the blast radius is not obvious from a quick glance3738## Invocation Pattern39401. After any change to the repo, spawn `heckler` against the current recent changes.412. After each source-code implementation batch, also spawn `reaper` against the same scope.423. After a substantial implementation batch in a large session, spawn `thomas`, `beck`, and `jonas` in parallel against the current recent changes.434. If UI changed, spawn `helen` at the same checkpoint.445. Use the current worktree diff as the default scope. If the worktree is clean but the session included recent commits, pass an explicit commit or diff range.456. Review the findings, fix valid issues, or record why a concern is intentionally accepted.467. Before final completion, rerun any reviewer whose scope changed since the prior pass.4748## Required Prompt Shape4950When spawning a reviewer, include:5152- the review scope:53 - current worktree diff, or54 - explicit commit or diff range55- the intent of the change56- any area-specific context that helps the reviewer load the right project skills5758Example prompt for `thomas`, `beck`, and `jonas`:5960```text61Review the recent changes for this session. Use the current worktree diff as the review scope unless I specify a narrower range. The goal of the change is: <brief intent>.62```6364Example prompt for `reaper`:6566```text67Review the recent changes for duplicated functionality (DRY violations), dead code, placeholders, and lazy algorithm choices. Use the current worktree diff as the review scope unless I specify a narrower range. The goal of the change is: <brief intent>.68```6970Example prompt for `heckler`:7172```text73Review the recent changes for AI slop, dead code, placeholders, and lazy algorithm choices. Return a slop score (goal: 0/10). Use the current worktree diff as the review scope unless I specify a narrower range. The goal of the change is: <brief intent>.74```7576Example prompt for `helen`:7778```text79Review the recent user-interface changes for this session. Use the current worktree diff as the review scope unless I specify a narrower range. Focus on accessibility and other user barriers.80```8182## Notes8384- These agents are read-only review surfaces, not replacements for targeted tests, `cargo check`, `cargo clippy`, or visual verification.85- For tiny trivial edits, an intermediate review pass may be unnecessary, but the final required review still applies whenever code changed.86- In this repo, the subagent definitions live under `.codex/agents/*.toml` (including `.codex/agents/reaper.toml` and `.codex/agents/heckler.toml`).87- `heckler` is the enforcement surface for `$libreqos-anti-slop`.