recipe-add-integration-tests
Add integration/E2E tests to existing codebase using Design Docs
50
55%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/recipe-add-integration-tests/SKILL.mdQuality
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is too terse and lacks explicit trigger guidance for when Claude should select this skill. While it identifies a specific niche (integration/E2E testing from Design Docs), it fails to enumerate concrete actions or provide a 'Use when...' clause, making it difficult for Claude to reliably choose this skill from a large pool.
Suggestions
Add an explicit 'Use when...' clause with trigger terms like 'add integration tests', 'write E2E tests', 'end-to-end testing', 'test coverage from design doc', or 'generate tests from specification'.
List specific concrete actions such as 'Reads design documents to identify test scenarios, generates integration test files, creates E2E test suites with setup/teardown, and validates API contracts'.
Clarify what 'Design Docs' means in this context (e.g., architecture documents, API specs, feature specifications) to reduce ambiguity and improve distinctiveness.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (integration/E2E tests) and a key action (add tests using Design Docs), but doesn't list multiple concrete actions like generating test cases, setting up test infrastructure, or writing assertions. | 2 / 3 |
Completeness | Provides a partial 'what' (add integration/E2E tests using Design Docs) but completely lacks a 'when should Claude use it' clause. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also weak, so this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant terms like 'integration tests', 'E2E tests', and 'Design Docs', but misses common variations users might say such as 'end-to-end', 'test coverage', 'testing', 'test suite', or 'acceptance tests'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'integration/E2E tests' with 'Design Docs' provides some distinctiveness, but 'existing codebase' is generic and could overlap with general testing or code generation skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured orchestration skill with strong workflow clarity and actionability—clear step sequencing, explicit feedback loops, concrete subagent invocations, and specific file naming conventions. Its main weaknesses are moderate verbosity from repeated routing rules and the orchestrator rationale preamble, plus references to external skills/files that cannot be verified without bundle context.
Suggestions
Consolidate the repeated routing logic (Steps 4, 6, 7) into a single reference table at the top to reduce redundancy and improve conciseness.
Remove or significantly shorten the 'Orchestrator Definition' section—Claude doesn't need to be told why delegation saves context; just state the delegation pattern directly.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is moderately efficient but includes some redundancy—routing rules are repeated across Steps 4, 6, and 7, and the orchestrator identity/delegation rationale section explains concepts Claude can infer. The template and step descriptions could be tightened. | 2 / 3 |
Actionability | The skill provides concrete, executable guidance: specific bash commands, exact subagent_type strings, file naming conventions, task file templates with markdown structure, commit message formats, and clear prompt templates for each subagent invocation. Each step specifies expected inputs and outputs. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced (Steps 0-9) with explicit validation checkpoints: Step 3 is marked as a GATE, Step 5 provides review with approve/revise feedback loop back to Step 4, Step 7 has a quality check with stub_detected/blocked/approved branching, and the per-task-file sequential execution through Steps 4→5→6→7 is clearly specified. | 3 / 3 |
Progressive Disclosure | The skill references external skills (documentation-criteria, acceptance-test-generator, integration-test-reviewer, quality-fixer, monorepo-flow.md) but no bundle files are provided to verify these exist. The content is somewhat monolithic—the task file template and scope boundary block could potentially be extracted. However, for an orchestration recipe, inline content is reasonable. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- shinpr/claude-code-workflows
- Commit
adf2e4d
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.