check

check skill の概要

check skill ができること

check skill は、コード差分、PR、issue のトリアージ、リリース準備、push、プロジェクト監査に向いたレビュー兼ゲート用のワークフローです。「この変更は安全に出せるか、何が壊れていて、マージ前に何を直すべきか」を素早く、しかし規律ある形で判断したい人に最適です。

この skill に向いているケース

check skill は、マージ前、リリース前、生成物の検証、後続作業の確認など、具体的な変更セットに対してコードレビューが必要なときに使います。特に、エージェントに最初に worktree を確認させたい場合、見えないローカル変更を避けたい場合、修正可能な問題と人の確認が必要な項目を分けたい場合に有効です。

check が他と違う点

check skill は、単なる「このコードを見て」という汎用プロンプトではありません。dirty な worktree や未追跡ファイルに対する明確な安全ゲート、レビュー優先のはっきりしたワークフロー、そしてアーキテクチャやセキュリティのリスクがあるときの専門レビューへの振り分けを備えています。そのため、check for Code Review のような単発プロンプトよりも、「いつ見るか」「何を見るか」「いつ止めるか」の迷いが少なく、精度が高くなります。

check skill の使い方

check をインストールして起動する

次のコマンドでインストールします。

npx skills add tw93/Waza --skill check

その後、差分、ブランチ、PR、リリース候補、コミット範囲、リポジトリ監査など、具体的なレビュー対象があるときに呼び出します。check usage では、「直近 3 コミットをレビューして」「この PR をマージ前に確認して」「依存関係更新後のリリース準備を監査して」のように、範囲をはっきり指定してください。

skill に適した入力を与える

check で最も強い入力は、「良いか？」のような曖昧な問いではなく、文脈付きで範囲が定まったタスクです。例えば次のような指示が有効です。

• 「マージ前に、この PR のセキュリティとアーキテクチャの回帰を確認して。」
• 「現在の worktree をレビューして、リリースを止める要因を教えて。」
• 「生成されたファイルを監査して、ソース変更と一致しているか見て。」

ブランチ名、コミット範囲、想定リリース、さらに「ファイルを変更しない」「公開リポジトリの文脈だけを見る」などの制約も含めると、範囲の広い曖昧なレビューになりにくくなります。

先に読むべきファイル

まず SKILL.md を読み、次に references/project-context.md と references/persona-catalog.md を確認して、レビューの深さ、専門家への振り分け、リリース基準を把握します。差分が信頼境界、API、import、モジュール構成に触れるなら agents/reviewer-security.md と agents/reviewer-architecture.md を使います。issue や PR に対するメンテナー向けのフォローアップがワークフローに含まれる場合は references/public-reply.md も重要です。

実務で役立つワークフローのコツ

レビューの前に、git status --short --branch -uall で worktree の安全確認を行うことが、この skill では前提になります。dirty や未追跡の変更があると、レビューの意味が変わるからです。より良い check guide の結果がほしいなら、エージェントに「指摘だけ返すのか」「安全な問題は修正してよいのか」「変更後にどの検証コマンドを使うべきか」を明示してください。

check skill の FAQ

check はコードレビュー専用ですか？

いいえ。check skill は、リリース準備、push、公開済みアーティファクト、issue と PR のトリアージ、プロジェクト全体の監査にも対応します。「出す前に判断する」要素があるタスクなら、通常のプロンプトより適しています。単なるコード読み取りだけの用途に限定されません。

いつ check を使わないほうがいいですか？

アイデアの発散、原因究明のデバッグ、文章の推敲には check を使わないでください。この skill は、具体的な差分と運用上のレビュー向けに設計されており、ブレストや物語的なフィードバック向きではありません。

check は初心者向けですか？

はい、対象と成果を言語化できるなら使いやすいです。初心者は、「何が変わったか」「何をレビューしてほしいか」「指摘だけほしいのか、安全な修正もほしいのか」をはっきり伝えると最も良い結果が得られます。それがないと、check install は簡単でも、check usage は広すぎて信頼性が落ちます。

ふつうのプロンプトと何が違いますか？

通常のプロンプトは、主観的なレビューを求めるだけになりがちです。check は、事前の安全確認、範囲の制御、検証の期待値、そしてセキュリティやアーキテクチャに対する専門ルーティングを加えた、規律ある手順を提供します。そのため、check for Code Review のような場面では、場当たり的なレビュー依頼よりずっと信頼できます。

check skill を改善するには

レビュー依頼をもっと具体的にする

最も有用な入力は、「何が変わったか」「なぜ変えたか」「何を壊してはいけないか」「どの種類のレビューが欲しいか」です。たとえば、「認証経路だけをレビューして」「リリース成果物に注目して」「このリファクタで公開 API が変わっていないか確認して」といった指示が有効です。これで探索範囲が絞られ、シグナルが上がります。

厳しい制約を先に明示する

パッケージング規則、生成ファイル、保護されたパス、必須の検証コマンドは skill に伝えてください。リポジトリに build や release の正本があるなら、それも最初に共有します。そうすると、過度な安心感を避けられ、check skill がずれ、成果物不足、危険な後続作業を見つけやすくなります。

ほめ言葉ではなく、指摘から反復する

最初の結果を受けたら、再確認したい指摘内容か、適用したパッチを正確に返してください。セキュリティ、アーキテクチャ、リリース準備のように、1 回に 1 つのリスク領域へ絞って再チェックを依頼すると、skill はさらに精度が上がります。出力が広すぎると感じたら、詳細化を求めるのではなく、スコープを狭めてください。