SkillsAdd

smithery.ai

test-plan

Create an AC-mapped unit, integration, edge, and smoke test plan for a documented work item. Use before tests or implementation are written.

First seen Mar 21, 2026

Installation

$ npx skills add https://smithery.ai
View on skills.sh ↗ Website ↗

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

building-native-ui Shared topics
expo/skills 59.2K installs
ai-sdk Shared topics
vercel/ai 53.4K installs
expo-cicd-workflows Shared topics
expo/skills 39.9K installs
webapp-testing Similar name
anthropics/skills

Toolkit for interacting with and testing local web applications using Playwright. Supports veri…

152.3K installs
clerk-testing Similar name
clerk/skills

E2E testing for Clerk apps. Use with Playwright or Cypress for auth flow tests.

36K installs
flutter-add-widget-test Similar name
flutter/agent-plugins

Implement a component-level test using `WidgetTester` to verify UI rendering and user interacti…

31.1K installs

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai
smithery-ai-cli 7.8K frontend-design 6.2K skill-creator 2.5K ck:ui-ux-pro-max 1.3K pdf 1.2K xlsx 966 pptx 894 docx 884 webapp-testing 1 web-design-reviewer 657

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,010 B
  • docs SUMMARY.md 106 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 4 installs

SKILL.md

  1. Read AGENTS.md, codex.toml (if present), and the target work item folder spec/features/<work-id>-<slug>/.

- <work-id> must use S-<stream>-<nnn> (example: S-core-001) for new work. - For legacy single-file specs, read the matching file under spec/features/. - Source acceptance criteria from feature.md (or the legacy single-file spec).

  1. Convert acceptance criteria into a test matrix:

- Preserve stable identifiers (AC-1, AC-2, etc.) in every mapping. - Unit tests (fast, isolated) - Integration tests (component boundaries) - End-to-end / scenario tests (happy path + key edge cases) - Negative/error cases (validation, permissions, timeouts, etc.)

  1. Decide what to mock vs run for real (with rationale).
  2. Update test-plan.md with:

- Test cases mapped to ACs - Test data/fixtures needed - Any required test hooks/utilities - Smoke plan fields: - applicability: required or notapplicable - rationale when not applicable; only non-runnable work may use this value - scenario ID/name - fixture path - expected output shape (schema and invariants) - pass/fail mode (schema/invariants only, or schema/invariants/golden) - runtime constraints (mode, network/env, time budget, request/token budget) - artifact path expectation (artifacts/smoke/...) - Omit scenario/fixture/artifact fields only when applicability is notapplicable and the rationale is documented.

  1. End by recommending write-tests.

- Output exactly: - Next recommended skill: - Run $write-tests <work-id> to implement the planned unit/integration/edge-case tests. - Replace <work-id> with the real ID from the target folder (example: S-core-001). - Do not use markdown links or absolute file paths in this recommendation.