Skill.md検索

ローカルの未コミット変更を自動レビューし、バグやセキュリティ問題を事前に検出できます。 変更内容を「必ず直す」「できれば直す」「注意点」「確認済み」の4段階に自動分類し、優先度をつけて報告します。 プロジェクトの要件ファイルや実装計画を読み込んで、変更が目的に合致しているか確認できます。 コーディング規約（Style Guide）との違いを検出し、ルール違反を自動で指摘します。 変更されたコードだけを対象に、ロジックバグ・セキュリティ脆弱性・設計の不整合を具体的なシナリオ付きで説明します。 Gitの変更内容を本当に正しいか自信がない開発者 コードレビューを受ける前に自分でチェックする癖をつけたい人 チーム内での指摘ルールを統一したい開発リーダー セキュリティやバグ潰しを確実にしたい品質重視のチーム 処理は以下の順序で実行されます。①プロジェクトの要件定義・実装計画ファイルを読み込んでコンテキストを把握、②git diffとgit diff --stagedで差分を取得、③git ls-files --others --exclude-standardでuntracked ファイルも収集、④正当性（ロジックバグ・境界条件・エラーハンドリング）、セキュリティ（秘密値露出・入力検証・権限昇格）、設計（公開面の意図しない変更・既存との契約不整合）、規約準拠（コーディング規約違反）の4観点で順序よく確認、⑤リポジトリの規約ファイルを読み込み、⑥各指摘について該当コードと周辺を実際に確認して具体的な失敗シナリオを言語化。指摘を「MUST-FIX（正当性バグ・セキュリティ問題・データ損失・公開面の意図しない破壊）」「SHOULD-FIX（規約違反・エラーハンドリング不足・命名と実装のずれ）」「NOTE（将来問題になりうる設計判断）」「CHECKED（問題ないと確認した項目）」に分類して報告します。

実装作業を終えたときに、レビュー内容・学んだ点・困ったことを自動で日誌ファイルに記録できます。 タイムスタンプ付き（YYYY-MM-DD_HHmmss形式）で過去の日誌と同じフォーマットで保存されるため、後から見返しやすいです。 日誌には「レビュー指摘と対応」「見逃していた問題」「手こずったポイント」の3項目を記載でき、実装プロセスの改善に役立てられます。 毎日の開発業務を記録し、成長を振り返りたい開発者 チーム内でレビューコメントの対応状況を共有したい人 過去の実装で何に詰まったかを記録して、同じ問題を繰り返さないようにしたい人 実装プロセスを可視化し、後のドキュメントやナレッジベースに活かしたい人 処理は4つのステップで実行されます：① date +%Y-%m-%d_%H%M%S コマンドで現在日時を取得、② Glob で既存の diary/*.md を検索し、直近の日誌があれば読み込んで記述スタイルを参考にする、③ diary/YYYY-MM-DD_HHmmss.md ファイルに新しい日誌をWrite、④ 呼び出し元に「DIARY_DONE」と報告します。記載内容は以下の3項目です。「レビュー内容」はレビューで指摘された内容と対応結果を記載し、指摘がなければその旨を記載。「見逃しの考察」はレビューで初めて気づいた問題、またはレビューなしでは見逃していた可能性のある点を記載し、なければ「なし」と記載。「手こずったこと」は実装中に詰まった点や解決に時間がかかったことを記載し、なければ「なし」と記載します。

レビュー指摘の収集と分類: GitHub の未解決レビュースレッドを自動取得し、各指摘を MUST-FIX（修正必須）/ DISCUSS（要相談）/ SKIP（対応不要）に自動分類できます。 コードに基づく検証: レビュアーの指摘が正しいか、ローカルコードで実際に確認します。コードを読まずに正しいと仮定しません。 MUST-FIX 項目の自動修正: 正当性バグ、リグレッション、セキュリティ問題、隣接コードとの不整合など、修正が必須な項目を自動で直します。 スマート な返信と Resolve: 修正した thread には簡潔に返信して resolve し、DISCUSS・SKIP の thread は理由を返信して resolve しません。 スコープ管理: PR diff に含まれるファイルと直接依存のみを修正対象とし、CI・認証・セキュリティ設定の変更は人間に回します。 PR レビューを受けたが、指摘が本当に正しいか確認してから対応したい開発者 レビュー指摘の対応で何を修正し、何をスキップするか判断基準を欲しい人 修正と議論を効率よく分離したいチーム コードベース全体の文脈を持つ人による、自動化された修正検証が必要な環境 このスキルは PR レビューコメントを単に鵜呑みにせず、検証・分類を経てから実装します。処理フロー は4ステップです。 (1)収集：GitHub の未解決 review thread とコメントを取得（resolved 済みは無視）。(2)検証：各コメントの主張をローカルコードで裏取りし、該当コードと周辺を読んで、現在の実装にその形である理由があるか、修正すると既存機能が壊れないか確認。(3)分類：検証結果に基づき、MUST-FIX（正当性バグ、リグレッション、セキュリティ問題、明確な不整合）/ DISCUSS（スコープ拡大提案、アーキテクチャ判断が必要、意見が分かれる）/ SKIP（スタイル好み、nit、推測的提案、重複、事実誤認）に振り分け。(4)実装と返信：MUST-FIX に分類した項目のみ直し、修正した thread に簡潔に返信して resolve。スコープ制限として、PR diff に含まれるファイルとその直接依存だけを触り、CI・認証・セキュリティ設定変更は人間に回します。

変更内容を自動整理してコミット — ステージングから実際のコミットまでの操作を一連で行い、手動入力を減らします。 コミットメッセージを安全に記録 — 引数の括弧エスケープのような複雑な処理を自動化し、タイプミスなく正確にメッセージを記録できます。 プロジェクト規約に合わせたコミット — CLAUDE.md に定義されたコミット規約を遵守し、チーム全体で一貫性のある履歴を残します。 Git の日々のコミット作業を効率化したい開発者 チーム全体でコミットメッセージの形式を統一したい 実装完了後の最後の一手を自動化したい人 コマンドラインの複雑な引数処理を避けたい非エンジニア向け操作者

GitHub Issue を自動でクローズできます。クローズ時にコメントを同時に追加することも可能です。 コメント本文を安全に渡すため、一時ファイルを経由して処理するため、特殊文字や改行を含むコメントでも確実に投稿できます。 クローズのみ、またはコメント＋クローズなど、必要な処理だけを選択して実行できます。 GitHub で Issue を大量に管理している開発チームのマネージャー 自動化ワークフローで Issue 処理を効率化したい人 反復的な Issue クローズ作業を削減したい人