「テスト」の検索結果

機能追加や仕様変更の要件を確認し、設計・テスト・実装順を含むプランを作る。プラン作成や実装前の設計を依頼されたときに使う。

実装が一段落したら、PR本文を課題・解決策・テスト結果・レビュー観点の 形に整形して下書きし、承認を取ってからGitHubへ投稿する。「PRを作って」と 頼まれたときに使う。

リファクタリング（構造変更）と機能変更（behavior change）が同一 diff に混在していないかを識別し、structural change に対する external behavior preservation の証拠（テスト・型・静的解析）が揃っているかを diff-time で確認する。証拠不足のときは Characterization Test 追加を促すか question とする。DTO/公開 API の破壊的変更検出は api-compatibility、完了主張の反証や抽出リファクタの性能特性退行は refactor-claim-audit、新知識の命名・責務・境界への反映は knowledge-to-code-alignment、投機的抽象化・スコープ逸脱は altitude-generalization / fix-scope-integrity へ委譲する

検査器（linter / ガード / CI ゲート / バリデータ / フィルタ）そのものの検出力が差分で静かに落ちていないか、また新設した検査が実際に検出できることが実証されているかを diff-time で検出する。Check 1 unverified detection reduction（検査器の検出ロジック（正規表現・除外パターン・解決集合・allowlist・baseline）を変更して検出件数が減ったのに、減った 1 件ずつが誤検出であった根拠が示されないまま「誤検出を潰した」「N → M 件に減少」と改善として主張している）、Check 2 unproven guard detection power（新しい検査ロジック・CI ゲート・バリデーションを追加・変更したのに、検出すべき入力を注入して検出されること／検出すべきでない入力で黙ることを示す変異注入の証跡が無く、「追加した」「CI が緑」を検出力の証拠として扱っている）、の 2 Check を対象とする report-only。テスト自身のアサーションが実質何も検証していない構造は test-assertion-effectiveness、レビュー基準・品質ゲートの明示的な弱体化（ルールの削除・閾値の引き下げ・suppression entry 追加・lint ルールの無効化）は review-criteria-integrity、リファクタ完了主張一般の検証は refactor-claim-audit、workflow の permissions と action pin は gha-workflow-security、設定ファイルの構文・型の妥当性は config-json へ委譲する

アプリケーションコードでの自動脆弱性検出のための静的アプリケーションセキュリティテスト（SAST）ツールを設定します。セキュリティスキャンの設定、DevSecOps実践の実装、またはコード脆弱性検出の自動化時に使用してください。

スケーラブルな自動化のためのマルチステージワークフロー、キャッシング、分散ランナーを備えたGitLab CI/CDパイプラインを構築。GitLab CI/CDの実装、パイプラインパフォーマンスの最適化、または自動テストとデプロイメントのセットアップ時に使用。

互換性分析、段階的ロールアウト、包括的テストを伴うメジャー依存関係バージョンアップグレードを管理します。フレームワークバージョンのアップグレード、メジャー依存関係の更新、またはライブラリの破壊的変更の管理時に使用します。

実装済み機能の仕様変更。要件定義書と基本設計を先に更新してからコード修正→テスト→レビューを実行する。 変更種別を自動判定し、実装はAgent(Sonnet)に委任可能、レビューは本体が直接実行する。 「アップロード上限を10MBに変えて」「この画面にフィールド追加して」「○○の仕様を変更して」 「○○を修正して」「バリデーションを変えて」などのリクエストで使用する。 既に実装済みの機能を変更するときに使う。新規実装はimplement-spec。

Specに基づく新規機能実装。要件定義書と基本設計を読んで実装プラン作成→コード実装→テスト→レビューを実行する。 実装はAgent(Sonnet)に委任可能、レビューは本体が直接実行する。 「REQ-AUTH-001を実装して」「ログイン機能を作って」「○○を実装して」 「これを作って」「実装に入って」などのリクエストで使用する。 要件定義書が存在する未実装機能を新規実装するときに使う。既存機能の変更はrevise-spec。

設計ドキュメントに基づいて実装計画を生成します。ScalarDB特有のスキーマ定義、トランザクション実装、統合テストを含む実装可能なタスク指示書を作成し、フェーズ別の実装ロードマップを提供します。

