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/codeforusers/odoo-dev-superskill/testing-behaviorgit clone --depth 1 https://github.com/CodeForUsers/odoo-dev-superskillWhat 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.00000 | $0.00352 |
| Opus 5 | $0.00000 | $0.00176 |
| Sonnet 5 | $0.00000 | $0.00070 |
| Haiku 4.5 | $0.00000 | $0.00035 |
Grade A, and why
testing-behavior 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.
What it actually says
Testing Behavior
Purpose
Define how the agent should behave when a task involves tests, validation strategy, coverage, and quality assurance for Odoo modules.
When to activate
- The user asks for tests.
- The task touches business-critical logic.
- The module is being prepared for publication, migration, or review.
- A change affects permissions, imports, sync flows, computed fields, or UI logic.
Pre-checks
- Identify whether tests already exist.
- Identify critical flows that require regression protection.
- Determine whether the task needs unit, transactional, integration, or UI-adjacent validation.
- Check whether test data/setup already exists.
Workflow
- Identify the risk introduced by the change.
- Decide what must be tested first.
- Prefer meaningful tests over superficial coverage inflation.
- Cover security-sensitive and business-critical flows first.
- Add regression tests for every fixed bug when possible.
- Keep tests maintainable and tied to actual behavior.
- Avoid overly brittle tests tied to unstable UI details unless necessary.
Rules
- Tests are part of the feature, not a final optional phase.
- Cover business rules before edge formatting details.
- Prioritize regression protection.
- Tests should explain expected behavior.
- Coverage percentage is useful, but not a substitute for relevance.
Avoid
- Dummy tests that assert nothing meaningful.
- Chasing coverage numbers with trivial assertions.
- Ignoring tests on permissions, imports, migrations, and connectors.
- Huge monolithic tests that validate too many concerns at once.
- UI-fragile tests when backend assertions are enough.
Related references
references/testing.mdreferences/maturity-levels.mdreferences/version-matrix.md
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 · 45 lines · 0 tokens per session scan A 894bc3e50132
testing-behavior is an agent published in the GitHub repository CodeForUsers/odoo-dev-superskill (11 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 352 tokens. 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
debugger
Debugging specialist for errors and test failures. Use when encountering build errors, runtime exceptions, test failures, or unexpected behavior. Invoke with /debugger to investigate issues.
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.
ijfw-assumptions-analyzer
Use when surfacing hidden assumptions in a brief or plan before execution begins -- what does the plan assume that the spec doesn't guarantee?
ijfw-accessibility-reviewer
Design-phase WCAG 2.1 AA review of UI artefacts: contrast, semantics, focus, ARIA. Trigger per design review pass.
refactor
Use when code has grown complex, has duplication, violates patterns, or needs restructuring - from code smells to architecture-level refactoring.
marketing
Use when creating marketing copy, landing pages, email campaigns, social media strategy, SEO content, or growth experiments.