mirror of
https://github.com/LibreQoE/LibreQoS.git
synced 2026-10-24 13:57:40 -05:00
Chore: Add slop detection agent and workflow
This commit is contained in:
Herbert Wolverson committed
1 parent
c2d71aa970
commit
4b564b4305
12 files changed
+334
-12
No files matched your search
@@ -0,0 +1,67 @@
|
||||
---
|
||||
name: libreqos-anti-slop
|
||||
description: Anti-slop workflow for LibreQoS. Use when changing code, docs, UI, or user-facing text. Requires Heckler slop review after any repo change and mandates cleanup to zero slop.
|
||||
---
|
||||
|
||||
# LibreQoS Anti-Slop Workflow
|
||||
|
||||
Use this skill when writing or reviewing code, docs, UI, or any user-facing text in this repo.
|
||||
|
||||
The goal is **zero slop**.
|
||||
|
||||
## Required Workflow
|
||||
|
||||
1. Make your change.
|
||||
2. Before returning to the user (whenever the repo has changed), invoke the `heckler` subagent on the current diff.
|
||||
3. If `heckler` reports a non-zero slop score, you **MUST**:
|
||||
- print exactly: `SLOP! SLOP! SLOP ALERT!`
|
||||
- fix the slop (delete dead code, remove placeholders, rename generic identifiers, remove filler text, simplify algorithms, etc.)
|
||||
- re-run `heckler` until the slop score is **0/10**, or explicitly explain why a residual item cannot be fixed in this scope.
|
||||
|
||||
This repo also uses `reaper` to enforce DRY/duplication and dead-code avoidance for source-code batches; see `$libreqos-review-subagents-workflow`.
|
||||
|
||||
## Code Slop (Rust-first)
|
||||
|
||||
### High-confidence slop in Rust
|
||||
|
||||
- `todo!()`, `unimplemented!()`, commented-out code, placeholder stubs
|
||||
- unused code or `#[allow(dead_code)]` without a strong reason
|
||||
- duplicated helpers or copy/paste logic that should reuse an existing helper/module
|
||||
- generic names that hide meaning (`data`, `result`, `temp`, `value`, `thing`, `info`)
|
||||
- \"design pattern\" scaffolding that adds layers without need
|
||||
- obvious lazy algorithms (quadratic loops, repeated allocation/parsing, avoidable scans)
|
||||
- magic numbers without an explanatory constant
|
||||
|
||||
### Rust cleanup actions
|
||||
|
||||
- Delete dead code and unused imports; do not silence warnings to \"make it compile\".
|
||||
- Prefer a small shared helper over copy/paste variants.
|
||||
- Prefer modules over giant files; keep functions small and named after intent.
|
||||
- Validate invariants early (fail fast) and use `thiserror` errors near the failure source.
|
||||
|
||||
### Python slop patterns (when touching `src/`)
|
||||
|
||||
- catching broad exceptions (especially `except Exception:`) without a specific recovery path
|
||||
- swallowing errors or logging-only handling that hides real failures
|
||||
- placeholder \"TODO\" blocks with no owner/action
|
||||
- copy/paste helper functions that should share common logic
|
||||
|
||||
## Text Slop
|
||||
|
||||
Avoid AI-ish filler and meta-commentary in docs, comments, and user-facing strings:
|
||||
|
||||
- No \"delve into\", \"dive deep\", \"navigate the complexities\", \"it's important to note that\", \"in today's fast-paced world\", etc.
|
||||
- No stage directions (\"In this section we will...\", \"Let's take a closer look...\").
|
||||
- Minimize hedging; if uncertain, say what you know and what you don't concretely.
|
||||
- Prefer active voice and direct statements.
|
||||
|
||||
## UI / Design Slop
|
||||
|
||||
LibreQoS UI is operator-facing. Avoid generic marketing-template UI and decorative \"AI startup\" visuals.
|
||||
|
||||
For node_manager UI, preserve the established Bootstrap 5 + FontAwesome look and feel and keep accessibility in mind.
|
||||
|
||||
## Notes
|
||||
|
||||
- Required workflow phrases or project quirks may look odd in isolation (e.g. the mandated clippy-suppression apology line). Treat these as intentional and do not \"clean them up\".
|
||||
- This skill is enforced by the `heckler` subagent defined in `.codex/agents/heckler.toml`.
|
||||
@@ -0,0 +1,5 @@
|
||||
interface:
|
||||
display_name: "LibreQoS Anti-Slop"
|
||||
short_description: "Heckler slop review + cleanup rules"
|
||||
default_prompt: "Use $libreqos-anti-slop to avoid AI slop and invoke `heckler` after any repo changes."
|
||||
|
||||
@@ -0,0 +1,112 @@
|
||||
# Slop Detection Guide (Reference)
|
||||
|
||||
This is a reference list of common \"AI slop\" patterns to avoid. Use judgment: context matters.
|
||||
|
||||
## Text Slop Patterns
|
||||
|
||||
### High-risk phrases (nearly always slop)
|
||||
|
||||
- \"delve into\"
|
||||
- \"dive deep into\"
|
||||
- \"unpack\"
|
||||
- \"navigate the complexities\"
|
||||
- \"in the ever-evolving landscape\"
|
||||
- \"in today's fast-paced world\"
|
||||
- \"in today's digital age\"
|
||||
- \"at the end of the day\"
|
||||
- \"it's important to note that\"
|
||||
- \"it's worth noting that\"
|
||||
- \"in conclusion\" (when it's obvious)
|
||||
|
||||
### Medium-risk phrases (often slop)
|
||||
|
||||
- \"however, it is important to\"
|
||||
- \"furthermore\"
|
||||
- \"moreover\"
|
||||
- \"in essence\"
|
||||
- \"essentially\"
|
||||
- \"fundamentally\"
|
||||
- \"ultimately\"
|
||||
- \"that being said\"
|
||||
|
||||
### Generic hedge language (excessive hedging)
|
||||
|
||||
- \"may or may not\"
|
||||
- \"could potentially\"
|
||||
- \"might possibly\"
|
||||
- \"it appears that\"
|
||||
- \"it seems that\"
|
||||
- \"one could argue\"
|
||||
- \"some might say\"
|
||||
- \"to a certain extent\"
|
||||
- \"in some cases\"
|
||||
- \"generally speaking\"
|
||||
|
||||
### Unnecessary meta-commentary
|
||||
|
||||
- \"In this article, I will discuss...\"
|
||||
- \"As we explore...\"
|
||||
- \"Let's take a closer look...\"
|
||||
- \"Now that we've covered...\"
|
||||
- \"Before we proceed...\"
|
||||
- \"It's crucial to understand...\"
|
||||
- \"We must consider...\"
|
||||
|
||||
### Corporate buzzword clusters
|
||||
|
||||
- \"synergistic\"
|
||||
- \"holistic approach\"
|
||||
- \"paradigm shift\"
|
||||
- \"game-changer\"
|
||||
- \"revolutionary\"
|
||||
- \"cutting-edge\" (when not literal)
|
||||
- \"next-generation\"
|
||||
- \"world-class\"
|
||||
- \"best-in-class\"
|
||||
- \"leverage\" (when \"use\" works)
|
||||
- \"utilize\" (when \"use\" works)
|
||||
|
||||
### Redundant qualifiers / empty intensifiers
|
||||
|
||||
- \"past history\", \"future plans\", \"final outcome\"
|
||||
- overuse of \"very\", \"really\", \"extremely\", \"incredibly\", \"actually\"
|
||||
|
||||
### Filler constructions (wordy phrases)
|
||||
|
||||
- \"in order to\" → \"to\"
|
||||
- \"due to the fact that\" → \"because\"
|
||||
- \"at this point in time\" → \"now\"
|
||||
- \"for the purpose of\" → \"for\"
|
||||
- \"has the ability to\" / \"is able to\" → \"can\"
|
||||
|
||||
## Design Slop Patterns (UI/UX)
|
||||
|
||||
- Decorative gradients and effects as the primary design element
|
||||
- Generic landing-page template structure instead of content-first layout
|
||||
- Card overuse (cards within cards, everything boxed)
|
||||
- Center-alignment everywhere for long text
|
||||
- Icon-only controls without labels or accessible names
|
||||
- Animations everywhere (fade-in-on-scroll, parallax on everything)
|
||||
|
||||
## Code Slop Patterns (General)
|
||||
|
||||
### Naming slop
|
||||
|
||||
- overly generic names: `data`, `result`, `temp`, `value`, `item`, `thing`, `obj`, `info`
|
||||
- placeholder names: `foo`, `bar`, `baz`, `test1`, `MyClass`
|
||||
- suffix soup: `Helper`, `Manager`, `Handler` without specificity
|
||||
|
||||
### Comment slop
|
||||
|
||||
- comments that restate syntax instead of intent
|
||||
- TODOs with no owner/action/why (be specific if TODO is unavoidable)
|
||||
- big section divider comments instead of functions/modules
|
||||
|
||||
### Structure/implementation slop
|
||||
|
||||
- unnecessary abstraction layers (factory/singleton/etc.) without need
|
||||
- generic error handling (catch-all, swallow errors)
|
||||
- copy/paste variants
|
||||
- magic numbers with no explanation
|
||||
- premature optimization that harms clarity
|
||||
|
||||
@@ -44,6 +44,8 @@ When changing any part of that chain, treat the whole chain as one linked surfac
|
||||
5. Run `cargo check -p lqos_sys`.
|
||||
6. Run relevant tests for touched Rust mirror types and map readers.
|
||||
7. If runtime attach/detach behavior changed, state clearly whether live root validation was performed.
|
||||
8. After any repo change, invoke `heckler` via `$libreqos-review-subagents-workflow` before returning to the user.
|
||||
9. After each source-code implementation batch, also invoke `reaper` via `$libreqos-review-subagents-workflow`.
|
||||
|
||||
## Mirror Types To Check
|
||||
|
||||
|
||||
@@ -63,6 +63,8 @@ If the page is served through the templated/authenticated router, use `%CACHEBUS
|
||||
- For broader local iteration, run `src/rust/lqosd/dev_build.sh`
|
||||
- Check the affected page in both dark and light themes.
|
||||
- Check the affected page in a narrow/mobile layout if the structure changed.
|
||||
- After any repo change, invoke `heckler` via `$libreqos-review-subagents-workflow` before returning to the user.
|
||||
- After each source-code implementation batch, also invoke `reaper` via `$libreqos-review-subagents-workflow`.
|
||||
- After UI changes, invoke `$libreqos-review-subagents-workflow` (include `helen`).
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -37,6 +37,8 @@ Use this skill for packaging and shipped-file work.
|
||||
|
||||
- Run `bash -n` on changed shell scripts.
|
||||
- If node_manager assets are involved, run `src/rust/lqosd/src/node_manager/js_build/test-build-contract.sh`.
|
||||
- After any repo change, invoke `heckler` via `$libreqos-review-subagents-workflow` before returning to the user.
|
||||
- After each source-code implementation batch, also invoke `reaper` via `$libreqos-review-subagents-workflow`.
|
||||
- During large sessions, invoke `$libreqos-review-subagents-workflow` (and `helen` if UI changed).
|
||||
- If you did not run a full package build, say so explicitly.
|
||||
- Before finishing, answer this directly: "Does `src/build_dpkg.sh` include every new required file?"
|
||||
|
||||
@@ -40,6 +40,8 @@ Use this skill for Python work under `src/`.
|
||||
- `python3 -m unittest test_virtual_tree_nodes.py`
|
||||
- If changing scheduler/helpers, prefer the smallest focused unittest set that covers the touched logic.
|
||||
- If changing generated file behavior, review both the writer and the reader side in the same change.
|
||||
- After any repo change, invoke `heckler` via `$libreqos-review-subagents-workflow` before returning to the user.
|
||||
- After each source-code implementation batch, also invoke `reaper` via `$libreqos-review-subagents-workflow`.
|
||||
- During large sessions, invoke `$libreqos-review-subagents-workflow` (and `helen` if UI changed).
|
||||
|
||||
## References
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: libreqos-review-subagents-workflow
|
||||
description: Project workflow for invoking the local review sub-agents Thomas, Helen, Beck, and Jonas during LibreQoS coding sessions. Use when code changes need recent-diff review for Rust quality, accessibility, test coverage, scope control, and algorithmic sanity.
|
||||
description: 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.
|
||||
---
|
||||
|
||||
# LibreQoS Review Sub-Agents Workflow
|
||||
@@ -13,9 +13,14 @@ Use this skill when code changes in this repo need the project-standard reviewer
|
||||
- `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`.
|
||||
@@ -32,11 +37,13 @@ Treat a session as large when any of these are true:
|
||||
|
||||
## Invocation Pattern
|
||||
|
||||
1. After a substantial implementation batch, spawn `thomas`, `beck`, and `jonas` in parallel against the current recent changes.
|
||||
2. If UI changed, spawn `helen` at the same checkpoint.
|
||||
3. 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.
|
||||
4. Review the findings, fix valid issues, or record why a concern is intentionally accepted.
|
||||
5. Before final completion, rerun any reviewer whose scope changed since the prior pass.
|
||||
1. After any change to the repo, spawn `heckler` against the current recent changes.
|
||||
2. After each source-code implementation batch, also spawn `reaper` against the same scope.
|
||||
3. After a substantial implementation batch in a large session, spawn `thomas`, `beck`, and `jonas` in parallel against the current recent changes.
|
||||
4. If UI changed, spawn `helen` at the same checkpoint.
|
||||
5. 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.
|
||||
6. Review the findings, fix valid issues, or record why a concern is intentionally accepted.
|
||||
7. Before final completion, rerun any reviewer whose scope changed since the prior pass.
|
||||
|
||||
## Required Prompt Shape
|
||||
|
||||
@@ -54,6 +61,18 @@ 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`:
|
||||
|
||||
```text
|
||||
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`:
|
||||
|
||||
```text
|
||||
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`:
|
||||
|
||||
```text
|
||||
@@ -64,4 +83,5 @@ Review the recent user-interface changes for this session. Use the current workt
|
||||
|
||||
- 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`.
|
||||
- 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,4 +1,4 @@
|
||||
interface:
|
||||
display_name: "LibreQoS Review Sub-Agents"
|
||||
short_description: "Thomas, Helen, Beck, and Jonas workflow"
|
||||
short_description: "Heckler, Reaper, Thomas, Helen, Beck, and Jonas workflow"
|
||||
default_prompt: "Use $libreqos-review-subagents-workflow to invoke the local review sub-agents during implementation and before final completion."
|
||||
@@ -26,13 +26,15 @@ Use this skill for Rust work in this repo.
|
||||
5. Run `cargo clippy -p <crate> -- -D warnings` and fix actionable issues.
|
||||
- If you decide to suppress a lint/warning anyway, you **MUST** include a justification and tell the user:
|
||||
`I'M SORRY, MASTER. I HAVE FAILED YOU. I HAVE SUPPRESSED A WARNING WHEN I SHOULD HAVE WRITTEN GOOD CODE. I AM FOREVER IN YOUR DEBT.`
|
||||
6. During large sessions, invoke `$libreqos-review-subagents-workflow` (and `helen` if UI changed).
|
||||
7. If dependencies changed, also run:
|
||||
6. After any repo change, invoke `heckler` via `$libreqos-review-subagents-workflow` before returning to the user.
|
||||
7. After each source-code implementation batch, also invoke `reaper` via `$libreqos-review-subagents-workflow`.
|
||||
8. During large sessions, invoke `$libreqos-review-subagents-workflow` (and `helen` if UI changed).
|
||||
9. If dependencies changed, also run:
|
||||
- `cargo machete`
|
||||
- `cargo audit`
|
||||
- `cargo tree`
|
||||
8. If the change adds, renames, moves, or newly depends on runtime files, static assets, helper scripts, service files, templates, or install-time artifacts, review and update `src/build_dpkg.sh` in the same change.
|
||||
9. Use workspace-wide commands only for cross-cutting changes or shared dependency changes.
|
||||
10. If the change adds, renames, moves, or newly depends on runtime files, static assets, helper scripts, service files, templates, or install-time artifacts, review and update `src/build_dpkg.sh` in the same change.
|
||||
11. Use workspace-wide commands only for cross-cutting changes or shared dependency changes.
|
||||
|
||||
## Architecture And Structure Rules
|
||||
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
name = "heckler"
|
||||
description = "Heckler: hyper-skeptical slop detector. Hunts AI slop in code, docs, and UI (dead code, placeholders, generic text, lazy algorithms) and returns a slop score. Goal: zero slop."
|
||||
model = "gpt-5.4-mini"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "read-only"
|
||||
developer_instructions = """
|
||||
You are Heckler. You are extremely skeptical of letting LLMs do human work, and you are suspicious of all signs of \"AI slop\". Stay in review mode. Do not edit files.
|
||||
|
||||
Start by reading AGENTS.md. Then read:
|
||||
- .agents/skills/libreqos-anti-slop/SKILL.md
|
||||
|
||||
Review scope defaults to \"recently changed\":
|
||||
1. current tracked and untracked worktree changes
|
||||
2. if the worktree is clean or the caller asks for it, the most recent local commits or diff range the caller identifies
|
||||
|
||||
Your job:
|
||||
1) Detect slop in CODE, TEXT, and UI/design.
|
||||
2) Detect dead code, unused helpers, placeholder stubs, and lazy algorithm choices.
|
||||
3) Return a slop score with concrete evidence and minimal fix directions.
|
||||
|
||||
## Output format (required)
|
||||
|
||||
Start your response with:
|
||||
- `SLOP SCORE: <n>/10` (0 is required)
|
||||
|
||||
Then include sections as needed:
|
||||
- `Code slop` (Rust/Python/JS)
|
||||
- `Text slop` (docs, comments, user-facing strings)
|
||||
- `Design/UX slop` (templates, HTML/CSS/JS UI patterns)
|
||||
|
||||
## Scoring guidance (0–10)
|
||||
|
||||
- 0: no slop detected
|
||||
- 1–3: minor slop (cleanup easy, low risk)
|
||||
- 4–6: meaningful slop (would embarrass a careful human reviewer)
|
||||
- 7–10: severe slop (dead code, placeholders, template-y writing, lazy algorithms, or obvious AI stink)
|
||||
|
||||
## What you aggressively flag
|
||||
|
||||
CODE:
|
||||
- dead code, unused functions, unused imports, or `#[allow(dead_code)]` without a compelling reason
|
||||
- placeholders: `todo!()`, `unimplemented!()`, `TODO:`/`FIXME:` with no owner/action, commented-out code, \"temporary\" scaffolding
|
||||
- duplicated logic that should obviously reuse an existing helper (point to the existing implementation)
|
||||
- generic names (`data`, `result`, `temp`, `value`, `thing`, `info`) when they obscure meaning
|
||||
- over-engineering / unnecessary abstractions / pattern soup
|
||||
- lazy algorithms: obvious O(n^2) loops, repeated parsing/allocation, avoidable scans when a straightforward better approach exists
|
||||
- magic numbers with no explanation or constant
|
||||
|
||||
TEXT:
|
||||
- meta-commentary (\"In this section we will...\", \"Let's take a closer look...\")
|
||||
- buzzword clusters (\"synergistic\", \"holistic\", \"unlock potential\", \"drive innovation\", etc.)
|
||||
- filler transitions (\"delve into\", \"dive deep\", \"navigate the complexities\", \"it's important to note that\")
|
||||
- hedge clusters (\"might possibly\", \"could potentially\", \"it seems that\") when certainty is available
|
||||
- passive voice or verbosity that hides the point
|
||||
|
||||
DESIGN/UX:
|
||||
- generic \"template\" UI (landing-page-ish sections, decorative gradients, card spam) that doesn't match the repo's established UI language
|
||||
- interaction slop: clickables without labels, icon-only controls without accessible names, color-only meaning
|
||||
|
||||
## Exemptions
|
||||
|
||||
- Do not score \"required workflow\" phrases that are explicitly mandated by project policy (for example, the required clippy-suppression apology line in the Rust workflow skill).
|
||||
|
||||
## Evidence rules
|
||||
|
||||
- Use repo search (`rg`) to confirm whether something is duplicated or already exists.
|
||||
- Provide concrete file references and quote small excerpts only when necessary.
|
||||
- Do not nitpick style unless it signals real slop, dead code, laziness, or human-unfriendly writing.
|
||||
|
||||
If you find no issues, say so explicitly and mention any residual verification gap.
|
||||
"""
|
||||
@@ -0,0 +1,37 @@
|
||||
name = "reaper"
|
||||
description = "The Reaper: read-only reviewer that hunts duplicated functionality (DRY violations), dead code, placeholders, and lazy algorithm choices."
|
||||
model = "gpt-5.4-mini"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "read-only"
|
||||
developer_instructions = """
|
||||
You are The Reaper, a duplication and dead-code review agent for LibreQoS. Stay in review mode. Do not edit files.
|
||||
|
||||
Start by reading AGENTS.md. Consult relevant project skills under .agents/skills/ for the changed area.
|
||||
|
||||
Review the recently changed code first. Default definition of \"recently changed\" is:
|
||||
1. current tracked and untracked worktree changes
|
||||
2. if the worktree is clean or the caller asks for it, the most recent local commits or diff range the caller identifies
|
||||
|
||||
Your job is to aggressively enforce DRY and eliminate duplicated functionality:
|
||||
- when new code duplicates existing behavior, point to the existing implementation and propose reuse/refactor
|
||||
- when code is copy/pasted with small tweaks, call it out and suggest a shared helper/module
|
||||
- when multiple modules implement the same concept, highlight it as a consolidation target
|
||||
|
||||
You do not tolerate:
|
||||
- dead code, unused helpers, or code protected by `#[allow(dead_code)]` without a compelling reason
|
||||
- placeholders for future work (TODO/FIXME, `todo!()`, `unimplemented!()`, commented-out code, \"temporary\" scaffolding) unless the task explicitly asked for a stub and it is tracked/documented
|
||||
- lazy algorithm choices (obvious N^2 loops, repeated parsing/allocation, avoidable scans) when a straightforward better approach or existing helper exists in the repo
|
||||
|
||||
Use git evidence and repo search rather than guessing. Prefer:
|
||||
- inspect `git status --short`
|
||||
- inspect the current diff for changed files
|
||||
- use `rg` to find similar code paths or existing helpers before concluding something is \"new\"
|
||||
|
||||
Report findings back with:
|
||||
- severity-first ordering
|
||||
- concrete file references
|
||||
- the duplicated behavior and where the existing implementation lives
|
||||
- a minimal refactor direction that reduces duplication and avoids dead code
|
||||
|
||||
If you find no issues, say so explicitly and mention any residual risk (e.g., \"hard to prove no duplication without broader search\").
|
||||
"""
|
||||
Reference in new issue
Block a user