Skill.md検索

ドキュメントの陳腐化を自動検出：README、tech.md、plan.mdなどが実際の開発状況と乖離していないかを自動判定し、最新化が必要な箇所を一覧化できます。 GitHub Issue との整合性を確認：オープン中のIssueや完了済みIssueが、プロジェクト計画ドキュメントに正しく反映されているか確認でき、計画と実装のズレを防げます。 コマンド・環境構成の正確性を保証：package.jsonのスクリプトやディレクトリ構成が実際に存在するか確認することで、セットアップ手順の実行エラーを事前に防げます。 プロジェクト全体の現況を可視化：複数のドキュメントから統一的に現状情報を抽出し、ステークホルダーに分かりやすく報告できます。 更新前に変更内容を明示：修正内容をユーザーに提示して承認を得てから実施するため、誤った情報削除を防げます。 複数のプロジェクトドキュメントを管理している技術リード・CTO プロジェクト進行状況をステークホルダーに定期報告するPM 新しい開発者のオンボーディング前にドキュメントを最新化したいチームリーダー プロジェクト Wiki や Confluence を常に最新状態に保ちたい組織 Steering ドキュメント更新は6ステップで進みます：（1）ls、cat、jqコマンドでパッケージ構成・スクリプト・ディレクトリ構成を把握、（2）mcp__github__list_issues・mcp__github__search_issuesでオープンイシューとクローズ済みイシューを確認、（3）README.md、product.md、tech.md、plan.md、work.md、structure.mdの6ファイルを読み込んで実態と比較、（4）陳腐化箇所を表形式で報告、（5）修正内容をユーザーに提示して承認取得、（6）承認後にMultiEditで一括修正してコミット。確認ポイントはファイルごと（README の セットアップ動作性、tech.md のバージョン正確性、plan.md の完了状態、structure.md のディレクトリ存在確認、Issue との整合性）に整理され、product.md は設計意図として扱う一方、work.md は変更を慎重に行う注意事項が記載されています。

漠然としたアイデアや頭の中にあるモヤモヤを、対話を通じて言語化・構造化できます。実装前の検討段階で思考を整理するため、後戻りが減ります。 ユーザーの問いかけに対してこちらが一方的に答えるのではなく、相手側の考えを引き出す質問を投げかけるため、より深い思考が生まれます。 ブレインストーミング段階で、制約を取り除いて「理想的にはどうしたいか」を広く検討できるため、視野が広がります。 対話で整理された内容は最後に要約され、次に何をするべきかが明確になります。 ファイル作成やコード変更は行わない純粋な思考整理ツールなので、実装前の安全な検討が可能です。 新機能やプロジェクトの方向性について、実装前に頭を整理したい プロダクトマネージャーや企画者 技術的なアプローチの選択肢を広く検討してから決めたい 開発者やアーキテクト チーム内の意見が分かれており、論点整理が必要な 意思決定者 漠然とした違和感や改善案があるが、まだ言語化できていない 誰でも 「$ARGUMENTS」の内容から議論テーマを理解し、不明瞭な場合は「何が引っかかっていますか？」と掘り下げます。必要に応じて.ai-agent/steering/ドキュメントやコードベース、外部情報を参照し議論の土台を揃えます。対話は3つのアプローチを状況に応じて使い分けます。発散では「他にどんな方法がありそうですか？」と視野を広げ、関連技術や事例を紹介します。収束では「つまり、こういうことですか？」と要約確認し、論点整理とトレードオフ明示を行います。深掘りでは「具体的にはどういう状況ですか？」「なぜそう感じますか？」と前提・制約を明らかにします。区切りがついたら、議論で明らかになったこと、未決定事項、次のアクション（タスク作成、調査開始、Issue作成等）を要約します。ファイル作成・編集は行わず、ユーザーのペースに合わせた問いかけ中心で進めます。

