recipe-add-integration-tests

Add integration/E2E tests to existing codebase using Design Docs

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a strong, highly actionable orchestrator workflow with excellent sequencing, validation gates, and feedback loops. Its main weaknesses are the absence of progressive-disclosure file structure (everything inline) and some repetition that could be tightened.

Suggestions

Externalize the Step 3 task-file template into a reference file (e.g. references/task-file-template.md) and link to it, reducing inline bulk and improving progressive disclosure.

Consolidate the repeated backend/frontend subagent routing tables (Steps 4, 6, 7) into a single routing reference table cited once, to tighten conciseness.

Consider a short 'Prerequisites / routing reference' detail file for the monorepo-flow.md naming conventions and subagent mappings, keeping SKILL.md as a lean overview.

Dimension	Reasoning	Score
Conciseness	The body is dense and directive with no padding of concepts Claude already knows, but the full inline task-file template and the repeated backend/frontend routing tables across Steps 4/6/7 could be tightened or externalized, matching the level-2 'could be tightened' anchor rather than 'every token earns its place'.	2 / 3
Actionability	Concrete executable guidance throughout — exact `subagent_type` strings, bash guards (`test -n "$ARGUMENTS"`), deterministic file-path patterns, structured prompts, and a commit-message format — making it copy-paste ready as the level-3 anchor requires; the bracketed placeholders are clearly filled from prior step outputs, not pseudocode.	3 / 3
Workflow Clarity	Steps 0-9 are explicitly sequenced with a [GATE] marker on Step 3, status-based validation checkpoints (approved/needs_revision, approved/stub_detected/blocked), and explicit feedback loops (Step 5→6 revision, Step 7 stub_detected returning to Step 4), matching the level-3 anchor for clear sequence with validation and error-recovery loops.	3 / 3
Progressive Disclosure	The skill is well-organized into clear sections but is essentially monolithic: the task-file template and routing tables are inline with no one-level-deep references to detail files, and no bundle files exist to split content into, matching the level-2 'content that should be separate is inline' anchor; it is not 1 because sectioning is clear, not a disorganized wall.	2 / 3
	Total	10 / 12 Passed

Description

50%

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 specific and on-domain but lacks an explicit "Use when..." trigger and has only partial trigger-term coverage, leaving it at the mid-level across all dimensions. Adding explicit when-to-use guidance and more natural trigger variations would lift it.

Suggestions

Append a 'Use when...' clause naming explicit triggers, e.g. 'Use when adding integration or E2E tests to an existing codebase from a Design Doc, or when the user asks to write integration tests / improve test coverage against a design spec.'

Broaden trigger terms with natural variations users say — 'write integration tests', 'add test coverage', 'E2E tests', 'end-to-end tests' — so the skill surfaces for the right requests.

Sharpen distinctiveness by contrasting scope, e.g. noting this targets integration/E2E (not unit tests) and is driven by Design Docs.

Dimension	Reasoning	Score
Specificity	"Add integration/E2E tests to existing codebase using Design Docs" names a clear domain (integration/E2E tests, existing codebase) and one concrete action ("Add"), but does not list multiple specific concrete actions, so it falls short of the level-3 anchor.	2 / 3
Completeness	The description states the "what" (add integration/E2E tests using Design Docs) but lacks any "Use when..." clause or equivalent explicit trigger, so per the judging guideline completeness is capped at 2; it is not 1 because the what is clearly stated.	2 / 3
Trigger Term Quality	Phrases "integration/E2E tests" and "existing codebase" are natural terms a user might say, but coverage is incomplete — common variations like "write tests", "test coverage", or "automated tests" are missing, matching the level-2 anchor rather than full coverage.	2 / 3
Distinctiveness Conflict Risk	"using Design Docs" and the integration/E2E scope give it a niche, but without explicit triggers it could still overlap with general unit-test or test-writing skills, matching the level-2 "could still overlap" anchor rather than a clearly conflict-free niche.	2 / 3
	Total	8 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: shinpr/claude-code-workflows
Commit: 66e3b29

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.