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 hmj1026/dhpk --skill tdd-workflowgit clone --depth 1 https://github.com/hmj1026/dhpkWrote 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/hmj1026/dhpk/tdd-workflow)<a href="https://agentmods.dev/skills/hmj1026/dhpk/tdd-workflow"><img src="https://agentmods.dev/badge/skills/hmj1026/dhpk/tdd-workflow/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/hmj1026/dhpk/tdd-workflow"><img src="https://agentmods.dev/badge/skills/hmj1026/dhpk/tdd-workflow.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.00108 | $0.01493 |
| Opus 5.5 | $0.00043 | $0.00597 |
| Sonnet 5.5 | $0.00022 | $0.00299 |
| Haiku 4.5 | $0.00011 | $0.00149 |
Grade A, and why
tdd-workflow 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 yesterday.
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 — 133 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
Select the work
Choose the mode from the requested outcome, rather than the agent's name:
- Standard TDD: own a feature or bug's test-first behavior change.
- Test-generation: produce tests or a scaffold for a named production seam; keep production code unchanged unless implementation is separately requested.
- Worker handback: perform a bounded GREEN or scaffold task using the settled owner's seam, target files, and verification command.
For Playwright journeys use e2e-runner; for a post-hoc coverage or acceptance
audit use change-verdict. Documentation, formatting, rename-only, and harness
configuration work without testable runtime behavior need no TDD loop.
Read tests.md when choosing assertions and mocking.md
when introducing test doubles. Use the repository's existing test framework,
runner, and nearby conventions. Read CONTEXT.md and relevant ADRs when present
before choosing domain vocabulary or a new seam.
Establish the seam and evidence
- Identify the caller-visible behavior and its public API, command, event, or other boundary. Reuse the requested or approved seam and its existing test owner; ask only about a material missing behavior or constraint.
- Find the smallest safe verification command. Keep tests isolated from shared services and data unless their use is explicitly authorized.
- Check supplied RED/GREEN evidence against the current behavior, test, seam, and source revision. Reuse adequate evidence without repeating approvals; rerun the scoped command when the source or test has drifted, or the failure reason is missing. An old failure alone does not establish current RED.
Choose inline work or a worker handback from ownership, coupling, runtime
expertise, and material risk; file count alone does not decide the route.
Resolve a missing specialist outcome with tdd-guide when separate expertise
is needed. Explicit Host, user, acceptance, and higher-priority requirements
for that role remain binding. If the required role or runtime is unavailable,
report BLOCKED and the action needed to resume. An equivalent capable owner
may proceed only when applicable instructions allow it. In dhpk,
rules/execution-policy.md owns dispatch and ownership decisions.
What ships with it
16 files 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.
- agents/openai.yaml 183 B
- distribution.yaml 1.8 KB
- references/dhpk-legacy-characterization-tests/agents/openai.yaml 283 B
- references/dhpk-legacy-characterization-tests/distribution.yaml 1.3 KB
- references/dhpk-legacy-characterization-tests/evals/evals.json 4.5 KB
- references/dhpk-legacy-characterization-tests/SKILL.md 9.6 KB
- references/mocking.md 1.3 KB
- references/phpunit/agents/openai.yaml 241 B
- references/phpunit/distribution.yaml 677 B
- references/phpunit/references/10.md 7.2 KB
- references/phpunit/references/11.md 7.2 KB
- references/phpunit/references/9.md 8.4 KB
- references/phpunit/scripts/resolve-version.js 1.8 KB runs code
- references/phpunit/scripts/version-resolver.js 7.9 KB runs code
- references/phpunit/SKILL.md 3.9 KB
- references/tests.md 5.3 KB
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.
- yesterday Changed · +8 lines 1876c34745dc
- 2d ago Changed · -33 lines · -6 tokens per session 2654f2ca1b0e
- 10d ago Changed · +17 lines · +7 tokens per session a439a62c32d6
- 15d ago Changed · -2 lines 9813fcbf207b
- 23d ago First seen · 143 lines · 107 tokens per session scan A 50fbe593c279
tdd-workflow is a skill published in the GitHub repository hmj1026/dhpk (2 stars, last pushed today), licensed MIT. It adds 108 tokens to every session and 1,493 once invoked, about $0.0004 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-09-24.
Other skills, from other repositories
opsx:tdd
Adds a TDD gate to OpenSpec — write REAL failing tests from specs//.md before implementation. Run after opsx:propose and before opsx:apply. Solid RED — never expect.fail placeholders.
tdd
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
tdd-with-phpunit
Apply RED-GREEN-REFACTOR with PHPUnit 10/11 for Symfony; KernelTestCase/WebTestCase, attributes (#[Test]/#[DataProvider]), Foundry.
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code.
tdd
Use when writing production code that needs tests -- new features, bug fixes, refactoring. Enforces RED-GREEN-REFACTOR before implementation.
nested-fixture-pattern
This skill should be used when working on Java projects with JUnit tests that have layered preconditions, expensive shared setup (servers, databases, provisioned users), or complex scenario trees. Trigger phrases include "nested fixture", "fixture pattern", "scenario tree", "layered test setup", or when the user is…