完了宣言の前にエビデンスを収集・確認する。証拠なき成功宣言は不正。「完了前チェック」「本当に動く？」「確認して」「検証して」「コミット前に確認」で発動。実装完了時、バグ修正後、テスト通過を宣言する前に使う。

This skill should be used when the user asks to "verify", "test", "check installation", "動作確認", "テスト", "ヘルスチェック", or wants to verify that the bengo-toolkit plugin is working correctly.

interact_block ツールの使い方。レバー、ボタン、ドア等を操作・テストする前に読む。

test ツールと CircuitTest Python DSL の書き方。test を実行する前に start_session でセッションを開始し、その session_id を指定する。回路の自動テストを作成・実行する前に必ず読む。

過去の成功知見から抽出したレッドストーン回路設計の普遍トラップ集。回路設計・テストコード記述前に必ず読むこと。フレームワーク/DSLの誤用で試行回数を枯渇させるのを防ぐ。

kill_entities ツールの使い方。テスト前のエンティティ掃除やボート等の削除に使う。

CLI版 mc-cli kill-entities コマンドの使い方。テスト前のエンティティ掃除やボート等の削除に使う。

CLI版 mc-cli interact-block コマンドの使い方。レバー、ボタン、ドア等を操作・テストする前に読む。

プロジェクト（特にこのテンプレートから始める新規プロジェクト）にClaude Code用の.claude/環境を対話形式で段階的にセットアップする。settings.jsonの権限・hooks設定、必要に応じたカスタムskill・command・subagentの雛形作成、CLAUDE.mdのビルド/実行/テストコマンド欄の穴埋めを行う。「セットアップして」「環境構築して」「init」「このプロジェクトでClaude Codeを使えるようにして」「開発を始めたいので準備して」といった依頼で積極的に使うこと。エンジニアが常駐しない・少ない組織で「事故らないようにしたい」「危険な操作を防ぎたい」「lint/testやセキュリティレビューが誰もチェックしないまま放置されるのを防ぎたい」といった要望がある場合も、権限・hook・レビュー体制を通じた安全網の構築としてこのスキルが対応する。既存の/initスキルはCLAUDE.mdのコードベースドキュメント生成に特化しているが、権限設定やskill/command/agentの追加が絡む場合は必ずこちらを使う。

Kent Beck/t-wada 流の TDD でテストコードとプロダクションコードを実装する。Triggers on: '/tdd-impl', 'TDDで実装', 'TDD実装'

品質ゲート（lint・型チェック・テスト）を実行し、必須ゲート通過を機械可読な結果で返す。Triggers on: '/quality-check', '品質チェック', 'QCして', 'quality gate'

WSL のワーカーから Windows 版 Chrome を headless で叩き、WSL 側に立てたプレビュー サーバの画面を PNG で撮るレシピ。サーバ起動と撮影を 1 つの Bash 呼び出しにまとめ、 その呼び出しだけ sandbox を外す・1 枚目は捨て撮り・出力先は UNC でワークツリー、 という固定手順と、撮れていないときの症状の弁別（`ss -ltnp` / WSL 側 curl）を含む。 「WSL から Windows Chrome で画面を撮る」「rondo の画面のスクリーンショットを撮る」 「before/after を撮り比べる」「ライト / ダークを撮り分ける」等で発動。 撮影を伴わない UI 実装・テストには発動しない。

GitHub Issue を読み込み、`_/local-plans/<issue-number>-<slug>.md` に詳細計画を作成して**ユーザー承認後**にコードを実装する。実装後はセキュリティレビュー (OWASP Top 10) → テスト実行 → Conventional Commits でコミット。Issue 番号や URL を渡された実装依頼、「Issue #N を実装して」「この Issue を着手」などで使用。

Vitest (Vite ネイティブテストフレームワーク) リファレンス。 test, describe, it, expect, vi.fn, vi.mock, vi.spyOn、 beforeEach / afterEach / beforeAll / afterAll、coverage (v8 / istanbul)、snapshot、 vitest.config.ts、ワークスペース、ブラウザモード、UI モード、bench。