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 skills/prowler-cloud/prowler/tddnpx skills add prowler-cloud/prowler --skill tddgit clone --depth 1 https://github.com/prowler-cloud/prowlerWrote 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/prowler-cloud/prowler/tdd)<a href="https://agentmods.dev/skills/prowler-cloud/prowler/tdd"><img src="https://agentmods.dev/badge/skills/prowler-cloud/prowler/tdd.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 | $0.00050 | $0.02308 |
| Opus 5 | $0.00025 | $0.01154 |
| Sonnet 5 | $0.00010 | $0.00462 |
| Haiku 4.5 | $0.00005 | $0.00231 |
Grade A, and why
tdd 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 4d 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 — 372 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD Cycle (MANDATORY)
+-----------------------------------------+
| RED -> GREEN -> REFACTOR |
| ^ | |
| +------------------------+ |
+-----------------------------------------+
The question is NOT "should I write tests?" but "what tests do I need?"
The Three Laws of TDD
- No production code until you have a failing test
- No more test than necessary to fail
- No more code than necessary to pass
Detect Your Stack
Before starting, identify which component you're working on:
| Working in | Stack | Runner | Test pattern | Details |
|---|---|---|---|---|
ui/ |
TypeScript / React | Vitest + RTL | *.test.{ts,tsx} (co-located) |
See vitest skill |
prowler/ |
Python | pytest + moto | *_test.py (suffix) in tests/ |
See prowler-test-sdk skill |
api/ |
Python / Django | pytest + django | test_*.py (prefix) in api/src/backend/**/tests/ |
See prowler-test-api skill |
Phase 0: Assessment (ALWAYS FIRST)
Before writing ANY code:
UI (ui/)
# 1. Find existing tests
fd "*.test.tsx" ui/components/feature/
# 2. Check coverage
pnpm test:coverage -- components/feature/
# 3. Read existing tests
SDK (prowler/)
# 1. Find existing tests
fd "*_test.py" tests/providers/aws/services/ec2/
# 2. Run specific test
uv run pytest tests/providers/aws/services/ec2/ec2_ami_public/ -v
# 3. Read existing tests
API (api/)
# 1. Find existing tests
fd "test_*.py" api/src/backend/api/tests/
# 2. Run specific test
uv run pytest api/src/backend/api/tests/test_models.py -v
# 3. Read existing tests
Decision Tree (All Stacks)
+------------------------------------------+
| Does test file exist for this code? |
+----------+-----------------------+-------+
| NO | YES
v v
+------------------+ +------------------+
| CREATE test file | | Check coverage |
| -> Phase 1: RED | | for your change |
+------------------+ +--------+---------+
|
+--------+--------+
| Missing cases? |
+---+---------+---+
| YES | NO
v v
+-----------+ +-----------+
| ADD tests | | Proceed |
| Phase 1 | | Phase 2 |
+-----------+ +-----------+
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.
- 4d ago First seen · 372 lines · 50 tokens per session scan A 5b10ba7a75d9
tdd is a skill published in the GitHub repository prowler-cloud/prowler (14,748 stars, last pushed today), licensed Apache-2.0. It adds 50 tokens to every session and 2,308 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 skills, from other repositories
ponytail-sec-audit
Full project security audit. Scans the entire codebase across three passes: code that shouldn't exist, all dependencies assessed, all hardening findings. Produces a comprehensive numbered report with blast-radius narrative. Persists findings to .ponytail-sec/ for cross-scan tracking. For per-diff review use…
ponytail-sec
Security companion for active development. Scopes to the current diff or changed files. Three passes: YAGNI code review, new-dep assessment, and up to 3 material hardening findings. Lean by design — surfaces the one thing to fix before merging, not a backlog. Use ponytail-sec-audit for a full project scan.
tunnel-manager-ssh-hardening
Harden and audit SSH access across a host fleet via the tunnel-manager MCP server — set up passwordless key auth, build a full-mesh trust, rotate SSH keys fleet-wide, distribute a shared ssh config, and run security / compliance / vulnerability audits against a host. Use when the agent must move a fleet off password…
dockerfile
Binary Dockerfile image-build hardening check. Use when reviewing Dockerfiles, container image builds, multi-stage builds, runtime users, pinned bases, or reproducible dependency installs. Minimal output only: OK or NOTOK: RULE, RULE.
k8s-securitycontext
Binary Kubernetes securityContext hardening check. Use when reviewing Pods, Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Helm templates, or Kubernetes manifests that define containers. Minimal output only: OK or NOTOK: RULE, RULE.
cis-aws-database-3.11
Ensure to Regularly Review Security Configuration.