القائمة
テストを書く前に発動。仕様から観点とテストケースを導出するための 3 軸チェックリストと技法カタログ。実装の翻訳ではなく仕様の検証になるテストを設計する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
体験設計の壁打ちと UI デザイン案の提案。「こういう機能を作る」「この画面を良くしたい」を受けて、 どんな体験にするかを壁打ちして体験方針に合意し、方針に沿った UI 案を デザイン憲法（DESIGN.md）とトークンに準拠した 1 枚の HTML で提示する。 Use when: - /np-design を実行した場合 - 「デザイン案がほしい」「この画面のデザインを考えて」「どんな体験にすべきか相談したい」等の依頼 - 実装前にデザイン・体験の方向性を検討したいとき NOT for: - 実装そのもの（このスキルは提案まで。採用後の実装は別タスク） - 文言だけの微修正
Manages verification of markdown files against live web pages. Tracks progress (Unverified/In Progress/Verified), logs changes, and facilitates side-by-side editing. Use when: - User wants to check markdown documentation against a website - User asks to "start verification" or "compare files with the web" - Validation of scraped content is needed NOT for: - Creating new markdown files from scratch - PDF-only verification (PDF の扱いは references/pdf-handling.md を参照)
コード変更の品質ゲート。lint・テスト・ビルド検証 → コード品質レビューを実行する。
stripHeaders 文脈欠落チェックの検知ロジック・重症度判定・出力フォーマットのリファレンス。エントリポイントは /np:chunk-context-check コマンド。
GitHub Projects PM Agent。議事録からタスク抽出・Issue化、Projects初期セットアップを行う。キラーUX:「雑に議事録を投げるとタスク化してくれる」
ねっぷちゃん本番環境の利用分析レポート。会話数・ユーザー数・週別推移・トピック分析・印象的な話題を D1 から集計。
| name | test-writing-rules |
| description | テストを書く前に発動。仕様から観点とテストケースを導出するための 3 軸チェックリストと技法カタログ。実装の翻訳ではなく仕様の検証になるテストを設計する。 |
テストを書く前に発動し、対象機能に対して仕様ベースで最適なケース集合を設計するための指針。
vitest.config.ts の閾値ギリギリを稼ぐためのテストを書かないテストを書く前に毎回辿る:
createRoute の入出力 Zod スキーマ、Mastra ツールなら inputSchema / description、Repository なら呼び出し元のユースケース、フックなら Props 型と画面側の使われ方を把握references/perspectives.md）references/techniques.md）it の文章で表現する（// 技法: 〇〇 のラベルコメントは書かない）書き始める前に各軸で漏れを潰す。詳細は references/perspectives.md。
null / undefined / NaN）HTTPException の status・コード・message までアサート（error-handler で { error: { code, message } } に整形される）expect(...).toThrow(SpecificError) で型まで確認機能が触る基盤・ドメインに応じて当てる。実装の癖（特定 middleware の優先順位、特定 helper の init 忘れ等）はテスト観点ではなく実装詳細なので含めない。詳細は references/perspectives.md。
書いたケースが本当に効くか、頭の中で実装に小さな変更を入れて落ちるか確認:
> を >= に変えても落ちないテストは弱い&& を || に変えても落ちないなら不足return x を return undefined にしても落ちないなら戻り値検証が甘いPOST /admin/broadcast: scheduled_at が過去日時のとき 400 を返すdescribe のネストは 2 階層まで。深くなるならファイルを分けるvi.useFakeTimers() または DI された clock。new Date() 直接呼び出しはラップ提案を一緒に出すvi.fn() の典型用途）createTestDb() の in-memory SQLite / msw のリクエストハンドラ / vi.useFakeTimers() の仮想時計が該当）「どこに何があるか」ではなく「どう使うか」の指針。詳細パスは CLAUDE.md / server/CLAUDE.md / web/CLAUDE.md を参照。
beforeEach で毎回作り直して状態を隔離。テスト間で row を引き継がないRuntimeContext の中身を 必ず明示（特に env）。default を信用しないserver.use(...) を必ず書く。setup.ts が onUnhandledRequest: "error" のため未モック呼び出しは即落ちる。afterEach の resetHandlers でテスト間の漏れを防ぐTZ=Asia/Tokyo 固定で実行。時刻依存ロジックは vi.useFakeTimers() か DI された clock を使う。new Date() 直接呼び出しは避けるfoo.ts の隣に foo.test.ts）vitest.config.ts で除外されているファイル（Sentry init / Astro shell / 外部 SDK 連携の深い tsx 等）にカバレッジ目当てのテストを足さないテストを書く前に、必ず下記の形でケース集合を一度言語化する。これでテスト過多と漏れを同時に防ぐ。
対象仕様: <関数 / ルート / フックのシグネチャと責務>
採用技法: <同値分割 + 境界値 / 状態遷移 / デシジョンテーブル など>
書くケース:
- <観点>: <入力 → 期待挙動>
- ...
書かないケース（理由付き）:
- <観点>: <なぜ書かないか。例: Zod が境界で弾く / Hono router が同じ branch を踏む / 純粋関数で例外系が無い>
expect(true).toBe(true) 系の placeholderskip / only のコミットonUnhandledRequest: "error" で msw が落とすが、念のため）references/perspectives.mdreferences/techniques.mdreferences/examples.md