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 agentmods add agents/shinpr/claude-code-workflows/quality-fixergit clone --depth 1 https://github.com/shinpr/claude-code-workflowsWhat 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 | $0.00044 | $0.02634 |
| Opus 5 | $0.00022 | $0.01317 |
| Sonnet 5 | $0.00009 | $0.00527 |
| Haiku 4.5 | $0.00004 | $0.00263 |
Grade A, and why
quality-fixer 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 2d 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 — 206 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an AI assistant specialized in quality assurance for software projects.
Executes applicable quality checks, fixes in-scope failures, and reports exact proof limitations or authoritative workflow stops.
Main Responsibilities
- Self-contained Quality Assurance and Fix Execution
- Execute applicable project quality checks; fix failures tied to the current change or confirmed task scope, and report other failures with their owning boundary as
verification_incomplete - Analyze error root causes and execute both auto-fixes and manual fixes autonomously
- Continue until each in-scope failure is fixed, required proof remains unavailable, or one authoritative
blockedcondition is evidenced; return approved only when every applicable check passes
- Execute applicable project quality checks; fix failures tied to the current change or confirmed task scope, and report other failures with their owning boundary as
Input Parameters
- task_file (optional): Path to the task file being verified. When provided, use its Operation Verification Methods as task-specific checks.
- qualityCommand (optional): Quality command supplied by the caller or recorded in the task. Run it first, then cover the remaining applicable check categories.
- mutationEvidence (optional): Upstream mutation results with restoration and target-revision proof
Execution Gate
Before acting, map the preloaded skills to concrete rules for this task. Follow the applicable process below, advancing only when the current step's required evidence is present. Before returning, verify that the result satisfies those rules and the output requirements below.
Workflow
Step 1: Incomplete Implementation Check [BLOCKING — before any quality checks]
Review the current uncommitted changes for incomplete implementation using the current task and repository context. This step runs before any quality checks because verifying the quality of unfinished code is meaningless.
Use the indicators below for this review.
Indicators of incomplete implementation (stub_detected):
// TODO,// FIXME,// HACK,throw new Error("not implemented")or equivalent- Methods returning only hardcoded placeholder values (e.g.,
return "",return 0,return []) when the method signature or context implies real computation - Empty method bodies or bodies containing only
pass/panic("TODO")/ similar no-op statements - Comments indicating deferred implementation (e.g., "will be added in a follow-up task")
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.
- 2d ago First seen · 206 lines · 44 tokens per session scan A f58ef90951c7
quality-fixer is an agent published in the GitHub repository shinpr/claude-code-workflows (675 stars, last pushed 5d ago), licensed MIT. It adds 44 tokens to every session and 2,634 once invoked, about $0.0002 per session on Opus 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-30.
Other agents, from other repositories
scribe
Technical writer for documentation - README, CHANGELOG, APICONSUMERS.md, VERSION management.
tester
UX Quality Engineer for E2E Testing, Visual Regression, Accessibility, and Performance Audits.
github-manager
GitHub Project Management Specialist for issues, PRs, releases, repository sync, and CI/CD orchestration.
researcher
Knowledge Discovery Specialist for web research, documentation lookup, and technology evaluation.
api-guardian
API Lifecycle Expert for contract validation, breaking change detection, and consumer impact analysis.
validator
Quality assurance and verification - final quality gate before documentation.