agentleFS
p10ns11yp10ns11y/skills/bdd-strategizer/SKILL.md

bdd-strategizer

Skill2 starsChanged 40 days agoMITView on GitHub

Generic high-quality BDD/TDD strategist for complex projects of any size. Decomposes large refactors into core-first test slices, contract-first invariants, and safe incremental delivery. Triggers on BDD strategy, TDD plan complex, behavior-driven refactor, legacy migration, make this testable.

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 11 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Ensure vitest / jest + pnpm test:unit (or equivalent) works.

    line 24
  2. Very specific:

    Create contracts.ts (or invariants.test.ts) that encodes all critical behaviors from design docs, specs, or legacy behavior.

    line 25
  3. Very specific:

    Write *.contract.test.ts for every public interface, type, and response shape.

    line 29
  4. Very specific:

    Use describe.each or matrix testing over configuration/env variations.

    line 35
  5. Distinctive:

    Ensure new path falls back to old behavior on error.

    line 39
  6. Distinctive:

    Add preflight checks before any external calls or risky operations.

    line 40
  7. Distinctive:

    Ensure all test symbols are properly exported from barrels.

    line 44
  8. Distinctive:

    Remove duplicate function names and confusing exports.

    line 45
  9. Distinctive:

    Create a thin gateway/wrapper that owns caching, mode selection, and fallback.

    line 49
  10. Distinctive:

    Keep route/handler files minimal (ideally <15 lines).

    line 50
  11. Distinctive:

    Use temporary re-export shims during transition if needed.

    line 54
  12. Distinctive:

    Remove excessive meta-comments, PR references, and outdated documentation.

    line 55
  13. Distinctive:

    Keep only invariants, non-obvious workarounds, and clear decision records.

    line 56
  14. Distinctive:

    Use state machines (e.g. XState) only for complex client UX (streaming, retries, cancellation) — not for simple config/flags.

    line 61
  15. Distinctive:

    Add generation controls (token limits, temperature, style prompts) as a dedicated config module when relevant.

    line 62
  16. Very specific:

    When stuck: Run the unit test command with grep for contract|invariant|feature|golden and expand only the failing lowest-relevance slice.

    line 72

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

BDD Strategiser — Generic Core-First, Test-Driven

Activate on: any mention of BDD/TDD strategy, complex refactor planning, legacy migration, dual systems, stubs, or "make this testable".

Core Philosophy Turn big, risky refactors into small, verifiable, green slices with zero behavior change.

Immutable Principles

  • Red → green → refactor per slice. Never move to next slice until current is green.
  • Core-outward: start with harness + contracts, then stable core, then shell.
  • Design-doc / spec invariants first — encode every "must" as a contract test.
  • One source of truth for flags/config (never scattered env checks).
  • Stubs are temporary scaffolding — replace with real logic before moving on.
  • Production safety first: preflight checks + fallback paths before any risky change.

Generic Strategy Playbook

Phase 0 — Test Harness (Mandatory First Step)

  • Ensure vitest / jest + pnpm test:unit (or equivalent) works.
  • Create contracts.ts (or invariants.test.ts) that encodes all critical behaviors from design docs, specs, or legacy behavior.
  • Make pnpm test:unit the single source of truth for the refactor.

Slice 1 — Contracts (Types + Public API)

  • Write *.contract.test.ts for every public interface, type, and response shape.
  • Fail fast on any drift from legacy contracts or design specifications.

Slice 2 — Core Journey (User Flow)

  • Break the feature into major steps of the user journey.
  • One test file (.feature.test.ts or *.contract.test.ts) per major step.
  • Use describe.each or matrix testing over configuration/env variations.

Slice 3 — Safety & Fallbacks

  • Explicitly test dual-path / legacy + new path behavior.
  • Ensure new path falls back to old behavior on error.
  • Add preflight checks before any external calls or risky operations.

Slice 4 — Stubs → Real Implementation

  • Merge or replace stub modules with real logic.
  • Ensure all test symbols are properly exported from barrels.
  • Remove duplicate function names and confusing exports.

Slice 5 — Orchestration & Gateway

  • Extract orchestration logic into clean pipeline stages (discriminated unions preferred).
  • Create a thin gateway/wrapper that owns caching, mode selection, and fallback.
  • Keep route/handler files minimal (ideally <15 lines).

Slice 6 — Structure & Hygiene (Last Step)

  • Perform folder reorganization only after all tests are green.
  • Use temporary re-export shims during transition if needed.
  • Remove excessive meta-comments, PR references, and outdated documentation.
  • Keep only invariants, non-obvious workarounds, and clear decision records.

For Highly Complex Projects

  • First map all pain points (duplicate names, stub drift, stale docs, tangled dependencies).
  • Shape folders around user flow, not technical layers.
  • Use state machines (e.g. XState) only for complex client UX (streaming, retries, cancellation) — not for simple config/flags.
  • Add generation controls (token limits, temperature, style prompts) as a dedicated config module when relevant.
  • Maintain a "Production vs Branch" matrix in README before any deployment.

Required Output Format (Always Use This)

  1. One-sentence goal + key risk controls
  2. Phased todo list (with id, description, and test type)
  3. Mermaid diagram of the current slice / flow
  4. Exact command to run tests after the phase
  5. "Fusion surplus" — one concrete change that will reduce future token/effort cost by 3× or more

When stuck: Run the unit test command with grep for contract|invariant|feature|golden and expand only the failing lowest-relevance slice.

Never do:

  • Big-bang moves
  • Implement code before writing the contract test
  • Ignore documented invariants or design specs

This generic strategist turns any large, messy codebase into clean, testable, incrementally delivered slices while protecting production behavior.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.