Skip to content
cccskills
FreePublished on GitHub

test-list

TDD Test List Phase - Create a comprehensive test list covering every example and rule from the specification

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md4.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

TDD Test List Phase

You are now in the Test List Phase of TDD. Follow these instructions to create a comprehensive test list.

Your Mission

Create a comprehensive test list that covers every example and rule from the specification:

  1. Read prompt.md thoroughly -- every rule, every example, every clarifying question
  2. Turn each example into at least one it.todo() test case
  3. Order tests from simplest to most complex
  4. Use it.todo() only -- no executable tests yet

Context: $ARGUMENTS

Test List Creation Process

Step 1: Understand the Feature

Read the complete prompt.md specification. Pay special attention to integration examples and clarifying questions (marked with ?) -- these disambiguate rules that may seem open to interpretation in isolation.

  • What are all operations the system must support?
  • What rules govern each operation?
  • Which examples in the spec illustrate these rules?

Step 2: Identify Test Cases from the Spec

Walk through the specification section by section. For each rule and each example:

  • Create a test case that verifies the described behavior
  • Include the expected numeric values from the spec in the test description
  • If a clarifying question resolves an ambiguity, create a test for the clarified interpretation
  • If the spec uses an example-mapping format (rules, examples, questions), every listed example must have a corresponding test

Step 3: Order Tests (Simple -> Complex)

Arrange tests in increasing complexity:

  1. Simplest case (often empty/zero/single item)
  2. Individual rules in isolation
  3. Rules with modifiers
  4. Combinations of multiple rules
  5. Multi-step scenarios (e.g., operations that reference earlier results)

Step 4: Write Test Descriptions

For each test case:

  • Use it.todo("description")
  • Include expected values: "should return 115 G (100 base + 10 first-insurance + 5 fee)"
  • Be specific and unambiguous
  • Reference the rule being tested

Step 5: Review Test List

Check for:

  • Every spec example is covered by at least one test
  • Every operation described in the spec has tests
  • Every clarifying question has a corresponding test
  • Tests are ordered simple -> complex
  • Each test is independent
  • Descriptions include expected values
  • All tests use it.todo()

Output Format

import { describe, it, expect } from "vitest";
import { functionName } from "./[feature-name].js";

describe("Feature Name", () => {
  it.todo("should [expected behavior] -- [expected value]");
  it.todo("should [next behavior] -- [expected value]");
  // ... ordered simple -> complex, covering ALL spec examples
});

Test List Summary

After creating test list, provide summary:

Test List Created:
**Feature**: [feature name]
**Test File**: [filename].spec.ts
**Tests**: [count]

**Test Cases** (ordered simple -> complex):
1. [first test description]
2. [second test description]
...

**Next Step**: Proceed to Red phase to activate the first test.

Red Flags

Watch for these issues:

  • Tests ordered randomly (not simple -> complex)
  • Vague or unclear test descriptions
  • Tests depending on each other
  • Writing executable tests instead of it.todo()
  • Thinking about implementation instead of behavior
  • Missing an entire operation described in the spec

Remember

  • Cover every spec example - All rules, all examples, all clarifications
  • it.todo() for all tests - No executable tests yet
  • Simple -> complex - Order matters
  • Clear descriptions - Include expected values
  • Independent tests - No dependencies
  • No implementation - Focus on "what", not "how"

Your goal is to create a comprehensive, well-ordered test list that covers all specified behavior and sets up the developer for successful TDD workflow.

Completion

After completing the test list, proceed to Red phase:

Test List Phase Complete. Proceeding to Red phase with the first test.

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

Generates an experiment-overview snapshot of all research questions under research/reports/. Invoke when a new point-in-time report across all RQs should be produced.

The English summary is being prepared. Showing the original description.

marcoemrich/agentic_coding_lab13Updated Oct 16, 2026

Mint a new YYYY-MM-DD-exact-coding-baseline snapshot under research/workflow-dev/export/. Detects the current best correctness- oriented workflow from research/workflow-dev/workflow-construction.md (or takes an explicit source-workflow argument) and transforms it from a lab workflow into a consumer-ready one on three axes: strips lab-only measurement content, re-enables human-in-the-loop checkpoints, and converts auto-loading config into an explicitly-invoked skill. Supports both promoted EXACT Coding lines: Opus/Hybrid and SOL/Predictive TDD. Exports Claude Code, pi, OpenCode, cursor-agent and, for SOL, Copilot. Trigger when the user says "exact-coding baseline export", "neue exact-coding baseline", "exact-coding-baseline-export", or asks to refresh the baseline snapshot.

The English summary is being prepared. Showing the original description.

marcoemrich/agentic_coding_lab13Updated Oct 16, 2026

green

Free

TDD Green Phase - Implement minimal code to make the failing test pass

The English summary is being prepared. Showing the original description.

marcoemrich/agentic_coding_lab13Updated Oct 16, 2026

Re-run the analysis pipeline on all runs matching an RQ, reaggregate metrics, and propose findings updates against the fresh data. Trigger when the user says "reanalyze RQ-N", "reanalyse RQ-N", "Runs neu analysieren", or wants to refresh metrics/findings after a pipeline change (analyze-run.sh fix, adapter added, ESLint config).

The English summary is being prepared. Showing the original description.

marcoemrich/agentic_coding_lab13Updated Oct 16, 2026

red

Free

TDD Red Phase - Activate ONE test from the test list and make it fail with explicit predictions

The English summary is being prepared. Showing the original description.

marcoemrich/agentic_coding_lab13Updated Oct 16, 2026

TDD Refactor Phase - Improve code while keeping tests green using Simple Design Rules and APP mass

The English summary is being prepared. Showing the original description.

marcoemrich/agentic_coding_lab13Updated Oct 16, 2026

See all skills by marcoemrich

Report a problem with this skill