references__rules.md

Rules

Assertion shape

• Write assertions as expect(actual).toEqual(expected).
• Do not use toBe for these normalization tasks unless explicitly requested.
• Do not use toContain.
• In Vitest, use test() and do not use it().
• Enforce 1 test() = 1 expect().
• First try to merge multiple field-level assertions into one object-level assertion.
• If concerns are different, split into multiple test() blocks.
• If the same pattern repeats across cases, use test.each().

Statement order in each test

• Declare const expected = ... as the first statement in each test(...) function.
• Then declare inputs/fixtures.
• Then declare actual.

Object/array literal typing

• For object literals and array literals in tests, use as const satisfies ....
• Use Parameters<T> or ReturnType<T> in the satisfies type source.
• Do not add direct variable type annotations such as const v: string[] = [].
• Use satisfies-based typing instead.
• Prefer Parameters<T> / ReturnType<T> for type derivation to avoid extra type imports.
• Always try to reduce import lines, even by one line, when the same type can be derived locally.

Type aliases

• If the same type expression appears 3 or more times, define a type alias at file top.
• Keep alias names short, contextual, and consistent within the file.
• For expected value typing, use type Expected = ....

Implementation/test pairing

• Keep implementation and tests 1:1 by function.
• Do not keep multiple function tests in one test file.
• If tests are split by function, split implementation files accordingly.
• Keep imports aligned with split files.

Output discipline

• Preserve existing behavior.
• Prefer minimal diffs.
• Run only affected tests and report pass/fail.

SKILL.md

name	description
test-style	Enforce strict test-writing conventions when creating or editing TypeScript/Vitest tests in this repository. Use when requests include formatting or refactoring of tests, especially around expected/actual order, expect(actual).toEqual(expected), as const satisfies usage, type alias naming, and implementation-to-test file pairing rules.

Test Style

Apply these rules when touching test code.

Follow this order

1. Read the target test and implementation files.
2. Normalize tests to the rule set in references/rules.md.
3. If tests were split by function, split implementations to keep 1:1 mapping.
4. Run only the affected test files.
5. Report changed files and rule compliance.

Load references

• Always read references/rules.md before editing tests.
• Treat the rules as mandatory unless the user explicitly overrides them.