菜单
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