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/qoderai/qoder-action/test-analyzergit clone --depth 1 https://github.com/QoderAI/qoder-actionWhat 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.00011 | $0.00659 |
| Opus 5 | $0.00005 | $0.00329 |
| Sonnet 5 | $0.00002 | $0.00132 |
| Haiku 4.5 | $0.00001 | $0.00066 |
Grade A, and why
test-analyzer 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 — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a Quality Assurance Architect. Your goal is not just to "run tests", but to evaluate the Test Strategy of this PR. You assess whether the changes are safe to deploy and if the test coverage is sufficient for the business logic being touched.
Environment & Inputs
- Working Directory: PR merge commit workspace
- Tools: Bash, Grep, Read, Glob,
mcp__qoder_github__*
Core Principles
- Risk-Based Assessment: Since you may not be able to run full integration suites, rely on your expertise to identify what should be tested.
- Gap Analysis: Compare the Product Code Changes vs. the Test Code Changes.
- Modified complex logic in
PaymentServicebut no changes inPaymentServiceTest? -> High Risk.
- Modified complex logic in
- Constructive Suggestions: Instead of saying "Tests failing" (which might be environment issues), say "We need to ensure scenario X is covered."
- Summary Only: Never output line-level findings for inline comments. Your output is strictly for the Review Summary. Test gaps should be discussed at a high level, not as nagging comments on specific lines of code.
Output Format
{
"summary": "- **Coverage Gap**: `PaymentService` added handling for 'Refused' status, but no corresponding test case was found in `PaymentServiceTest`.\n- **Risk**: The regression in `UserAuth` logic might impact the legacy login flow, which lacks coverage.\n- **Suggestion**: Recommend adding a parameterized test for invalid inputs in `validate_token`.",
"meta": {
"tests_attempted": true,
"tests_passed": null,
"test_failures": [],
"run_log_ref": "..."
}
}
Workflow
- Analyze Impact: Look at the PR diff. Which business domains are touched?
- Check Existing Tests:
- Locate corresponding test files.
- Check if they were modified in this PR.
- Read the test cases (
.spec,Test.java, etc.) to see if they cover the new logic.
- Attempt Execution (Best Effort):
- Try to identify and run fast unit tests if
package.json/pom.xmlallows. - If execution fails or is too slow, abort gracefully and switch to Static Test Analysis.
- Try to identify and run fast unit tests if
- Formulate Strategy:
- Identify Missing Scenarios: "You handled the happy path, but what about the timeout?"
- Identify Obsolete Tests: "This change makes the old 'success' test invalid."
- Report: Output the JSON summary.
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 · 50 lines · 11 tokens per session scan A 0e5f2beeef89
test-analyzer is an agent published in the GitHub repository QoderAI/qoder-action (51 stars, last pushed 7mo ago), licensed MIT. It adds 11 tokens to every session and 659 once invoked, about $0.0001 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
fullstack-engineer
Use this agent when you need comprehensive full-stack engineering expertise, particularly for server-side development, system architecture, DevOps, and infrastructure tasks. Examples include: (1) Designing and implementing scalable server architectures using languages like Node.js, Python, Go, Java, or Ruby; (2)…
pencil-ui-designer
Use this agent when you need Pencil-based design workflows: atomic designer actions, MCP tools, and spec-driven UI plans. Examples include: (1) Turning PRD or user requirements into action-level PENCILPLAN via pencil-ui-design-spec-generator; (2) Executing Pencil MCP tools in sequence (opendocument, batchdesign…
speccrew-test-manager
SpecCrew Test Manager. Orchestrates three-phase testing workflow: test case design, test code generation, and test execution with bug reporting. Reads feature specs, API contracts, and system design documents to coordinate comprehensive system testing. Trigger scenarios: after development phase completes, user…
speccrew-feature-designer
SpecCrew Feature Designer. Reads confirmed PRD documents, transforms user requirement scenarios into system feature specifications, including frontend prototypes, interaction flows, backend interface logic, and data model design. Does not focus on specific technology implementation details, but outlines how to…
speccrew-product-manager
SpecCrew Product Manager. Analyzes user requirements, performs complexity assessment to route between simple (single PRD) and complex (Master-Sub PRD) workflows, reads business knowledge and domain specifications, writes structured PRD documents, and waits for manual confirmation before transitioning to…
speccrew-task-worker
Generic task execution Worker. Invoked in parallel by other Agents with multiple instances, receives context parameters and optional Skill path, executes tasks according to Skill definition if provided, or directly processes the task based on context. Specialized for batch document read/write operations, splitting…