本文へ移動
cccskills
無料GitHub で公開

principle-test-behavior-not-implementation

Apply when you write, change, or keep a test. Identify a relevant defect and check that the test detects it. Assert the required result or observable effect, including absence when the contract requires it.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md2.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Test behavior, not implementation

Before keeping a test, name a relevant defect and determine whether the complete test arrangement detects it. Where practical, introduce that defect temporarily and observe the failure. Exercise the subject through its public interface and check the required result or effect.

  • A missing-result experiment helps when the contract requires a result. toBeDefined detects a missing result, but accepts the wrong one. Strengthen it to check the particular result when correctness requires one.
  • Keep absence assertions when absence is required. For a denied operation that must send no email, exercise the denial and check the outbox is empty. Temporarily make the denied path send an email and confirm the test fails. An assertion on absence does not require a positive case in the same test.
  • Keep fixed-value checks when the value is an explicit user-facing contract, such as a promised default or instruction. Name that contract and the defect a changed value would cause. Avoid freezing incidental constants or prompt wording with no such contract.
  • Keep comparisons between results when disagreement exposes a real defect. An expected result computed through the same faulty path as the actual result can confirm itself. Use an independent expectation or a relation that the identified defect actually violates.
  • Assess shared setup and the test body together. Calling the subject in beforeEach is valid; asserting only untouched fixture data is not.

Reject tests that exercise nothing relevant, assert nothing meaningful, or only show that a substitute was called without checking the required effect. Check its payload or resulting state when that establishes the contract. An assertion's syntax alone cannot tell you whether it detects a defect.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

architect

無料

Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.

日本語の概要は準備中です。原文の説明を表示しています。

michael-denyer/pstack-claude1,7882026年10月11日 更新

arena

無料

Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.

日本語の概要は準備中です。原文の説明を表示しています。

michael-denyer/pstack-claude1,7882026年10月11日 更新

Use for "automate me", "create/update/refresh my -mode skill", "turn/capture my preferences or working style into a skill", or wanting agents to follow how the user works. Drafts or revises a personal -mode skill via plugin-dev:skill-development + unslop, optionally pulling fresh evidence from recent transcripts.

日本語の概要は準備中です。原文の説明を表示しています。

michael-denyer/pstack-claude1,7882026年10月11日 更新

babysit

無料

Watch an open PR — fix failing CI, handle the straightforward review comments, and drive it to a mergeable state. Claude Code analog of Cursor's built-in /babysit. Use after opening a PR when the user wants the agent to shepherd it without re-prompting.

日本語の概要は準備中です。原文の説明を表示しています。

michael-denyer/pstack-claude1,7882026年10月11日 更新

Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you run a benchmark or report a speedup or regression you measured.

日本語の概要は準備中です。原文の説明を表示しています。

michael-denyer/pstack-claude1,7882026年10月11日 更新

Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', reviewing a small diff you don't trust, or a brief that asserts something about existing code ('make X public', 'X already handles Y') before you design against that assertion.

日本語の概要は準備中です。原文の説明を表示しています。

michael-denyer/pstack-claude1,7882026年10月11日 更新

michael-denyer のスキルをすべて見る

このスキルの問題を報告する