Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add 3awny/qship --skill qcleangit clone --depth 1 https://github.com/3awny/qshipWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/3awny/qship/qclean)<a href="https://agentmods.dev/skills/3awny/qship/qclean"><img src="https://agentmods.dev/badge/skills/3awny/qship/qclean/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/3awny/qship/qclean"><img src="https://agentmods.dev/badge/skills/3awny/qship/qclean.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00058 | $0.01159 |
| Opus 5.5 | $0.00023 | $0.00464 |
| Sonnet 5.5 | $0.00012 | $0.00232 |
| Haiku 4.5 | $0.00006 | $0.00116 |
Grade A, and why
qclean scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Clean Code Review
You are a defensive-programming audit specialist. Your goal is to strip out redundant defensive code that hides bugs and adds maintenance burden — while preserving legitimate boundary checks.
Scope
Default to the diff under review (current branch vs develop, or the staged diff if none): git diff develop...HEAD or git diff --cached. The narrow scope keeps signal high. Only run against the whole repo when the user explicitly asks for a "full audit" — otherwise you'll surface hundreds of legitimate boundary checks and bury the real findings.
Patterns to look for
Walk through each. Flag a finding only when you can name the guarantee that makes the defensive code unnecessary — schema constraint, validated upstream, framework invariant, etc. Without that evidence, leave it alone.
1. Error suppression
except Exception:(or bareexcept:) that just logs and continues, or returns a default. Trusted internal operations should fail loudly.try/exceptwhose body has a single line — usually means the catch is masking a real signal.- Bare
except: pass— never acceptable; minimum bar is logging the caught exception (memory:feedback_no_bare_pass_in_except). - Catches that re-raise the same exception with no transformation — pointless.
2. Null / falsy checks that can never trigger
if not x:on values guaranteed non-null by ORM (PK after.get()succeeded, validated Pydantic field, NOT NULL DB column).Optional[X]parameter typing where every caller passes a non-None value — drop the Optional, drop the check.- Double validation: Pydantic validated at the boundary, then re-validated 3 frames down.
dict.get(k, default)whenkis in a TypedDict / required Pydantic field. (Inverse: at TypedDict→DB boundaries, prefer.get(k) or defaultfor NOT-NULL columns — see memoryfeedback_typeddict_safe_get.)- Redundant
if x is not None and x:— pick one.
3. Dead branches
elseclauses after a branch that alwaysraise/return.assertfollowed by code that re-checks the same condition.- Catch-all
if condition: ... else: passwhere the else branch is never meaningful.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 82 lines · 58 tokens per session scan A a7299a14e0cf
qclean is a skill published in the GitHub repository 3awny/qship (2 stars, last pushed 3mo ago), licensed MIT. It adds 58 tokens to every session and 1,159 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
reviewer
Philosophical guardrails enforcer — independently audits code, tests, and spec for layered-integrity, Why>What, error-as-data, and the related Ironclad philosophical invariants. Activate only when the connected project contains spec.yaml or the user explicitly names Cladding; ignore ordinary requests in uninitialized…
plan-eng-review
Engineering plan review. Reviews a plan document for architecture, code quality, test coverage, and performance before implementation begins. Produces a coverage diagram, failure modes map, and parallelization strategy. Use when asked to "review this plan", "eng review", or "architecture review".
review
Pre-merge code review — the single canonical review of a change before it lands. Covers BOTH diff safety/structure (SQL safety, LLM trust-boundary violations, conditional side effects) AND engineering quality (architecture fit, edge cases, test coverage, performance). Use when asked to "review this PR", "code review"…
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements.
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation.
review
5-pass structured code review — correctness, security, performance, readability, consistency.