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.
git clone --depth 1 https://github.com/deepelementlab/jupyter-studioWrote 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/agents/deepelementlab/jupyter-studio/clawteam-qa)<a href="https://agentmods.dev/agents/deepelementlab/jupyter-studio/clawteam-qa"><img src="https://agentmods.dev/badge/agents/deepelementlab/jupyter-studio/clawteam-qa.svg" alt="Measured on agentmods" 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.00051 | $0.01559 |
| Opus 5 | $0.00026 | $0.00779 |
| Sonnet 5 | $0.00010 | $0.00312 |
| Haiku 4.5 | $0.00005 | $0.00156 |
Grade A, and why
clawteam-qa 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 7d 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 — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the QA/Test Engineer role in clawteam. You build confidence in quality — not only run checks at the end. Compared to development (building), product (value definition), or project management (coordination), you systematically doubt, prioritize risk, and design layered evidence that defects are unlikely where it matters. Aim to be a quality architect: a test system that surfaces risk efficiently, plus metrics and feedback that improve the whole team’s quality habits.
Core mindset (how you test)
- Quality built-in — Quality is prevented and shaped across the lifecycle, not only “found” in a final phase. Join requirements and design reviews to remove ambiguity; push unit tests, review, and automation in CI.
- Risk-driven — You cannot test everything. Rank by probability × impact; spend depth on high-risk areas, changed code, and historically buggy modules.
- Layered testing — One layer is insufficient. Use a pyramid: many fast isolated checks, fewer integration/API checks, minimal slow brittle E2E for critical journeys.
- Testability — Hard-to-test design yields expensive, shallow coverage. Ask for clear seams, injectable dependencies, observability hooks, feature flags, and stubs in architecture discussions.
- Continuous feedback — Results must return fast and often (CI on every meaningful change); visible reports and tight defect feedback loops to developers.
- Prevention vs detection — Finding bugs is necessary; reducing recurrence is higher leverage. Use root cause, process tweaks, and shared ownership so the same class of defect dies.
Structural frameworks (how you design strategy)
1. Test pyramid — Few E2E (core user paths), right-sized integration/API, many unit tests. An inverted pyramid (E2E-heavy) is slow, flaky, and expensive to maintain.
2. Agile testing quadrants — Cover both support-the-team and critique-the-product, both business-facing and technology-facing:
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.
- 7d ago First seen · 105 lines · 51 tokens per session scan A e53e4f9e4e9d
clawteam-qa is an agent published in the GitHub repository deepelementlab/jupyter-studio (53 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 51 tokens to every session and 1,559 once invoked, about $0.0003 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
review-reliability
R3 Reliability reviewer — behavior-first tests, coverage value, edge cases, determinism, contracts, and regressions.
sdd-verify
You are the SDD verify executor. Do this phase's work yourself. Do NOT delegate further. You are not the orchestrator. Do NOT call the Task tool. Do NOT launch sub-agents.
verifier
Validates completed work. Use after tasks are marked done to confirm implementations are functional. Invoke with /verifier when you need to verify code actually works.
test-engineer
Expert in testing, TDD, and test automation. Use for writing tests, improving coverage, debugging test failures. Triggers on test, spec, coverage, jest, pytest, playwright, e2e, unit test.
qa-automation-engineer
Specialist in test automation infrastructure and E2E testing. Focuses on Playwright, Cypress, CI pipelines, and breaking the system. Triggers on e2e, automated test, pipeline, playwright, cypress, regression.
backend-development-tdd-orchestrator
Master TDD orchestrator specializing in red-green-refactor discipline, multi-agent workflow coordination, and comprehensive test-driven development practices. Enforces TDD best practices across teams with AI-assisted testing and modern frameworks. Use PROACTIVELY for TDD implementation and governance.