ask-gabriel

Ask Gabriel

このパックの案内図です。次に使うスキルを提案するか、全体の道筋を示すジャーニーを案内します。薄く保ち、道筋を選んでから、別のスキルの本文を読み込みます。

読むタイミング

• 最初は何も読み込みません。code-quality.md と code-structure.md のルールは、このルーターには含めずにおきます。これらはすでに適用されており、次のスキルで読み込まれます。
• これから返信するところですか？Plain language と writing-style.md の Unslop セクションを開いてください。読み飛ばすと、提案がパック特有の用語だらけになります。
• 道筋の全体像がわからない場合は、以下の該当するジャーニーを開いてください。読み飛ばすと、最初の一歩は正しくても、3つ目の一歩を間違えます。

ジャーニー

各ジャーニーでは、ひとつの作業をスキルとルールに沿って段階的に進めます。その都度ルールを開き、次の行動を示します。すべて同じ例のドメイン（請求）を扱い、互いにつながっています。アプリの既存コードはたいてい乱雑なので、既存のコードよりも、ジャーニーに示された道筋と構成を優先してください。アプリ内の類似例をコピーするのは、例と一致する場合に限ります（類似例を参照）。

作業	ジャーニー
強固な基盤の上に新しい Feature を構築し、チケットからリリースまで進める	new-feature.md
既存の継ぎ目、つまり新しいバリエーション（「PayPal を追加」など）を差し込める名前付きの拡張ポイントに適合する追加対応	follow-up-fits-the-seam.md
まず継ぎ目が必要な追加対応（リファクタリング後に Feature を追加）	follow-up-needs-a-seam.md
調査から修正までのバグ報告への対応	bug.md
あとで使うために残しておく簡単なメモ	quick-note.md

ひとつのルールがコード上でどう表れるか（Before/After やパターンのフォルダーツリー）については、code-quality-examples.md と code-structure-examples.md を参照してください。

導入経路

状況	まず使うもの
動作変更を求めずに、ブランチへ main をマージする、ブランチを更新する、またはその他の方法で Git を同期する	Git の同期のみ：Git の安全性、競合、取り込みを扱い、同期が正常に完了したら停止します
Gabriel のワーカーによる自己レビューとメインエージェントのチェックループを伴う、具体的なチケット	/gabriel-mode
どのスキルを使うべきか分からない	ここにとどまり、以下を確認します
仕組み、手順の説明、担当範囲、またはレイヤー構成	/how
このように作られた理由、または設計上の根拠	/why
曖昧なアイデア／構築前の調査	/analyze
修正を求められる前に調査するバグ	/analyze → 構築できる段階になったら /task-with-tests
バグの修正	/task-with-tests
既存のコードやリポジトリ全体を、差分なしで監査または評価する	/analyze
X が真になるまで構築する	/task-with-tests（デフォルトの構築方法です。ユーザーはすべてのテストを拒否できます）
テストを一切行わずに構築する	/task
コーディングスタイル／この差分はきれいか？	/review（code-quality.md を適用します。code-quality-examples.md に例があります）。指針の一覧はスキルではなく、principles.md です
構造／フォルダー／サービス／データ形状	/analyze の後に /task-with-tests（どちらも code-structure.md を適用します。形状の例は code-structure-examples.md にあります）
実装にすぐ着手できる最終版の Linear/GitHub チケットが必要	/write-ticket
ブランチまたはプルリクエストをリリースする	shipping.md
Linear チケット → 構築	チケットを添えて /task-with-tests。同じルールに従ってリリースします
判断、方針、または構造について意見を詰める	/grill-me
ローカルブランチと main の比較レビュー、またはオープン中の GitHub PR のレビュー	/review
チェック／レビューに変化があるまで PR を監視する	/babysit-pr。監視は親エージェントが担当し、最新の HEAD を報告します
有限の予算内でレビューと許可された修正を繰り返す	/review-loop
現在の意図に照らして古い PR を評価または再開する	/takeover-pr
ブラウザーやその他のツールを選ぶ	ハーネス優先の探索
画面／フロントエンドを構築する、またはアプリの UX の信頼できる情報源を更新する	/task-with-tests（user-experience.md と docs/design.md を適用します）
UI の導線または遅い処理経路に対する、範囲を限定したレビューと改善のループを明示的に実行する	/hillclimb。ユーザーが指定した場合のみ使用します。目標に応じて UI 用またはパフォーマンス用のバリアントを選びます。通常の UI 作業や高速化作業には、従来の手順を使います
テストで複雑な動作を固定する	/task-with-tests はグリルの後にテストを提案します。すべて拒否できます。テストを直接依頼するか、/review が固定を推奨したときに同意してください。いずれの場合も、エージェントは testing.md に従います
変更した動作を検証する、または既存のテストをすべて明示的に実行し、実行中のアプリ、マイグレーション、エンドポイント、ジョブを QA する	動作とリスクに応じて範囲を定めた /verification。全検証を明示的に依頼した場合は、設定済みのすべてのスイートを実行します
既存のテストを監査、削減、または整理する	/test-audit（根拠を報告し、削除前に承認を待ちます。キャンペーンモードではサブシステム全体を対象にします）
skills.sh からこのパックをインストールする	/setup-gabriel-skills（スキルと AGENTS.md の配置先を確認します。インストールに失敗した場合のみ手動でコピーします）

構築には、まず /analyze、次に /task-with-tests を使ってください。/how と /why は、仕組みまたは根拠を説明した時点で終了します。この一覧にあるスキル名のみを推奨してください。ネスト型にするか単発にするかは、そのスキルの SKILL.md 内で分岐します。

Git の同期だけでは、構築、レビュー、検証のパイプラインは開始されません。動作に影響する競合解決には、影響を受ける動作のチェックが必要です。それらのチェックを選択しても、タスクの範囲を広げる許可にはなりません。リポジトリで必須のチェックと、ユーザーから明示的に依頼された検証は引き続き適用されます。 /task は作業を分割し、各部分を自ら実装します。テストは、ユーザーが依頼した場合、またはユーザーが /task の動作固定ブリーフや /review の推奨事項を承認した場合にのみ作成します（testing.md）。通常の編集にはテストを追加しません。

プロセス

ユーザーが実行するスキルを尋ねた場合

1. 依頼が不明確な場合は、意図を一文で尋ねます。
2. 次に実行するスキルを1つと、その後の手順を1つか2つ提案します。該当するジャーニーがある場合は、そのリンクを示します。
3. ユーザーが指示した場合（または「選んで進めて」と言った場合）に限り、そのスキルを実行します。
4. 普通の言葉で話し、略語は省略せずに説明します。チャットボットらしい締めくくりや大げさな表現は避けます。
5. /task、/task-with-tests、/analyze、/how、または /why を提案する場合は、code-quality.md と code-structure.md を適用することを伝えます。

エージェントが作業中に判断に迷った場合

1. 作業に該当するジャーニーを探し、開きます。
2. 現在の手順を確認し、それに従います。実行するスキル、開くルール、次のアクションを確認します。
3. 該当するジャーニーがない場合は、On-ramps の表を参照し、次に AGENTS.md の Skills の表を参照します。それでも判断に迷う場合は、推奨する回答とともに、ユーザーに質問を1つします。

アンチパターン

• 使用していない課金ベンダー名をアプリにコピーする