Phase 3 / Ep 13: Configuring test-driven-development skill flow

To put chains on that behemoth (LLM code development), we need to create a targeted skill specification in the guardrail system's .agents/skills/ directory. By leveraging the radar effect of using-superpowers, we can force the AI into this workflow every time before it writes specific business logic.

1. Establishing the TDD Skill Profile

Write down this set of disciplines in .agents/skills/test-driven-development/SKILL.md:

name: test-driven-development
description: Triggered when encountering any instruction to implement a Feature or Fix a Bug. This outline must be read before writing business logic files.

# The Iron Law of TDD Red-Green Refactoring

**Core Red Line**: "Guessing and writing business code first, then adding tests later" is strictly prohibited. You must strictly follow these steps without skipping.

1. **Write the Red Line (Red)**:
   - First, create or use an existing `*.spec.ts` file to write test cases for the goal you are about to implement.
   - Run it using the command line (it must Fail and throw red text, because at this point the source business file is still an empty shell).
   - **Read the Error!** Confirm that the reason the test failed is indeed because "the feature is not implemented" and not due to a syntax error.

2. **Turn on the Green Light (Green)**:
   - Turn to the `src/` directory to complete the minimum viable business code (just aim to make it pass and turn green; do not pursue an elegant architecture yet).
   - Run the terminal tests repeatedly.
   - This is one of the **only two** stages where you are allowed to enter a code fine-tuning loop.

3. **Refactor and Purify (Refactor)**:
   - When the terminal turns green with a `PASS`, this is when you can show off your "architect" level skills.
   - Extract common methods in the business logic, optimize time complexity, and increase code readability.
   - Refactor boldly with peace of mind, because the heavy lock of testing is already in place. If you break it during refactoring, it will turn red!

2. Granting Terminal Freedom to the Toolset

When using Agents with advanced terminal sandboxes like Antigravity/Claude Code, we must confirm that the system foundation has Vitest installed.

Issue a task in the terminal or task board:

"Please configure the project's Vitest environment, and configure the script in package.json as test:unit."

This action is not for writing business code, but to allow the Agent to hand over its code verification to an objective machine in the future by running standard Shell commands (such as npm run test:unit), rather than relying on your eyes or its hallucinations.

The testing infrastructure is now laid out. In the next episode, the real brutal battle begins. We will execute the first code action in task_plan.md and see with our own eyes how the Agent breaks through the siege under the torture of red test errors!