Skill.md検索

GitHub プルリクエストを統一された標準フォーマットで作成・更新でき、チームのコードレビュープロセスを効率化できます。 実装内容（何が変わったか、何が良くなるか）を人間向けの自然な文章で記録し、動作確認の結果と実装メモを一箇所に集約できます。 計画や技術的意思決定は Issue に記録し、PR は実装結果のみに集中させることで、ドキュメント管理の役割分担を明確化できます。 Verification チェックリスト（対象機能の動作確認、既存機能への影響確認）により、マージ前の品質確認を可視化できます。 チーム全体で PR フォーマットを統一し、コードレビューの効率を上げたい技術リード 実装の意図と実装結果を明確に分離して管理したいエンジニアチーム Issue と PR の役割分担を徹底し、ドキュメント管理を整理したい開発チーム 実装時に気づいた補足情報や次回への申し送りを体系的に記録したいコントリビューター PR の目的は「何が変わったか」を人間がレビューできるようにすること。必須セクション: (1) closes 行（Issue リンク）、(2) 冒頭の概要（見出しなし、自然な文章で何が変わるか・何が良くなるかを記述、リスクや影響を含める）、(3) Verification（実際にブラウザ操作や API 呼び出しで確認した内容、test/build などの技術的チェックは含めない）。ルール: 計画・技術的意思決定は Issue の Plan セクションに記録して PR には書かない。必須セクション後に任意セクション（Implementation Notes、Breaking Changes、Screenshots など）を自由に追加可能。Claude が残したい実装メモは何でも記録してよい。プロパティ形式（「リスク評価:」など）は使わない。Notion タスクが存在する場合は closes 行に [TASK-{番号}](Notion URL) を追記。

実装の判断理由・技術的課題・依存関係を構造的に記録し、別のセッションで同じ内容を何度も検討し直す無駄を排除できます。 AIが後で同じプロジェクトに戻ったとき、Issue記事だけで前回の思考を完全に追え、実装を即座に再開できます。 冒頭を「人間向けの説明」に、詳細を「技術セクション」に分けることで、チーム全体で進捗状況を共有でき、非エンジニアメンバーも状況を把握できます。 検討した代替案・デバッグログ・試行錯誤の記録を自由に追記でき、意思決定の過程が透明になります。 長期プロジェクトで実装の文脈を失わないようにしたい開発者 AIとの連携で開発効率を高めたいチーム 複数人で同じコードベースを触り、進捗状況を詳しく共有したい場面 技術的な判断の経緯をドキュメント化しておきたい人