agentsclimarketplace

Hyper tdd

Skill zeikar/hyperclaude/skills/hyper-tdd

Use when about to write or modify behavior-bearing code — functions, business logic, bug fixes — before writing any production code. Also when the user invokes /hyperclaude:hyper-tdd. Forces a failing test first so you watch it fail for the right reason.From its SKILL.md

Install
npx -y skills add zeikar/hyperclaude --skill hyper-tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

1.6 KB, 339 tokens by cl100k_base, as published. Nobody here has run it

hyper-tdd

Test-driven discipline tailored to this author's preferences.

The loop

  1. Write the failing test first. Name the behavior, not the implementation. The test should compile/import but fail because the behavior doesn't exist yet.
  2. Run it. Confirm it fails for the right reason. "Cannot find function" is fine. "ReferenceError because of typo in test" is not — fix the test.
  3. Write the minimum code to make it pass. Resist scope creep. No "while I'm here" edits.
  4. Run it. Confirm it passes.
  5. Commit. One behavior, one commit. Commit messages describe the behavior, not the code.
  6. Refactor if there's a clear smell. Tests must still pass after.

Skip TDD when

  • Touching only documentation, comments, or formatting.
  • Renaming a symbol (an LSP/grep operation, not a behavior change).
  • One-shot migration scripts that run once and get deleted.
  • Config-only changes (e.g., updating a .gitignore).

What "minimum" means here

Implement only what the current test requires. If you need a helper, add the simplest version. Do not pre-build for tests you might write later — write that test first, then the helper.

What good test names look like

  • slugify drops non-ASCII characters
  • cli --dry-run prints JSON without spawning codex
  • test_slugify (says nothing)
  • slugify works correctly (vague)

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in 339 tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

  • Use third-person for skill descriptionsin 54 of 1951, across 35 files
  • Start descriptions with Use whenin 43 of 1951, across 29 files
  • Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
  • Use active voicein 40 of 1951, across 36 files
  • Map file responsibilities before defining tasksin 36 of 1951, across 29 files
  • Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
  • Ask one question at a timein 35 of 1951
  • Offer execution options after saving the planin 33 of 1951, across 24 files
  • Include complete code in every stepin 33 of 1951, across 27 files
  • Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
  • Announce the skill usage at the startin 30 of 1951
  • Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

  • Commit one behavior per commit
  • Refactor code only if there is a smell

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.