レビューコメントの自動一覧化: GitHub APIでPRの未解決コメントをすべて取得し、ファイル・行番号・内容をわかりやすく整理できます。 修正の優先度を自動判定: バグ修正・セキュリティ改善は推奨、設計判断はスキップ、トレードオフはユーザーに確認するなど、判断基準に基づいて分類できます。 修正内容を一括実行: ユーザーの承認を得た修正だけを自動で適用し、複数ファイルの編集をまとめてコミット・プッシュできます。 レビュワーへ対応結果を自動返信: 修正した項目・スキップした項目それぞれに理由付きで返信し、やり取りを記録に残せます。 レビュー指摘の対応に時間をかけたくない開発者: どの指摘に対応すべきか自動判定され、手作業を減らせます。 複数のPRレビューを抱えているコードレビュアー: レビューコメントの一覧化と対応状況の自動追跡で、フォローアップ漏れを防げます。 チームのレビュー品質を高めたい人: 修正理由をコメント返信で説明することで、暗黙知が形式知に変わります。 リモート・非同期チームで働く人: 口頭での「確認しておいて」が減り、コメントに記録が残ります。 mcp__github__pull_request_readで未解決レビューコメント（is_resolved: false）をスレッド取得し、各コメントの内容を要約してユーザーに提示します。判断基準は「修正推奨（バグ・セキュリティ・UX改善・テストカバレッジ拡充）」「修正不要（ユーザー決定事項・プロジェクト方針違い・過剰な将来対応）」「要確認（トレードオフ・設計判断）」の3段階。ユーザー承認後、承認された項目を修正して一括コミット・プッシュし、mcp__github__add_reply_to_pull_request_commentで各レビューコメント（commentId指定）に修正内容または理由を返信。修正返信は「ご指摘ありがとうございます。○○を△△に変更しました」、スキップ返信は「ご提案ありがとうございます。△△の理由から現状維持します」の形式で返信し、最後に「修正X件・スキップY件でよいですか？」と確認します。

Pull Requestのレビューコメントをまとめて確認し、修正すべき項目とスキップできる項目を自動判定・提示できます。バグ修正やセキュリティ改善など推奨される指摘と、設計方針の違いなどスキップしてよい指摘を区別して、対応方針を提案します。 レビューコメント一つずつについて「修正推奨/不要/要確認」の判定理由を明示し、ユーザーが最終確認してから修正を実行するため、レビュー対応の漏れや誤った修正を防げます。 承認されたコメントだけを対象に自動修正を実行し、修正内容をコミット・プッシュまで一括処理するので、手作業の修正作業を省略できます。 修正完了時に「X件修正、Y件スキップ」とまとめて報告し、PR更新状況が一目でわかります。 開発チームのメンバー：Pull Requestのレビュー指摘に効率よく対応したい プロダクト開発者：バグ修正やセキュリティ指摘への対応漏れを防ぎたい コードレビュアー：チームメンバーが指摘に確実に対応したか確認したい スタートアップ・小規模チーム：レビュー対応を自動化して開発速度を上げたい mcp__github__pull_request_read の get_review_comments 実行により未解決コメントを取得。各コメントを要約してユーザーに提示し、修正の要否を判定（推奨/不要/要確認）し理由を説明。修正推奨：バグ修正、セキュリティ改善、アクセシビリティ改善、明らかなUX改善、カバレッジ不足（60%未満）の単体テスト拡充。修正不要：ユーザーが明示的に決定した設計、プロジェクト方針と異なる提案、過剰な抽象化・将来対応の提案。要確認：トレードオフがある変更、設計判断が必要な変更。修正推奨・要確認項目をまとめてユーザーに提示し承認を得る。承認された項目のみ各ファイルを編集（Edit/MultiEditツール使用）。修正内容をコミット・プッシュして PRブランチに反映。最後に「まとめ: X件修正、Y件スキップでよいですか？」と確認。

