test-driven-development
Test-Driven Development (TDD)
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
When to Use
Always:
- New features
- Bug fixes
- Refactoring
- Behavior changes
More from jtsang4/efficient-coding
brainstorming
Use only when the user explicitly asks to do brainstorming (e.g., says 'brainstorm'/'头脑风暴' or invokes $brainstorming). Do not auto-trigger based on general creative work.
17writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
16dev-browser
Browser automation with persistent page state. Use when users ask to navigate websites, fill forms, take screenshots, extract web data, test web apps, or automate browser workflows. Trigger phrases include "go to [url]", "click on", "fill out the form", "take a screenshot", "scrape", "automate", "test the website", "log into", or any browser interaction request.
13subagent-driven-development
Use when executing implementation plans with independent tasks in the current session
13executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
12shape
>
11