Content
27%Scale 1-3Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive but overly verbose TDD guide that explains many concepts Claude already knows (TDD principles, test types, Arrange-Act-Assert). While it provides some concrete code examples, several are incomplete with placeholder comments. The monolithic structure with no progressive disclosure makes it token-inefficient, and the project-specific examples (Supabase, Redis, OpenAI mocks) limit generalizability without being clearly scoped to a specific project.
Suggestions
Cut the content by at least 50%: remove explanations of what TDD is, what test types are, and generic best practices lists—Claude already knows these. Focus only on project-specific conventions and non-obvious patterns.
Complete all placeholder test implementations (e.g., '// 測試實作', '// 測試錯誤處理') with actual executable code, or remove them entirely.
Split into multiple files: keep SKILL.md as a concise overview with the 7-step workflow, and move mock patterns, E2E examples, and test organization into separate referenced files.
Add explicit error recovery steps: what to do when coverage drops below 80%, how to handle flaky E2E tests, and when it's acceptable to skip TDD (e.g., exploratory prototyping).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~300+ lines. Explains TDD concepts Claude already knows (what TDD is, what unit/integration/E2E tests are, Arrange-Act-Assert pattern, basic testing principles). The 'best practices' list and 'success metrics' are generic knowledge. The mock examples, while concrete, are project-specific (Supabase, Redis, OpenAI) yet presented as general patterns. Much content could be cut by 60%+ without losing actionable value. | 1 / 3 |
Actionability | Provides concrete code examples (Jest/Vitest tests, Playwright tests, mock patterns) that are mostly executable, but many test bodies contain placeholder comments like '// 測試實作' and '// 測試錯誤處理' instead of actual implementations. The TDD workflow steps are clear but the code examples are a mix of complete and incomplete. | 2 / 3 |
Workflow Clarity | The 7-step TDD workflow is clearly sequenced with explicit steps (write test → run → implement → run → refactor → verify coverage). However, there's no feedback loop for when coverage falls below 80% or when tests fail unexpectedly during refactoring. The validation step (Step 7) exists but lacks error recovery guidance. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. All content—mock patterns, test patterns, CI/CD config, file organization, best practices—is inlined in a single massive document. No bundle files exist, but the content is long enough that splitting into referenced files (e.g., MOCK_PATTERNS.md, E2E_EXAMPLES.md) would significantly improve usability. | 1 / 3 |
Total | 6 / 12 Passed |