This skill should be used when "planning tests", "testing strategy", "what tests do we need", or designing the testing section of a design document. Covers unit, integration, E2E, and performance testing levels. Do not use for writing actual test code (see tdd-discipline).
From forgenpx claudepluginhub flox/forge-plugin --plugin forgeThis skill uses the workspace's default tool permissions.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Details PluginEval's skill quality evaluation: 3 layers (static, LLM judge), 10 dimensions, rubrics, formulas, anti-patterns, badges. Use to interpret scores, improve triggering, calibrate thresholds.
Standard approach for planning tests across different levels.
Questions to ask:
Include in design:
### Unit Tests
- [New modules/functions needing tests]
- [Existing tests needing updates]
Questions to ask:
Include in design:
### Integration Tests
- [Component interactions to verify]
Questions to ask:
Include in design:
### E2E Tests
- **Needs update:** Yes / No
- [New scenarios if applicable]
For features affecting API contracts:
| Question | Why It Matters |
|---|---|
| Could this break existing clients? | Users may not update immediately |
| Is versioning needed? | Backward compatibility |
| What's the deprecation path? | How to phase out old behavior |
Include in design:
### API Compatibility
- **Existing clients work:** Yes / No
- **Versioning needed:** Yes / No
- [Deprecation path if applicable]
For performance-sensitive features:
For UI changes:
Include in design:
### Web UI Testing
- **Affects authenticated users:** Yes / No
- **Affects unauthenticated users:** Yes / No
- **Responsive behavior:** Consistent / Intentionally different
- **Breakpoints tested:** Mobile / Tablet / Desktop
When a design includes Key Decisions (ADRs), each decision should map to at least one test that validates correct implementation:
| Decision | Test | Expected Outcome |
|---|---|---|
| {decision title} | {specific test} | {pass criteria} |
This ensures design decisions are not just documented but verified during implementation. The implementation worker should check this table when writing tests.
## Testing Strategy
### Unit Tests
- [New modules/functions needing tests]
- [Existing tests needing updates]
### Integration Tests
- [Component interactions to verify]
### E2E Tests
- **Needs update:** Yes / No
- [New scenarios if applicable]
### API Compatibility
- **Existing clients work:** Yes / No
- **Versioning needed:** Yes / No
- [Deprecation path if applicable]
### Web UI Testing (if applicable)
- **Affects authenticated users:** Yes / No
- **Affects unauthenticated users:** Yes / No
- **Responsive behavior:** Consistent / Intentionally different
- **Breakpoints tested:** Mobile / Tablet / Desktop
### Performance Tests
- [If applicable]