Skip to content

Add TDD enforcement to DEVELOP prompt #68

Closed

Description

@monkut

Context

definitions.py:185 says "Write tests for every new or changed behavior" but doesn't enforce test-first methodology. The agent is free to write implementation first and backfill tests (or skip them).

Proposal

Replace the single "Write tests for every new or changed behavior" line in the DEVELOP prompt (askcc/definitions.py) with red/green TDD guidance, per the refined suggestion in the comment below.

Acceptance Criteria

  • askcc/definitions.py DEVELOP prompt replaces the existing Write tests for every new or changed behavior bullet with a Testing methodology — red/green TDD (non-negotiable): block covering RED (write failing test, confirm failure), GREEN (minimum code to pass), and REFACTOR (only on clear duplication/naming), plus rules requiring behavioral assertions and committing tests with implementation.
  • Prompt includes an explicit phase gate: do NOT proceed from RED to GREEN without a confirmed failing test run.
  • The DEVELOP prompt's anti-rationalization list gains one new entry rejecting "I'll write the test after, it's faster" (tests-after verify code, not requirement).
  • Existing Write tests for every new or changed behavior line is removed (no duplication of testing guidance in the DEVELOP prompt).
  • Tests covering the DEVELOP prompt content assert that the new TDD block and anti-rationalization entry are present (red/green TDD discipline applied to this change itself).
  • uv run pytest, uv run ruff check, and uv run pyright all pass.
  • No changes to other prompts (PLAN, PREPARE, VALIDATE, etc.) in this PR.

Dependencies

None.

Rationale

Research shows TDD enforcement significantly improves code quality in agent-driven development. See the updated suggestion comment for findings from Simon Willison's agentic patterns, alexop.dev's forced-TDD workflow, Superpowers, and agent-skills. Test-first catches requirement misunderstandings before implementation begins, rather than discovering them after the code is written.

Activity

  1. monkut commented on Apr 13, 2026

    @monkut
    OwnerAuthor

    Updated suggestion (TDD best-practices review)

    Reviewed current guidance from Simon Willison's agentic patterns, alexop.dev's forced-TDD workflow, the Superpowers/agent-skills skills, and recent Medium coverage (Shubham Sharma, Rupeshit Patekar). Key findings that sharpened the original proposal:

    1. "red/green TDD" is an understood shorthand — every capable model recognizes it, so naming the cycle anchors the rest.
    2. Confirming RED is the step agents skip most often. Training data rarely contains failing-test states, so agents tend to write tests that already pass. Require an explicit "ran the test, saw it fail, here's the output" proof.
    3. Phase gates beat prose. Blockers like "Do NOT proceed to GREEN until RED is confirmed" measurably lift adherence vs. soft guidance.
    4. GREEN must be minimal. Without a cap, agents backfill "nice to haves" that weren't driven by a test.
    5. Tests must be behavioral. They should assert on observable I/O or side effects, not re-run the implementation's own logic.
    6. Anti-rationalization already exists in the DEVELOP prompt — add a TDD-specific line so the pattern stays consistent.

    Proposed replacement for `definitions.py:184`

    ```
    Testing methodology — red/green TDD (non-negotiable):

    • RED: write a failing test that captures the required behavior. Run it and confirm it fails
      for the right reason. Paste the failing output into your working notes.
    • GREEN: write the minimum code needed to pass the test. No extra features, no speculative
      abstractions, no "while I'm here" changes.
    • REFACTOR: only if there is clear duplication or unclear naming. Keep tests green throughout.
    • Tests must assert on observable inputs/outputs or side effects — never by re-invoking the
      implementation's own logic to compute the expected value.
    • Do NOT proceed from RED to GREEN without a confirmed failing run.
    • Commit tests and implementation together.
      ```

    Add to the anti-rationalization list

    ```

    • "I'll write the test after, it's faster" — Tests written after implementation verify the
      code, not the requirement. Always RED before GREEN.
      ```

    Sources

  2. self-assigned this
    on Apr 13, 2026
  3. added a commit that references this issue on Apr 13, 2026
    5574fc7
  4. monkut commented on Apr 13, 2026

    @monkut
    OwnerAuthor

    Implemented in #76.

    Changes

    • askcc/definitions.py: Replaced the Write tests for every new or changed behavior bullet in DEVELOP_AGENT_PROMPT with a Testing methodology — red/green TDD (non-negotiable): block covering RED (failing test + confirmed failure output), GREEN (minimum code), REFACTOR (only on duplication/naming), behavioral-assertion rule, the explicit phase gate Do NOT proceed from RED to GREEN without a confirmed failing run., and a Commit tests and implementation together. rule.
    • askcc/definitions.py: Added the "I'll write the test after, it's faster" anti-rationalization entry.
    • tests/test_askcc.py: Added TestDevelopPromptTddContent (9 assertions) covering each new requirement plus removal of the legacy line.

    TDD applied to this change

    1. Wrote TestDevelopPromptTddContent tests first.
    2. Ran uv run pytest tests/test_askcc.py::TestDevelopPromptTddContent — confirmed RED (first failing test on the missing TDD block).
    3. Edited DEVELOP_AGENT_PROMPT minimally to satisfy the assertions — confirmed GREEN.

    Verification

    • uv run pytest — 123 passed
    • uv run ruff check — All checks passed
    • uv run pyright — 0 errors

    No other prompts were touched.

    :tokens-used: model: N/A, input: 36, output: 7350

  5. added and removed
    action:developIssue is ready for development
    on Apr 13, 2026
  6. added a commit that references this issue on Apr 13, 2026
    e4aae14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions