메뉴
Apply when writing, reviewing, or planning tests — covers BDD style, happy-path AND sad-path coverage, deriving tests from user stories, and using bun:test. Load whenever creating *.test.ts files, adding coverage, or turning a requirement into a spec.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Apply when writing, structuring, or reviewing application code — covers SOLID, YAGNI, DRY, composition over inheritance, Gang of Four patterns (used sparingly), Command/Query Separation, the banned Repository pattern, /lib application logic, and /tests BDD coverage. Load whenever designing classes, services, modules, or deciding where code lives.
Apply whenever you write or modify ANY class, method, or .ts file — not only when editing comments. Every class and method you author must be commented per this skill, so load it alongside code-architecture during all code-writing. Covers commenting classes and methods (not internals), writing for a future LLM reader, and avoiding noise comments on properties or obvious code.
Apply when reading or writing data, designing schema, choosing a datastore, or wiring persistence — covers Drizzle ORM usage, SQLite for dev/test, Cloudflare D1 for prod, Firebase Storage links, and the absolute ban on the Repository pattern. Load whenever touching the database, migrations, queries, or storage.
Apply when choosing runtime/framework/deploy targets or scaffolding an app, API, route, webhook, or deployment — covers Bun with TypeScript, Cloudflare Workers, D1, Firebase Storage, Resend, and Stripe webhooks. Load whenever setting up endpoints, configuring runtime, or planning deployment.
| name | testing-standards |
| description | Apply when writing, reviewing, or planning tests — covers BDD style, happy-path AND sad-path coverage, deriving tests from user stories, and using bun:test. Load whenever creating *.test.ts files, adding coverage, or turning a requirement into a spec. |
Use bun:test whenever possible — import { describe, it, expect, beforeEach } from "bun:test". No Jest, no Vitest unless a real constraint forces it.
Start from the story, not the implementation:
As a customer, I want to add an item to my cart so that I can buy it later.
Each story becomes a describe block. Each acceptance condition becomes an it that reads as a sentence:
describe("Cart — adding items", () => {
it("adds a new line when the item is not already in the cart", () => { /* ... */ });
it("increments quantity when the item is already in the cart", () => { /* ... */ });
});
it/describe text should read like spoken English. If the test name needs "and" twice, it's testing too much — split it.
Every behavior gets both. A feature isn't tested until its failure modes are:
describe("OrderService.place", () => {
it("places an order when the cart has items and payment succeeds", async () => { /* happy */ });
it("rejects an empty cart", async () => { /* sad */ });
it("does not charge twice when called concurrently", async () => { /* sad */ });
it("surfaces a clear error when payment is declined", async () => { /* sad */ });
});
If you only wrote happy-path tests, you're not done — state that and add the sad paths.
it where practical.beforeEach for setup; keep tests independent and order-agnostic./tests, mirroring the domain or behavior: tests/orders/orders.test.ts (see code-architecture).data-access).Per CLAUDE.md: never report something works without running it. Run bun test and show the result before claiming a fix.