Update to Skillquiver

{
  "description": "Runs a recorded red-green-refactor cycle. Use when implementing a feature, bug fix, or behavior change.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 218
    },
    {
      "relative_path": "writing-good-tests.md",
      "size_in_bytes": 3540
    }
  ],
  "name": "test-driven-development",
  "skill_md_contents": "---\nname: test-driven-development\ndescription: Runs a recorded red-green-refactor cycle. Use when implementing a feature, bug fix, or behavior change.\n---\n\n# Test-Driven Development\n\nWrite one behavioral test, observe the expected failure, write the minimum code\nto pass, and refactor only while green.\n\n## Scope\n\nUse TDD for features, bug fixes, and externally observable behavior changes.\nFor a pure behavior-preserving refactor, preserve existing green tests and add\ncoverage only for an uncovered contract the refactor could break. Ask before\nskipping TDD for throwaway prototypes, generated code, or configuration-only\nchanges.\n\nProduction code written before its failing test is not a red-green cycle. Do\nnot keep it as a reference: revert that implementation, establish red, and\nimplement from the test.\n\n## Cycle\n\n### 1. Red\n\nWrite the smallest test that expresses one required behavior through the\nhighest practical public seam.\n\n- Name the behavior precisely.\n- Exercise real production code; mock only an external boundary that cannot be\n  used safely or deterministically.\n- Cover the requested example first, then one meaningful edge or error case.\n- Run only the focused test while iterating.\n\nRecord the command, non-zero exit, and decisive assertion output. Confirm that\nthe test failed because the behavior is missing, not because of syntax, setup,\nimports, or the wrong command. A passing test or a test that errors does not\nestablish red; correct it and rerun.\n\n### 2. Green\n\nImplement only enough production behavior to satisfy the red test. Do not add\noptions, abstractions, validation, or adjacent cleanup that no current test or\nrequirement demands.\n\nRerun the identical focused command. Fix production code rather than weakening\nthe assertion. Record the zero exit and passing output. If existing focused\ntests now fail, resolve the regression before continuing.\n\n### 3. Refactor\n\nOnly after green, remove duplication, improve names, or simplify structure\nwithout adding behavior. Keep the focused tests green after every structural\nchange. If the next requirement needs new behavior, start another red cycle.\n\n## Test integrity\n\nBefore writing or changing a non-trivial test, read\n[writing-good-tests.md](writing-good-tests.md). In particular:\n\n- Name the production defect that would make the test fail.\n- Assert externally visible results, state, or calls at a real boundary rather\n  than reimplementing the production algorithm in the test.\n- Avoid tests that prove only a mock was configured.\n- Keep test-only helpers out of production classes.\n- Understand dependency side effects before replacing them.\n\nHard-to-test behavior is design feedback: simplify the public interface or\nmove dependencies behind an explicit seam. Huge setup should be reduced with a\nsmall test helper before adding production abstraction.\n\n## Completion\n\nBefore reporting success, verify and report:\n\n- Every changed behavior has a test that was observed failing first for the\n  expected reason.\n- The implementation is the smallest one supported by the requirements and\n  tests.\n- Main examples plus proportionate edge and failure cases pass.\n- The relevant test command passes with no hidden errors or warnings.\n- No assertion was deleted or weakened merely to obtain green.\n\nIf red was not observed, say so explicitly; do not relabel tests-after as TDD.\n"
}