| name | write |
| description | Implement a small to medium feature with TDD approach. This skill should be used when the user asks to "write a feature", "implement", "add functionality", "build", or describes a new feature to create. For large features requiring architecture exploration, consider a feature-dev plugin. |
| argument-hint | ["feature description"] |
| disable-model-invocation | true |
| allowed-tools | Read, Edit, Write, Grep, Glob, Bash(git log:*), Bash(git diff:*), Bash(git show:*), Bash(npm test:*), Bash(npm run test:*), Bash(npx vitest:*), Skill |
/write — Feature Implementation Workflow
Skills Rubric
| Skill | When to load |
|---|
| spec | When the Spec Gate says NO (see Step 2) |
| principles | Always — design decisions are part of every feature |
| testing | Always when the feature introduces new behavior (almost always) |
| done | Always — run verification before claiming the feature is complete |
Step 1: Understand the Context
Feature request: $ARGUMENTS
Read the relevant files before writing any code.
- Identify which files / modules will be affected
- Look at existing patterns in adjacent code (
git log --oneline -10 for recent context)
- Do NOT read framework source code — only application code
Step 2: Spec Gate — TDD or SDD First?
Before loading skills or writing any plan, answer these three questions:
| Question | If YES |
|---|
| Is this a bug fix or internal change that does not touch the public interface? | Skip spec → go to Step 3 |
| Does a TypeScript interface / function signature already exist for this? | Skip spec → go to Step 3 |
| Can you name 3+ boundary cases right now without thinking hard? | Skip spec → go to Step 3 |
If you could not answer YES to any question → load spec skill now. Complete the spec output (behaviour description + interface + invariants) before continuing.
When spec is complete, return here. The invariants become the first test cases in Step 4.
Step 3: Load Skills
Apply the Skills Rubric. Load principles and testing always. spec only if Spec Gate triggered it.
Step 4: Plan Mode — TDD Task Breakdown
Enter plan mode. Break the feature into the smallest meaningful tasks.
- Apply minimum change principle: prefer extending over modifying
- Each task should be completable as one Red/Green/Refactor cycle
- List any questions or assumptions for the user to confirm
Wait for user confirmation before writing any code.
Step 5: Implement (Red → Green → Refactor per task)
For each task in the breakdown:
Red — Write a failing test that describes the behavior.
- Confirm: "Test fails because [reason]."
Green — Write minimum code to pass the test.
- Confirm: "All tests pass."
Refactor — Clean up without changing behavior.
- Confirm: "Tests still pass."
Step 6: Completion Check
Verify against both skill rubrics:
- principles rubric — naming, types, function length, import order
- testing rubric — AAA structure, single assertion, deterministic, integration path exists
Next: run /review to verify style consistency and test quality before committing.
