Skip to content

Improve TDD skill guidance and add frontend visual polish step #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
etr merged 1 commit into from
Mar 14, 2026
Merged

Improve TDD skill guidance and add frontend visual polish step #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions skills/implement-feature/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,12 @@ For non-trivial changes, ask:

If improvements identified: implement them (maintaining test coverage).

### Step 4b: Frontend Visual Polish

**For UI/frontend tasks**, apply visual polish before handing off. Read the design system spec (`specs/design_system.md`) if it exists.

**Rule of thumb:** Every view should have at least one element that makes it visually distinctive. If everything is the same white card with the same border, it needs more visual variety.

### Step 5: Verify and Hand Off

Verify all work before handing off:
Expand Down
29 changes: 26 additions & 3 deletions skills/test-driven-development/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -204,6 +204,27 @@ Next failing test for next feature.
| **Clear** | Name describes behavior | `test('test1')` |
| **Shows intent** | Demonstrates desired API | Obscures what code should do |

## What NOT to Test

Not everything benefits from TDD. Writing tests for these wastes budget and creates maintenance burden:

**Skip tests for:**
- Static markup and CSS classes (layout, colors, spacing, font sizes)
- Element counts ("renders 6 nav items") — only fails on intentional changes
- Pure presentational components with zero logic (just HTML + Tailwind)
- Tooltip styling, container classes, overflow attributes
- That an icon renders as an SVG

**DO test:**
- Conditional rendering (shows X when condition Y)
- Computed values (formats currency, calculates percentage)
- User interactions (click, keyboard, filter, sort, pagination)
- State transitions (toggle, edit mode, selection)
- Edge cases (empty data, zero values, overflow)
- Business rules (color thresholds, frequency detection, amortization math)

**Rule of thumb:** If the test would only fail when someone intentionally changes the UI, it's not testing behavior — it's preventing change. Delete it.

## Why Order Matters

**"I'll write tests after to verify it works"**
Expand Down Expand Up @@ -329,7 +350,7 @@ Extract validation for multiple fields if needed.

Before marking work complete:

- [ ] Every new function/method has a test
- [ ] Every function/method with logic (conditionals, computation, side effects) has a test
- [ ] Watched each test fail before implementing
- [ ] Each test failed for expected reason (feature missing, not typo)
- [ ] Wrote minimal code to pass each test
Expand All @@ -351,8 +372,10 @@ Can't check all boxes? You skipped TDD. Start over.

## Coverage Requirements

### Target: 80%+ Coverage
- Unit tests + Integration tests + E2E tests combined
### Target: 80%+ Coverage of Logic Paths
- Coverage means branch/logic coverage, not line coverage of markup
- Pure presentational components (no conditionals, no computed values) do NOT need unit tests — they are validated visually
- Do not write tests solely to increase coverage numbers
- All edge cases covered
- Error scenarios tested
- Boundary conditions verified
Expand Down
Loading