Skill.md検索

技術的な重要判断を「判例」として記録：なぜその技術やアーキテクチャを選んだのか、あるいは実装を見送ったのかを、背景と理由とともに正式に文書化できます。 同じ議論の繰り返しを防止：過去の判断理由が明確に残るため、同様の提案が再度上がった際に「前にこう決めた」と根拠を示して説明できます。 新規メンバーやAIが判断基準を理解：プロジェクトの設計思想や制約条件が明文化されるため、新しい開発メンバーやAIエージェントが文脈を理解した提案・実装ができるようになります。 プロダクト哲学との一貫性を保証：CLAUDE.md などのプロジェクト原則と ADR の関連を明記することで、散発的な判断ではなく一貫性のある方針を維持できます。 将来の再検討を明確化：状況が変わった場合に「なぜ当時この決定をしたのか」を参照して、改めて検討する際の材料とできます。 技術選定やアーキテクチャ設計を議論するエンジニア・技術リード 「やらないこと」を明確にして意思決定を記録したいプロダクト・プロジェクト担当者 チーム内で設計思想や制約を共有・継承したい組織やスタートアップ AIエージェント との協働時に、プロジェクトの判断基準を明確にしたい開発チーム このスキルは、Architecture Decision Record (ADR) を作成するためのワークフローです。ADRは人間が下した重要な技術的・機能的判断を記録した「判例」で、過去の判断の経緯と理由を明確にし、同じ議論の繰り返しを防ぎ、新規メンバーやAIが判断基準を理解する助けとなります。 ADR作成が必要な場面：①機能の実装を見送る判断（最も重要）、②ライブラリやフレームワークの技術選択、③アーキテクチャパターンの採用・不採用、④パフォーマンス最適化方針、⑤意図的に選択した設計上の制約、⑥UX・ワークフロー設計やセキュリティに関するプロダクト方針 ADR記述の原則：客観的に記述（感情的表現を避ける）、コンテキスト明確化（なぜ必要だったか）、プロダクト哲学との関連明示、将来変更の余地を残す、簡潔かつ具体的、今回固有の判断と一般原則を区別、将来の判断への影響を考慮する ADR構造：タイトル、ステータス（決定済み/提案中/廃止）、コンテキスト（背景・問題・提案）、決定内容、複数の理由、判断基準の適用（CLAUDE.md との関連含む）、影響、代替案（オプション） 作成ワークフロー：既存ADRを確認→番号決定→コンテキスト整理→判断明確化→理由記述→ファイル作成・格納。軽微なバグ修正やバージョンアップなどはADR不要です。

技術的課題を自動抽出 - パフォーマンスボトルネック、エラーハンドリング不備、型安全性の問題、セキュリティ懸念などを自動検出し、優先度付きで報告できます。 アーキテクチャ問題を明確化 - ディレクトリ構造、関心の分離、データフロー設計、API一貫性、テスト戦略、スケーラビリティなどをレビューし、大規模改善の方向性を示します。 UI/UXの課題を可視化 - ユーザーの思考中断要素、初回体験、レスポンス速度、エラー時の体験、アクセシビリティなどをプロダクト哲学に基づいて評価できます。 既存機能とプロダクト哲学のズレを検出 - 各機能がプロダクトビジョンや5つのコア原則に沿っているか評価し、改善の必要性を提案できます。 改善提案をGitHub Issueで一元管理 - 分析結果を自動的にGitHub Issueとして起票し、改善トラック（守りの改善）と価値創造トラック（攻めの改善）に分類できます。 プロダクトマネージャー - コードベース全体の課題を可視化し、プロダクト戦略に基づいた優先順位付けができます。 技術リード・アーキテクト - 複数の観点から技術的課題を網羅的に把握し、大規模な改善提案を具体化できます。 開発チーム全体 - 5つのエージェントが並行分析するため、短時間でコードベース全体の改善点を把握でき、チーム間での優先度合意が形成しやすくなります。 プロダクト開発が停滞していると感じるチーム - 既存機能の改善だけでなく、新しい価値創造の提案も受け取でき、プロダクト成長の方向性を再発見できます。 Taskツール（subagent_type=Explore）を使って、以下の5つのエージェントを1つのメッセージで同時起動：①技術的課題分析（パフォーマンス、エラーハンドリング、型安全性、セキュリティ、コード重複、依存関係を調査）、②アーキテクチャ分析（ディレクトリ構造、関心分離、データフロー、API設計、WebSocket/Yjs同期、テスト戦略、エラー回復、スケーラビリティを検証）、③UI/UX分析（ユーザー思考中断要素、初回体験、レスポンス速度、エラー時体験、アクセシビリティ、モバイル対応、CSS一貫性を評価）、④既存機能の哲学適合性分析（プロダクトビジョン「悩むから考えるへ」と5つのコア原則への合致度を評価）。各エージェントは課題・場所・影響・改善案・優先度を形式化して報告し、分析結果をGitHub Issueとして自動起票します。提案は改善トラック（既存機能の技術的・UX的改善）と価値創造トラック（新しい使い方・機能でプロダクト価値拡大）の2つのトラックに分類されます。