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 babyworm/rtl-agent-team --skill rtl-p4s-unit-testgit clone --depth 1 https://github.com/babyworm/rtl-agent-teamWrote 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/babyworm/rtl-agent-team/rtl-p4s-unit-test)<a href="https://agentmods.dev/skills/babyworm/rtl-agent-team/rtl-p4s-unit-test"><img src="https://agentmods.dev/badge/skills/babyworm/rtl-agent-team/rtl-p4s-unit-test/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/babyworm/rtl-agent-team/rtl-p4s-unit-test"><img src="https://agentmods.dev/badge/skills/babyworm/rtl-agent-team/rtl-p4s-unit-test.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.00043 | $0.00730 |
| Opus 5.5 | $0.00017 | $0.00292 |
| Sonnet 5.5 | $0.00009 | $0.00146 |
| Haiku 4.5 | $0.00004 | $0.00073 |
Grade A, and why
rtl-p4s-unit-test 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 15d 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 — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing Tier Context:
Tier 1: Smoke Test — connectivity, R/W, basic ops (rtl-p4-implement Wave 6)
Tier 2: Unit Test — reference comparison, uarch features (THIS SKILL) ←
Tier 3: Module Regr. — cocotb multi-seed (rtl-p5s-func-verify)
Tier 4: Integration — cross-module, end-to-end (rtl-p5s-integration-test)
Outputs: sim/{module}/tb_{module}.sv testbench files + sim/{module}/{module}_unit_results.json.
<Use_When>
- Phase 4 RTL is lint-clean AND Tier 1 smoke test passed (rtl-p4-implement Wave 6)
- Each module needs uarch-level functional verification with reference comparison
- A new module's key features need targeted testing beyond connectivity
- A bug fix needs regression test verifying the fix against reference model </Use_When>
<Do_Not_Use_When>
- Only basic connectivity/R/W verification needed (covered by rtl-p4-implement Wave 6 smoke — Tier 1)
- Full multi-seed regression needed (use rtl-p5s-func-verify — Tier 3)
- Integration/cross-module testing (use rtl-p5s-integration-test — Tier 4)
- Formal verification preferred (use rtl-p5s-sva-check instead) </Do_Not_Use_When>
<Why_This_Exists> Tier 1 (smoke) only verifies connectivity and basic I/O. Tier 2 unit tests verify that each module implements its uarch spec — FSM states, pipeline stages, data transformations — using the C reference model as the golden oracle. This catches behavioral bugs that smoke tests miss, while remaining faster and more targeted than full regression (Tier 3). </Why_This_Exists>
All coding conventions, reference mode rules, escalation criteria, and result schemas are defined in the rtl-p4s-unit-test-policy skill (loaded via the orchestrator's skills: field).
Execution
Task(subagent_type="rtl-agent-team:p4s-unit-test-orchestrator", prompt="Execute Tier 2 unit testing. User input: $ARGUMENTS")
Do not perform any work directly. The orchestrator agent manages testbench generation, simulation, and failure triage.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 15d ago First seen · 66 lines · 43 tokens per session scan A 536037db0a55
rtl-p4s-unit-test is a skill published in the GitHub repository babyworm/rtl-agent-team (61 stars, last pushed 16d ago), licensed MIT. It adds 43 tokens to every session and 730 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-10-08.
Other skills, from other repositories
test-sqrl
Use when adding or updating tests for a DataSQRL pipeline. Use after implementing features to verify correctness.
embedded-testing-patterns
Firmware test patterns with Unity, CMock, Ceedling, and QEMU: project layout, testable HAL interfaces, CMock expect chaining, error-path tests, and an on-target test runner over ITM. Use when making embedded C testable or writing tests for it.
mavlink-integration
Use this skill when a task involves MAVLink protocol communication via pymavlink, UART/UDP/TCP drone connections, ArduPilot SITL simulation, or telemetry message parsing in the edge service. Don't use it for raw UART hardware driver code without MAVLink framing (use embedded-systems), WebSocket transport to the web…
codexkit-test-hardening
Strengthen test coverage around changed behavior, edge cases, and regressions without writing noisy or brittle tests.
testing-business-rules
Use when adding, reviewing, or deleting tests, deciding whether a function needs coverage, or when a suite enumerates branches, signs, empty values, or implementation steps without naming the behavior at risk.
precommit
Run the deterministic pre-commit pipeline in fast or full mode through the packaged runner. Use when handing off repository changes. Not for: ad hoc replacement checks, dependency audits, or read-only verification. Output: runner-owned changed-file reporting and final verdict.