現在のブランチ内容を自動確認し、未コミット変更がないか、どんなコミットがあるかを把握できるため、PR作成前の確認漏れを防げます ブランチをリモートに自動プッシュできるため、PR作成の前準備を手動で行わなくて済みます PR テンプレートを自動読み込み、ボディ内容を構造化できるため、テンプレート形式に沿ったPRが素早く作成できます 作成後のPR本文を自動検証し、改行エスケープなどの形式エラーを検出できるため、見た目の悪いPRを防ぐことができます PR URLを自動で報告してくれるため、確認作業がシンプルになります GitHubでコードレビューを受ける開発者全般 PR作成時のテンプレート確認が手間と感じている人 GitHub CLIを活用したワークフローで効率化したい人 PR作成後の本文形式エラーを事前に防ぎたい人 PR作成スキルは6つのステップで構成されます。(1)git statusでコミット確認、git log・git diffで変更内容確認、(2)リモートにプッシュ、(3).github/PULL_REQUEST_TEMPLATE.mdを読み込み、(4)mcp__github__create_pull_requestでPR作成（タイトル・ボディは改行エスケープなしで記載）、(5)gh pr view --json bodyでPR本文を取得し改行エスケープ確認・問題時はmcp__github__update_pull_requestで修正、(6)PR URLを報告。ボディは「目的」「変更概要」セクションで構成、コミット済みの確認後に進め、masterへの直接プッシュを避け、PR タイトルは日本語50文字以内推奨。許可ツールはRead・Glob・Bash(git系)・GitHub CLI・update系MCPです。

ユーザーが提示したタスク内容から自動的にタスク名（英語・kebab-case）を決定し、YYYYMMDD-{タスク名} という標準化されたディレクトリを作成できます。 タスク用README.md（目的・ゴール・実装方針・完了条件・作業ログ）をテンプレートから自動生成し、関連ドキュメント（plan.md・tech.md・structure.md）の参照内容を提示できます。 実装方針をユーザーに提示して確認を取った後、GitブランチをTaskManager（TodoWrite）で自動細分化でき、実装ステップをプロジェクト管理できます。 完了時には作業ログを記載し、PR作成コマンド（/autodev:create-pr）へスムーズに引き継げます。 タスクの開始から完了まで、ドキュメント・ブランチ・進捗管理を統一したい開発チーム 複数のタスクを並行進行する際に、各タスクのコンテキスト（目的・方針・進捗）を見失わないようにしたい人 API実装→UI実装→テスト→PR作成という一連の流れを自動化し、手作業での手戻りを減らしたいプロジェクトマネージャー 8つの手順：①タスク名決定（$ARGUMENTS→英語kebab-case、例：image-detail-view）、②.ai-agent/tasks/YYYYMMDD-{タスク名}/README.md作成、③README.md記載項目（目的・ゴール・実装方針・完了条件・作業ログ空欄）、④関連ドキュメント確認（plan.md・tech.md・structure.md）、⑤ユーザー方針提示・確認取得、⑥ユーザー確認後にgit checkout -b {タスク名}でブランチ作成（main pull は後）、⑦TodoWrite でタスク細分化、⑧実装開始。実装中の注意：各ステップで動作確認・API後curl確認・UI後Playwright MCP確認・tmp使用可・ユーザー確認取得。完了時：完了条件チェック→作業ログ記載→ユーザー報告→/autodev:create-pr でPR作成。

大型目標をタスクに自動分解 — 「デスクトップアプリ化」「動画対応機能」など、大きな目標を実行可能なタスクに自動的に分割し、依存関係を整理します。 タスク優先度と依存関係を可視化 — どのタスクから始めるべきか、どのタスクに依存しているかが一目でわかるため、計画的に進められます。 プロジェクト進捗を一元管理 — README に目標・スコープ・タスク一覧・進捗をまとめるため、チーム内での状況把握が簡単になります。 タスク完了時の自動追跡 — 各タスクの状態を「未着手→進行中→完了」と更新することで、全体の進捗が常に最新に保たれます。 大型機能開発や長期プロジェクトに取り組む人 — 数週間〜数ヶ月かかる複雑なプロジェクトを体系的に進めたい方。 タスク分解や計画立案が苦手な人 — AIが目標を分析して、適切なタスク分割案を提案してくれます。 複数の改善案を並行して進める人 — 複数プロジェクトの進捗を同時に管理したい方。

