Skip to content
cccskills
FreePublished on GitHub

skill-tdd

Develop behavior changes by first observing an expected test failure, then making the smallest passing implementation. Refactor with tests passing, and document preserved behavior and measured runtime whenever tests are consolidated.

OriginalShow the original description

Build a behavior change with observed red, minimal green, and measured test consolidation

See how to install

Good for

  • Add behavior through a failing test
  • Fix a bug with a test that reproduces it
  • Refactor while keeping affected tests passing
  • Consolidate tests with evidence and timing measurements

Files included (2)

  • SKILL.md3.1 KB
  • agents/openai.yaml164 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than /octo:* slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, see skills/blocks/codex-host-adapter.md.

Test-driven development

Read skills/blocks/engineering-method-selection.md from the installed plugin for review admission. Natural-language requests and --peer-review share that policy. Honor host-only requests; risk alone does not authorize paid usage.

Run the red, green, and refactor cycle on the current host. Routine TDD makes zero additional provider dispatches. Use one external reviewer only when the user passes --peer-review, explicitly requests independent review, or an existing risk policy requires it. Explicit debate, council, and multi-model commands retain their own execution contracts.

<HARD-GATE> NO PRODUCTION BEHAVIOR CHANGE WITHOUT AN OBSERVED, EXPECTED FAILING TEST FIRST. </HARD-GATE>

The rule

Do not change production behavior until a focused test fails for the expected reason. Existing implementation outside the requested change remains intact.

  1. Name the observable behavior and the smallest public boundary that proves it.
  2. Write one focused test. Directly test an internal invariant only when the public boundary cannot isolate its failure mode.
  3. Run it and record the expected failure, command, and exit status.
  4. Implement the smallest change that passes.
  5. Run the focused test, then the affected suite.
  6. Refactor only while the tests remain green.

If a test passes before implementation, it is not red evidence. If it errors due to fixture or syntax problems, repair the test until it fails on the missing behavior.

Consolidating tests

Do not equate similar assertions with duplicate guarantees. Keep separate OS, security, cancellation, and integration boundaries. For every removed test, record old_test, behavior, replacement, mutant, red_observed, baseline_ms, candidate_ms, and reason. The retained test must kill the named mutant at the intended caller boundary.

After one warm-up, measure five isolated runs and report every sample and the median. Review a slowdown only when it exceeds both 20 percent and 100 ms.

Completion requires observed red and green evidence, affected-suite results, and the consolidation ledger when tests were removed. A missing reviewer is reported as incomplete review, never simulated.

Strategy rotation

If the same test remains red after two implementation attempts, stop and recheck the test boundary, fixture, and expected behavior. The strategy-rotation hook is a signal to try a fundamentally different hypothesis, not another variation of the same patch.

Adapted from DEEPENING in mattpocock/skills at commit 3cca18b368ae95cdbdebbff572ccafa662551015 under the MIT License. See THIRD_PARTY_NOTICES.md.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

council-verdicts

FreeSummary

Interpret the saved results of a completed AI council review. Count verdicts, check whether enough participants responded and whether models are independent, surface substantive dissent, and explain what action the outcome supports.

  • Explain a completed council review
  • Check vote counts and quorum
  • Assess model independence and dissent
nyldn/claude-octopus4.3KUpdated Oct 19, 2026

debate-kickoff

FreeSummary

Turn a technical choice into a structured debate between different AI model families. Assign explicit positions, launch the discussion, and summarize agreement, disagreement, and a recommendation supported by the strongest argument that survives the debate.

  • Compare Redis and Memcached for session storage
  • Debate monorepo versus polyrepo organization
  • Examine a technical choice from opposing positions
nyldn/claude-octopus4.3KUpdated Oct 19, 2026

flow-define

FreeSummary

Clarify a feature’s requirements with multiple AI providers, combining technical constraints with user and business needs. Produce a scoped definition covering priorities, edge cases, exclusions, and a requirements checklist before implementation begins.

  • Defining requirements for a user authentication system
  • Setting boundaries for a notification feature
  • Identifying technical constraints and edge cases
nyldn/claude-octopus4.3KUpdated Oct 19, 2026

flow-deliver

FreeSummary

Review code or documents with available AI providers before delivery. Combine findings into a scored validation report that checks prior requirements and decisions, separates critical issues from warnings, and recommends next steps.

  • Review authentication code before release
  • Check API readiness before deployment
  • Review a PRD for missing requirements
nyldn/claude-octopus4.3KUpdated Oct 19, 2026

flow-develop

FreeSummary

Develop complex features or business documents by gathering approaches from available AI providers. Combine their perspectives with prior project decisions and quality checks to produce a proposed plan, then proceed with implementation after user confirmation.

  • Planning and implementing a complex feature
  • Comparing approaches for an external service integration
  • Developing a product requirements document or strategy
nyldn/claude-octopus4.3KUpdated Oct 19, 2026

flow-discover

FreeSummary

Research technical or business questions through multiple available AI providers, each assigned a different perspective. Combine usable results into a report covering findings, disagreements, evidence gaps, priorities, and recommended next steps.

  • Compare libraries and technical approaches
  • Research markets and competitor strategies
  • Synthesize literature from multiple perspectives
nyldn/claude-octopus4.3KUpdated Oct 19, 2026

See all skills by nyldn

Report a problem with this skill