메뉴
Read this guideline when creating implementation tasks, doing TDD, deciding task order, or working on any feature with observable behavior.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Read this guideline when creating commits, opening PRs, writing changeset descriptions, branching, or before running any git command that modifies history.
Read this guideline when placing new code in a layer, reviewing imports, designing a new package, adding I/O, or when files are under packages/core/src/, packages/fit/, packages/tcx/, packages/zwo/, packages/garmin/, packages/garmin-connect/, packages/cli/, packages/mcp/.
Generate a Garmin Connect (.gcn) workout file from a natural language description. Use when the user describes a training session, workout, or exercise plan and wants a .gcn file.
Read this guideline when writing tests, reviewing test code, or deciding what kind of test to write for a given layer. Also applies when files match **/*.test.{ts,tsx,js,mjs}.
Read this guideline when writing or reviewing TypeScript code, naming symbols, refactoring, deciding between type vs interface, or working with schemas, mappers, or converters.
Read this guideline when working on workout-spa-editor, React components, custom hooks, Zustand store, Dexie queries, or generating GCN workout targets.
| name | xp-tdd-practices |
| description | Read this guideline when creating implementation tasks, doing TDD, deciding task order, or working on any feature with observable behavior. |
Every implementation task with behavior (use cases, adapters, converters, components, hooks) uses the preceding-sibling RED → GREEN → REFACTOR pattern:
- [ ] parent feature
- [ ] write failing test for X (RED)
- [ ] implement X — minimal passing code (GREEN)
- [ ] refactor X (REFACTOR)
The failing test task MUST immediately precede its implementation task. Do not batch tests at the end.
Types, interfaces, DTOs, config files, and pure wiring tasks are plain checkboxes — no TDD format.
Characterization tests for unchanged production code (e.g., adding a *.converter.test.ts next to a *.converter.ts whose logic is not modified) use plain checkboxes — they describe current behavior, not new behavior, so the RED → GREEN → REFACTOR cycle does not apply.
A bug fix that changes observable behavior MUST start with a failing regression test that reproduces the bug, then the fix that makes it pass.
Order tasks strictly by layer:
domain types/schemas → ports → application use cases → adapters → CLI/MCP wiring → docs/changeset
Within each layer, apply RED → GREEN → REFACTOR ordering.
Each checkbox should be implementable + testable in one focused commit (~30–60 min). Split larger items into nested sub-checkboxes.
Every task list ends with this block (in order):
- [ ] pnpm -r test:coverage (thresholds: 80% core, 70% frontend)
- [ ] pnpm -r build (zero warnings)
- [ ] pnpm lint (zero errors/warnings; includes lint:specs, lint:archive, lint:archive-index)
- [ ] /opsx:verify against all spec scenarios
- [ ] pnpm exec changeset (for any user-visible change)
- [ ] Update affected domain specs in openspec/specs/ and run pnpm lint:specs