Skill.md検索

人間と対話しながら設計書（design.md）を作成し、タスクの要件を明確化できます。曖昧な部分があれば必ず確認し、独断で判断しません。 設計レビューAI・プラン作成AI・実装AIなど複数のAIエージェントをチーム化し、設計→実装のサイクルを一貫して管理できます。 コード修正は実装AIに任せ、自分はレビュー・判断・対話に集中することで、効率的な開発ループを回せます。 既存の仕様書（docs/）を参照しながら設計を進め、スコープ外のタスクは後回しリストに自動で追記できます。 チーム開発でAIを複数使い、設計から実装まで一貫管理したい開発リーダー 曖昧な要件を明確化してから開発に進みたいプロジェクトマネージャー 実装の詳細よりも「何を作るか」「なぜそう設計するか」に時間を使いたい開発者 設計レビュー→プラン作成→実装→検証のループを効率化したい組織 開発パートナー（御子）スキルは、TeamCreate を使い複数のAIエージェント（設計レビュー、プラン作成、実装等）をチーム管理するシステムです。主要フローは「考える（人間と対話して design.md 作成）→ チームを作る → 設計レビュー → プラン作成 → 作る/触る/振り返るループ」の5段階。design.md が完成後、設計レビューAI（design-review.md 指示従行）で指摘受け、問題あれば人間と相談して修正。その後プラン作成AI（planner.md）とプラン照合AI（plan-review.md）が直接やりとりして plan.md 完成。実装フェーズではループ中 docs/ 変更禁止（incidents.md と todos.md 除く）、実装AI（implement.md）常駐で plan.md から実装。変更あれば design.changelog.md 記録し「design.changelog.md を確認して実装せよ」と指示し再ループ。エージェント自身に設定ファイル読ませ、メインコンテキスト汚染を防ぐが特徴。

実装コードから機能を客観的に説明：設計ドキュメント（design.md）を参照せず、コードから読み取れる事実だけを積み重ねて、そのコードが「何をしているか」を明確に説明します。 第三者視点で実装を可視化：設計者の意図を推測せず、コードそのものの振る舞いを説明するため、設計と実装のズレを客観的に発見できます。 要件とコードの矛盾を浮き彫りに：「設計では X のはずだが、実装は Y している」という乖離を発見し、修正対象を明確にします。 新しいチームメンバーへのオンボーディングを加速：コードから読み取れる事実に基づいた説明があれば、設計意図を別途学習する前に、コードの動作を素早く理解できます。 explanation.md として説明資料を自動出力：タスクディレクトリにexplanation.mdを自動生成し、レビュー・チーム内共有に即座に活用できます。 コードレビュアー：実装がドキュメントと一致しているか、客観的に検証したい人 新しいチームメンバー、オンボーディング対象者：設計意図を抜きにして、コードそのものを理解したい人 プロダクトマネージャー：実装が要件通りか、技術的サポートなく確認したい人 品質保証（QA）エンジニア：テストケース設計の前に、実装の動作を正確に把握したい人 スキルの呼び出し形式：/explain {task_dir} [注意事項]（例：/explain otuge/data-table）。3つの制約：otuge/内のdesign.mdは絶対に読まないでください、設計意図は推測しないでください、コードから読み取れる事実だけを述べてください。説明のポイント：「なぜこうなっているか」ではなく「何をしているか」を説明、実装コードを読み込んで具体的な処理フローを述べる。結果は{task_dir}/explanation.mdに書き出す。

セキュリティ脆弱性を自動検出 — シークレット情報の漏洩、認証チェック漏れなど、本番環境で深刻な問題となりうるバグを見つけ出します。 バグやエラーを事前に指摘 — デバッグコードの残存、エラーハンドリング不足など、本番環境で問題を起こしやすい箇所を洗い出します。 パフォーマンス問題を提案 — 不要な再レンダリングや N+1 クエリなど、ユーザー体験を損なう処理を特定し改善案を提示します。 コード品質の改善点を提案 — 重複コード、わかりにくい変数名など、チーム全体の開発生産性を高める改善提案を行います。 プルリクエスト作成前にコード品質をチェックしたい開発者 セキュリティバグを本番環境へのリリース前に防ぎたいチームリーダー 新人エンジニアのコードレビューを効率的に進めたい現場 保守性の高いコードベースを維持したい開発チーム