メニュー
Use whenever you need to write a unit, integration or component test.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Guidance on writing fast, robust, modern Svelte code. Load this skill whenever in a Svelte project and asked to write/edit or analyze a Svelte component or module. Covers reactivity, event handling, styling, integration with libraries and more.
Use when the user asks for documentation. Use when a new feature has been built or significantly changed and its design/decisions should be recorded in the repo's docs/. Captures the approach (and optional rationale) into per-topic markdown files (testing, api-endpoints, routes, data-loading, components, state-management, business-logic, forms-actions, auth, error-handling, build-deployment). Do NOT use for bugfixes, style tweaks, or other small tasks.
Use when reviewing code changes. Checks Svelte 5 runes usage, SvelteKit data-loading/endpoints, server-only and env/secret boundaries, SSR state leakage, storefront pitfalls (money, cart/price/stock trust boundaries, payments, SEO, a11y, caching), tests, and the repo's verification gates. Use ONLY for reviewing/critiquing existing code, not for writing new features.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Use when the user wants a plan or breakdown for building a feature (or significantly reshaping one) before any code is written. Turns a feature request into a written implementation plan of self-contained, independently testable vertical slices. Do NOT use for bugfixes, refactors with no behavior change, or trivial one-step tasks.
| name | test-writer |
| description | Use whenever you need to write a unit, integration or component test. |
See tests.md for examples and mocking.md for mocking guidelines.
Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
They are integration-style; they exercise real code paths through public APIs. They describe what the system does, not how it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
They are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
