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.
In this repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adversarial-auditSkill
- agentic-reactorSkill
- agent-orchestratorSkill
- ai-optimizationSkill
- architecture-synthesisSkill
- audit-allow-buildsSkill
- audit-ide-dependenciesSkill
- author-workflow-skillSkill
- chrome-extension-mv3Skill
- concurrent-cli-agentsSkill
- control-feederSkill
- control-graphSkill
- cursor-transcript-harvestSkill
- cv-promote-guardSkill
- devcontainer-hardenedSkill
- dual-copy-skill-publishSkill
- explore-repo-readonlySkill
- finder-reactorSkill
- fix-dependency-securitySkill
- fusion-sageSkill
- git-worktreesSkill
- grok-host-prepSkill
- gt-flowSkill
- higher-order-decision-architectSkill
- looperSkill
- master-plannerSkill
- mvu-refactor-planSkill
- odysseus-navigatorSkill
- project-editor-profileSkill
- react-client-expertSkill
- semantic-markup-cssSkill
- semantic-nameSkill
- session-unit-orderSkill
- shell-kernel-ontologySkill
- skill-rename-propagationSkill
- split-to-prsSkill
- src-tree-reorganizeSkill
- stellar-roadmapSkill
- stellar-spacemapSkill
- subagent-delegationSkill
- subagent-explore-reportSkill
- supply-chain-hardenSkill
- tauri-agenticSkill
- tauri-ipc-debugSkill
- tidy-commit-pushSkill
- upgrade-packagesSkill
- verification-cockpitSkill
- x-agent-resourcesSkill
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
- Very specific: line 24
Ensure vitest / jest + pnpm test:unit (or equivalent) works.
- Very specific: line 25
Create contracts.ts (or invariants.test.ts) that encodes all critical behaviors from design docs, specs, or legacy behavior.
- Very specific: line 29
Write *.contract.test.ts for every public interface, type, and response shape.
- Very specific: line 35
Use describe.each or matrix testing over configuration/env variations.
- Distinctive: line 39
Ensure new path falls back to old behavior on error.
- Distinctive: line 40
Add preflight checks before any external calls or risky operations.
- Distinctive: line 44
Ensure all test symbols are properly exported from barrels.
- Distinctive: line 45
Remove duplicate function names and confusing exports.
- Distinctive: line 49
Create a thin gateway/wrapper that owns caching, mode selection, and fallback.
- Distinctive: line 50
Keep route/handler files minimal (ideally <15 lines).
- Distinctive: line 54
Use temporary re-export shims during transition if needed.
- Distinctive: line 55
Remove excessive meta-comments, PR references, and outdated documentation.
- Distinctive: line 56
Keep only invariants, non-obvious workarounds, and clear decision records.
- Distinctive: line 61
Use state machines (e.g. XState) only for complex client UX (streaming, retries, cancellation) — not for simple config/flags.
- Distinctive: line 62
Add generation controls (token limits, temperature, style prompts) as a dedicated config module when relevant.
- Very specific: line 72
When stuck: Run the unit test command with grep for contract|invariant|feature|golden and expand only the failing lowest-relevance slice.
≈ “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.
Files
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(orinvariants.test.ts) that encodes all critical behaviors from design docs, specs, or legacy behavior. - Make
pnpm test:unitthe single source of truth for the refactor.
Slice 1 — Contracts (Types + Public API)
- Write
*.contract.test.tsfor 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.tsor*.contract.test.ts) per major step. - Use
describe.eachor 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)
- One-sentence goal + key risk controls
- Phased todo list (with id, description, and test type)
- Mermaid diagram of the current slice / flow
- Exact command to run tests after the phase
- "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.
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
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.