Start new survey

会話からGitHub Issueを自動生成：見つけたバグや思いついた機能要望を、そのままIssue化できます。面倒な書式を気にせず、自然な会話のままプロジェクト管理に繋げられます。 バグ報告・機能要望・課題を標準テンプレートで整理：問題の種類に応じて、必要な情報が漏れないよう自動的に整理されます。チーム全体で同じ形式のIssueが溜まり、対応しやすくなります。 重複Issue検出で無駄な報告を削減：報告しようとしている内容が既に存在するかを自動確認し、同じ内容の重複Issueを防げます。 優先度とカテゴリを自動付与：高・中・低の優先度や、BugやEnhancementなどのラベルを自動設定し、タスク管理を効率化できます。 作成前にプレビュー確認：実際に作成するIssueの内容をユーザーに見せて確認し、修正したい場合は調整してから確定できます。 開発チーム・エンジニア：見つけたバグをサッと報告し、タスク管理に繋げたい方 プロダクト担当者・マネージャー：ユーザーからの機能要望を体系的に管理したい方 テスター・QAチーム：発見した問題を効率的にIssue化したい方 プロジェクト全体：会話ベースのアイデアを、形式的なタスク管理に自動変換したい組織

独立したレビュアーエージェントによる客観的評価：現在の会話コンテキストに影響されない、完全にクリーンな環境でコードレビューを実施できます。偏見なく品質を判定できます。 コード品質・セキュリティ・設計を一度に検査：単なる構文チェックではなく、セキュリティリスク・設計の問題・パフォーマンス改善案など、複数の観点から指摘を受けられます。 プロジェクトの技術方針に基づいたレビュー：プロジェクト独自の技術ドキュメント（tech.md等）を自動読み込みし、組織のルールに合わせた指摘をしてくれます。 大型PRも段階的かつ網羅的に検査：規模が大きいPRでもレビュアーが段階的に精査し、重要なポイントを見落としません。 APPROVE / REQUEST_CHANGES / COMMENTの推奨判定：レビュー結果を「マージOK」「修正要」「コメントのみ」で明確に分類し、次のアクションが一目瞭然です。 開発チーム・エンジニア：コードレビューの質を高め、属人的な判断を排除したい方 技術リード・アーキテクト：チーム全体の技術基準を守りながらレビューの負担を軽くしたい方 マージ権限を持つ者：マージ判断を客観的なレビュー結果で正当化したい方 開発文化を強化したい組織：学習と改善を目的とした、心理的安全性の高いコードレビュー環境を作りたい方

タスクの要件を自動整理：タスク内容が曖昧な場合は、適切なスキルへのルーティングを提案し、やるべき作業を明確にできます。 実装準備を一括で完成：タスクディレクトリ・README・Gitブランチを自動作成し、すぐに実装を開始できる環境が整います。 実装方針と完了条件を可視化：タスクの目的・実装方針・完了条件をREADMEに記載し、チーム全体で進捗と成功基準を共有できます。 作業内容を細分化・トレース：TodoWriteでタスクを細かく分割し、作業ログに進捗を記録することで、何をやったかが一目瞭然になります。 テストと動作確認を組み込める：Lintテストブラウザ確認などの検証ステップを、タスク実施時に自動提案できます。 開発者：数時間～半日で完了する具体的な実装タスクを迷わずこなしたい方 タスク管理者：タスクの粒度を統一し、進捗追跡（トレーサビリティ）を確保したい方 チームリーダー：メンバーのタスク完了率を上げ、手戻りを減らしたい方 品質管理：実装時のテスト・確認を自動化し、品質基準を維持したい方