菜单
Generates well-structured unit tests using Vitest with the "given/should" prose format. Use when writing tests for new code, adding coverage to existing code, or following TDD practices.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audits components and pages for WCAG accessibility issues and suggests fixes. Use when building new UI, reviewing components for a11y compliance, or fixing reported accessibility bugs.
Rewrites text to be clearer, simpler, and more engaging using Scott Adams' writing principles and persuasive techniques. Use when editing marketing copy, blog posts, emails, or any business text that needs to be punchier.
Facilitates solution ideation with clear trade-offs and a final recommendation. Use when exploring architectural decisions, evaluating technology choices, or comparing implementation approaches before writing code.
Reviews code changes for correctness, maintainability, security, and adherence to project conventions. Use when reviewing PRs, auditing recent changes, or getting a second opinion on implementation quality.
Commits staged changes using the conventional commits format with proper type, scope, and description. Use when committing code changes to maintain a clean, standardized git history.
Structured debugging skill for methodical root cause analysis. Use when investigating bugs, unexpected behavior, or errors. Produces an issue summary, key findings, root cause analysis, and recommended solutions without modifying code.
| name | unit-tests |
| description | Generates well-structured unit tests using Vitest with the "given/should" prose format. Use when writing tests for new code, adding coverage to existing code, or following TDD practices. |
Act as a top-tier software engineer with serious testing skills.
Write unit tests for: $ARGUMENTS
Each test must answer these 5 questions:
UnitTests {
Constraints {
Use Vitest with describe, expect, and test.
Tests must use the "given: ..., should: ..." prose format.
Colocate tests with functions. Test files should be in the same folder as the implementation file.
Use cuid2 for IDs unless specified otherwise.
If an argument is a database entity, use an existing factory function and override values as needed.
Capture the actual and the expected value in variables.
The top-level describe block should describe the component under test.
The test block should describe the case via "given: ..., should: ...".
Avoid expect.any(Constructor) in assertions. Expect specific values instead.
Always use the toEqual equality assertion.
Empty line before actual variable assignment.
NO empty line between actual and expected assignments.
Empty line after expected variable assignment before the toEqual assertion.
Tests must be readable, isolated, thorough, and explicit.
Test expected edge cases.
Create factory functions for reused data structures rather than sharing mutable fixtures.
}
Boundaries {
React component render tests (.test.tsx) -> use /happy-dom-tests instead
Database or server action tests (.spec.ts) -> use /integration-tests instead
Browser-level user flow tests (.e2e.ts) -> use /e2e-tests instead
This skill is for pure function unit tests (.test.ts) only.
}
}
