Skill.md検索

Git worktreeを使って現在のブランチを切り替えることなく、複数の機能を同時に別ワークスペースで開発できます .worktrees または ~/.config/superpowers/worktrees/ など複数のディレクトリ候補から最適な場所を自動判定し、ユーザーの確認で決定します worktree ディレクトリが .gitignore に設定されているか検証し、不足していれば自動的に修正してからワークスペースを作成します プロジェクトの技術スタック（Node.js、Rust、Python、Go等）を自動判定し、必要な依存パッケージをインストールしてセットアップを完了します 複数の機能を同時に開発する必要があるエンジニア 現在の作業を中断せず並行開発したいチーム worktree の安全性設定を正確に行いたいコードレビュアー worktree 作成前に .worktrees → worktrees → CLAUDE.md の設定 → ユーザー確認 の順で場所を決定します。プロジェクトローカルディレクトリを選ぶ場合は git check-ignore で無視設定を確認し、未設定なら .gitignore に行を追加してコミットします（「壊れているものは即座に直す」原則に従う）。ディレクトリ決定後、git rev-parse --show-toplevel でプロジェクト名を検出し、git worktree add で新規ブランチを作成してワークスペースを初期化します。npm install、cargo build、pip install、go mod download など技術スタックに応じたセットアップを実行し、npm test、cargo test、pytest、go test などでテストを実行してクリーンなベースラインを確認します。テスト失敗時は報告して調査方針を確認し、テスト通過時は準備完了を宣言します。

GitHub の Issue・PR・コメントを gh CLI コマンドで一元管理し、セレモニーを最小化できます。 PR は Draft で作成してセルフレビュー後に Ready 状態に変更するワークフローで、品質を確保しながら効率的に進めることができます。 親 Issue とサブ Issue（タスク）を階層的に整理し、優先度順に進捗管理ができます。 ブロッカーや仕様変更を Issue/PR にコメントで記録し、チーム全体の進捗状況を可視化できます。 API 呼び出し失敗時にもユーザーに明確な対応策を報告するため、作業の停滞を防げます。 GitHub を使ったチーム開発をしており、Issue・PR 管理を効率化したい開発者 CLI ツールで GitHub 操作を統一し、手作業を減らしたい人 PR のレビュー前に自分で検証する工程を組み込み、品質を上げたい人 チーム内でコミュニケーションを記録しながら、開発の進捗を見える化したい人 gh CLI を使用して GitHub の Issue・PR・進捗コミュニケーションを最小限のセレモニーで管理します。GitHub 操作はすべて gh で行い、ローカル Git 操作には git を使用します。優先順位は①プロジェクト固有ルール ②このスキルの規約 ③一般的な GitHub ベストプラクティスです。PR はデフォルト Draft として作成し、セルフレビューと検証後に gh pr ready で Ready にします。作業前は必ず gh pr view でベースブランチを確認し、ハードコードを避けます。Issue とサブ Issue を階層的に管理し、addSubIssue GraphQL ミューテーションで追加・リンク解除します。ブロッカー・仕様変更・レビュー依頼時にコメントを投稿し、短い内部タスクのノイズは避けます。API 失敗時は無言で続行せず、詳細と次のステップを Issue/PR にコメントしてユーザーに報告します。詳細なコマンド・Issue 管理・コメントテンプレートは references/ ディレクトリの各ファイルで管理します。

ユーザーのアイデア・要件・制約をヒアリングしながら、実装可能な設計書に仕上げることができます。 プロジェクトの現状（既存ファイル、ドキュメント、コミット）を自動分析し、文脈を把握したうえで質問できます。 2〜3個のアプローチ案を提案し、トレードオフと推奨理由を明確にできます。 ユーザーの承認を得た設計を Markdown ドキュメント（doc/specs/YYYY-MM-DD--design.md）として自動生成できます。 仕様レビューループ（自動レビュー機能）で設計品質を検証し、承認までを自動化できます。 プロジェクト開始時に、要件定義と基本設計を効率よく進めたい人 TODO リスト、単一関数のユーティリティなど「小さめ」なタスクでも、手戻りなく実装を進めたい人 実装前に設計書を作成し、チーム内で仕様を共有したい人 ビジュアル・UI検討が必要なタスクで、デザイン提案を含めたい人 すべてのタスク開始時に実施する計画スキル。ユーザーが「brainstorming 不要」と明示した場合のみ例外。自然対話でアイデアを完成した設計に仕上げる。チェックリスト: (1)プロジェクト文脈把握（ファイル・ドキュメント・コミット確認）、(2)ビジュアルコンパニオン提案（ビジュアル関連質問予想時、単独メッセージで送信、他内容と混ぜない）、(3)確認質問（一度ひとつずつ、目的・制約・成功基準を理解）、(4)2〜3アプローチ提案（トレードオフ・推奨を示す）、(5)設計提示（複雑さ応じたセクション構成、各セクション後にユーザー承認を得る）、(6)設計ドキュメント作成（doc/specs/YYYY-MM-DD--design.mdに保存・コミット）、(7)仕様レビューループ（spec-document-reviewer サブエージェント的確な文脈でディスパッチ、セッション履歴なし、問題あれば修正再ディスパッチ、最大3回、超過時はユーザー報告）、(8)ユーザー仕様確認依頼、(9)wf-03-writing-plans スキル呼び出し。設計提示までは実装スキル呼び出し・コード記述・スキャフォールディング等の実装アクション禁止。

異なるテストファイルの修正、複数のバグ調査など、関連のない複数のタスクをエージェントに分散させて同時に進めることができます。各エージェントは独立した文脈で作業するので、互いに干渉しません。 タスクごとに「スコープ」「ゴール」「制約」を明確に指定することで、エージェントが迷わず集中して問題を解決できるようになります。 セッションの全コンテキストを引き継がせずに、必要な情報だけを正確に構成するので、メインエージェントのコンテキストを温存でき、別の調整作業に充てられます。 異なるサブシステムやドメインの複数の障害が同時に発生している場合、それぞれを並列に調査できるため、全体の作業時間を大幅に短縮できます。 複数のテストが同時に失敗していて、それぞれを順番に調査するのは時間がかかると感じる開発者 異なるサブシステムが独立して壊れている状況を早期に把握・修正したい人 プロジェクトのコンテキストを温存しながら、複数の並列タスクを効率良く実行したい 関連のない複数のバグ・不具合を同時に対応する必要があるエンジニア このスキルは独立したドメインの特定、集中的なエージェントタスクの作成、並列ディスパッチ、レビュー・統合の4段階で構成されます。使用タイミングは、複数の障害が存在し、各々が独立していて、調査間で共有状態がない場合です。エージェントプロンプトは集中的（ひとつの明確な問題ドメイン）、自己完結的（問題理解に必要なコンテキストを含む）、出力が明確（何を返すべきか明示）の3点が要件です。障害が関連している場合や全体状態の理解が必要な場合、エージェント間の干渉がある場合は使用しません。