Skill.md検索

ソースコード・ドキュメント・Web リソースを徹底的に読み込み、調査内容を体系的にまとめる 調査結果を report/.md に自動保存し、基準コミットを記載した正式なレポートを生成する 調査内容の要約をわかりやすく報告し、分析根拠となるコード箇所やドキュメント参照を明記する プロジェクトの全体像を把握したい企画・マネージャー 技術的な課題や仕様を調べる際に、正式な記録に残したい開発チーム 意思決定の根拠となる詳細な調査レポートが必要なリードエンジニア ユーザーから調査・分析を依頼されたときの実施手順。①調査対象に関連するソースコード（関連モジュール全文）、ドキュメント（README.md, CLAUDE.md, TODO, plan.md, backlog/）、Web リソース（必要に応じて Web 検索）を徹底的に読み込む。②調査結果を report/.md に保存し、冒頭に基準コミット（git rev-parse --short HEAD）を記載する。③要約、詳細分析、根拠となるコード箇所・ドキュメント参照を含めてレポート構成する。④調査結果の要約をユーザーに報告する。禁止事項として、部分的なファイル読み取りで全体確認と報告すること、推測や一般論のみでレポート構成、レポート作成なしの口頭のみ報告、基準コミット未記載での作成を禁止。

実装前にテスト設計で漏れを防ぐ: 正常系・異常系・境界値を事前に整理し、実装のやり忘れやバグを事前防止します。テストコードが仕様書になるため、後の保守も容易になります。 RED → GREEN → REFACTORの流れで品質を担保: テスト失敗を確認してから実装を始め、テストに通す最小限のコードだけを書き、その後に整理・改善します。こうすることで、意図しない副作用のない堅牢なコードが完成します。 変換機能の変更時にE2Eテストで動作確認: コード内での変換処理を変更した場合、自動的に実行結果テストも加えるため、実際のユーザー利用時のバグを防ぎます。 リファクタリングの安全性を確保: テストが全て通る状態を保ちながらコードを整理できるため、既存機能を壊す心配がなく、自信を持ってコード改善に進めます。 新機能開発やバグ修正に着手するエンジニア: テスト駆動で品質を保ちながら、効率的に実装を進めたい人。 レガシーコードの保守・改善を担当するチーム: テストがない中での修正は危険ですが、テスト駆動に切り替えることで安全な改善が可能になります。 開発チームのコード品質を上げたいテックリード: テスト駆動を標準プロセス化することで、チーム全体の実装品質と保守性を向上させたい人。