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-p4-implement-policygit 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-p4-implement-policy)<a href="https://agentmods.dev/skills/babyworm/rtl-agent-team/rtl-p4-implement-policy"><img src="https://agentmods.dev/badge/skills/babyworm/rtl-agent-team/rtl-p4-implement-policy/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-p4-implement-policy"><img src="https://agentmods.dev/badge/skills/babyworm/rtl-agent-team/rtl-p4-implement-policy.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.00023 | $0.04087 |
| Opus 5.5 | $0.00009 | $0.01635 |
| Sonnet 5.5 | $0.00005 | $0.00817 |
| Haiku 4.5 | $0.00002 | $0.00409 |
Grade A, and why
rtl-p4-implement-policy 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 — 306 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Phase 4 Implementation Policy
10-Wave Pipeline Definition
Wave 0: Prepare — **Wave 0: Preparation + Test Plan**
- Step 0a: Module enumeration, directory creation, TODO list (existing)
- Step 0b: Test plan generation per module via test-plan-writer agent
- Gate: sim/{module}/{module}_test_plan.md exists for every module
- Failure: retry once, then proceed with WARNING (Wave 6a must generate missing plans)
Wave 1: Write All — One rtl-coder per module, all parallel
Wave 2: Lint All — One lint-checker per module, all parallel, collect results
Wave 3: Fix Lint — ONLY FAIL modules, max 3 rounds, re-lint only fixes
Wave 3.5: Synth Gate — synthesizability-gate per lint-clean module, parallel (HARD GATE:
zero inferred latches / incomplete assignments / non-synth constructs, AND
DC-script-emittable; max 2 fix rounds, then rtl-architect escalation)
Wave 4: Code Review — rtl-critic per lint-clean module, parallel
Wave 5: Bugfix — ONLY REVIEW_FAIL modules, max 3 review→fix iterations
Wave 6a: Tier 1 Smoke — testbench-dev + eda-runner per module, parallel
Wave 6b: Tier 2 Unit — Ref model comparison, REQ-U-* tracing, FSM >= 50%, line >= 60%, covergroups >= 1, codec conformance PASS/N/A
Wave 7: Module CDC — cdc-checker per multi-domain module, parallel
Wave 8: Module Proto — protocol-checker per bus-interface module, parallel
Wave 9: Refactoring — rtl-p4s-refactor for flagged modules, selective
Wave 10: Integration — smoke test + spec compliance + Stream B + Phase 4 gate
Key principles:
- "Lint all at once, fix only failures, re-lint only fixes"
- "Code review before testing — catch design bugs early"
- "Module-level CDC/protocol before Phase 5 — catch hazards early"
- "Stream B synthesis smoke test — catch latch inference and unmappable constructs before Phase 5"
- Modules that pass early waves start later waves immediately
Wave Overlap Rules
Owned by the wave sequencer: see "Wave Overlap Rules" in the p4-implement-orchestrator agent prompt (modules progress through waves independently per that schedule).
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 · 306 lines · 23 tokens per session scan A 796bf15ca9e0
rtl-p4-implement-policy is a skill published in the GitHub repository babyworm/rtl-agent-team (61 stars, last pushed 16d ago), licensed MIT. It adds 23 tokens to every session and 4,087 once invoked, about $0.0001 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.