Skill.md検索

開発フロー統率: 設計 → プラン作成 → 実装 → 説明照合 → 設計照合 → コードレビューの6フェーズを複数のサブエージェント（実装AI、説明AI、設計照合AI、コードレビューAI）で統率し、一貫性のある開発を実現します。 複数AI間の天議（てんぎ）: 方針の判断に迷った時や複数の選択肢から最善を決める場面で、複数エージェント間の議論を自動起動して整理された判断材料を得られます。 簡易修正の直接実装: スタイル調整やデフォルト値変更など軽微な変更は自分で直接編集でき、フローを回す手間を削減します。 スコープ外タスクの一元管理: 「後でやる」「スコープ外」と判断されたことをtodos.mdに記録し、開発期間中は集中力を維持できます。 プロジェクトリード: 複数のAIを使いながら設計から実装まで統率したい人 デザイナー・アーキテクト: 要件定義から詳細設計まで対話的に詰めたい人 開発マネージャー: 3AI駆動方式で開発フロー自体を改善したい人 個人開発者・スタートアップ: AIの力を活用して開発効率を最大化したい人 開発パートナー（御子）は、人間と直接対話する唯一のエージェントとして、設計・実装の統率から簡易修正、開発フロー改善まで担います。開発フロー禁止事項として、実装中にdocs/を変更しません（例外：.claude/incidents.md、docs/reference/explain-effectiveness.repo.md、docs/todos.md）。Phase 1は人間との対話で設計.mdを完成させます。Phase 2でプラン作成AIをfork → plan.mdとdesign.mdを照合、問題に応じて再forkか設計更新を行います。Phase 3で実装AIをfork、Phase 4で説明AIをfork → explanation.mdとdesign.mdを照合、問題があればdocs/reference/explain-effectiveness.repo.mdに記録します。Phase 5で設計照合レビューAI、Phase 6でコードレビューAIをfork。完了後はdesign.mdを元にdocs/に知識を反映し、otuge/{タスク名}/を削除してコミットします。引き継ぎの場合は既存ファイルから現在フェーズを特定して報告します。

実装されたコードを読み込んで、設計背景や意図を推測せず「何をしているか」を客観的に説明します。 コードから直接読み取れる事実（データフロー、処理順序、条件分岐など）のみを記述した説明書を自動生成します。 説明結果をマークダウン形式で {task_dir}/explanation.md に出力し、チーム内での理解共有を加速させます。 design.md などの設計ドキュメントに依存せず、コード単体で理解できる客観的な説明を提供します。 他チームが書いたコードの動作を正確に把握したい開発者 レビュー時にコードの客観的な説明が必要なテックリード ドキュメント化されていないレガシーコードの動作を理解したい保守エンジニア コード解析を自動化して時間を短縮したいプロジェクトマネージャー 引数 /explain {task_dir} [注意事項] で実行。{task_dir} はタスクディレクトリのパス。実装コードを読み込んで、何をしているかを説明する。制約として、otuge/ 内の design.md は絶対に読まない、設計意図は推測しない、コードから読み取れる事実だけを述べる、「なぜこうなっているか」ではなく「何をしているか」を説明する。結果を {task_dir}/explanation.md に書き出す。

セキュリティ脆弱性の検出: ハードコードされたシークレット、認証・認可チェックの欠落、SQL インジェクション、XSS などの脆弱性（セキュリティ上の穴）を自動で発見します。 品質問題の指摘: デバッグコードの残存、エラーハンドリング不足、パフォーマンス低下の可能性など、実装品質の問題をリスト化して報告します。 保守性改善の提案: コードの重複、わかりにくい変数名、不足している型定義など、将来の保守を困難にする問題を検出します。 優先度付きレポート出力: Critical（必修正）→ Warning（推奨）→ Suggestion（検討）に分類し、対応順序を明確にしたレポートを出力します。 開発チームのコードレビュアー: 手動レビューの手間を減らし、見落としやすい問題を自動検出したい方 セキュリティ意識が高いプロダクトチーム: リリース前のセキュリティチェックを自動化したい組織 品質基準を統一したい管理者: チーム全体で一貫した品質ガイドラインを適用したい方 保守性を重視する開発者: 長期的に管理しやすいコード品質を継続したい方