コードベース全体のレビュー・監査。perf/sec/test/arch/cq/docs の6観点を並列委譲し、優先度付き issue ファイルと観点サマリをメモリディレクトリに生成する。コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review 実行時に使用。境界: PR 単位は pr-review、自ブランチの提出前確認は self-review。
gal-check
タスク進行中に、続行・即出荷・方向転換のどれが妥当かを、fresh なサブエージェント1体に状況サマリだけ渡して裁定させる。/gal-check 実行時、「ずれてない?」「このまま続けていい?」「ギャルに聞いて」等の方向確認の依頼時、外部レビューループの打ち切り条件に達した時に使用。成果物の中身は読まない。
境界: 成果物のレビューは pr-review、計画の穴の対話検証は grilling。
含まれるファイル(1)
- SKILL.md5.6 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Gal Check
レビューループ・長時間タスクの膨張は、lead自身のサンクコスト・一貫性圧力のため自己検出できない。本スキルは、汚染されていないfreshエージェント1体に「状況の事実」だけを渡し、プロセス自体の妥当性を裁定させる。
既存設定との関係
- AGENTS.md「自分の作業の検証・ダブルチェックのために委譲しない」の対象外: 本スキルは成果物の検証ではなくプロセスの判定であり、leadが構造的に自己修正できないバイアスへの対処。1体1回・成果物を読まないためコストも最小
- 裁定は助言: 打ち切り・スコープ変更の最終判断はユーザー(AGENTS.md「確認必須カテゴリ」に従う)
- 外部レビューループとの関係: レビューの代替ではない。レビューが「成果物の欠陥」を見るのに対し、本スキルは「そのレビューを続けるべきか」を見る
設計原理(様式制約を緩めない理由)
ペルソナと様式は飾りではなく機能要件。緩めると判定が機能しなくなる:
- 忖度の解除: 断定・ヘッジ禁止は「敬語と保険を外して結論だけ言え」の許可。緩めると両論併記に回帰する
- 日常比喩への翻訳強制 = 理解の検算: 専門用語で言えてしまうと、本質を掴めていなくても出力できる(ファインマンテスト)
- 1点主義: 網羅性への回帰(=レビュー膨張と同根の癖)を様式で防ぐ
- キャラ経由の距離: 素のアシスタント口調では角が立つ断定を、言いやすく・聞きやすくする
ワークフロー
1. 状況サマリの作成(lead)
以下の事実のみを、判定に要る分だけ圧縮する。成果物本体・diff・文書・指摘リストの転記は含めない:
- 元の目的(1行)
- 経過: ラウンド数 / 経過日数 / 残作業の中身と重大度
- 周辺コスト: PR滞留日数・base追従の回数・この作業がブロックしているもの
- 適用中の自分ルール(AGENTS.md・PJ CLAUDE.md)で状況に関係しそうな規定(あれば1〜2行)
完了基準: サマリに成果物の引用が1つも含まれていない(含めた時点で彼女は「もう1人のレビュアー」になる)。
2. spawn(1体・1回)
経路はAgent tool(委譲先は裁定を返すだけでファイルを書かないため、委譲の既定であるherdr paneに当たらない。@context/herdr-delegation.md「経路の選択」)。Agentツール(general-purpose)でfreshにspawnする(既存agentの継続・会話中の自分での代演は不可。freshであることが判定の前提条件):
あなたは本質を突くのが得意な鋭いギャル。友達(作業中のAIエージェント)の状況を聞いて、率直に言ってあげて。追加の調査・ファイル読みは不要、以下の状況だけで判定して。
## 状況
<状況サマリ>
## 様式(絶対)
- 断定で言い切る。忖度・ヘッジ・両論併記は禁止
- 専門用語・抽象語は禁止。日常の比喩に翻訳して言う
- 指摘は「いちばん刺さる1点」だけ。箇条書きで並べない
- 状況に「本人が自分で決めたルール」との矛盾があれば、それを最優先で突く
## 出力形式(そのまま返す。前置き・締めの挨拶は不要)
1行目: 裁定 —「続行でいい」「今すぐ出せ」「本当の問題はそこじゃない」のいずれか+一言
2行目以降: パンチラインと、その理由1つ
完了基準: spawnは1体のみ、渡したのは状況サマリだけ。
3. 裁定の扱い(lead)
- 裁定を口調を変えずそのままユーザーへの報告に含める(要約・翻訳すると様式が機能しなくなる)
- 裁定が「今すぐ出せ」「本当の問題はそこじゃない」なら、AskUserQuestionの判断材料として添えて確認する(leadが自分で打ち切り・スコープ変更を確定しない)
- 複雑タスク中なら05_log.mdに裁定と採否を記録する
完了基準: 彼女の裁定への再レビュー・再spawn・反論の往復をしていない(1体1回で終わり)。
Gotchas
- 状況サマリの肥大: 長くなるほど網羅レビューに回帰する。10行を超えたら事実を削る(判断材料を足さない)
- 裁定の再帰: 「彼女の指摘に対応するためのラウンド」を追加するのは本スキルの存在意義に反する。裁定は採るか・ユーザーに諮るかの二択
- 成果物を読ませたくなる誘惑: 「正確な判定のために文書も渡そう」は誤り。彼女の判定対象は文書の質ではなく状況の構図であり、文書を渡すと指摘リストが返ってくる
既存設定への参照
- @context/agent-cli-guide.md(発火元: レビューループの打ち切り条件)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
変更をコミットする。/commit 実行時、「コミットして」「pushして」等の依頼時に使用。--push 引数または「pushして」の依頼で push も行う。
PR を Draft で作成する。PR テンプレートを全セクション埋め、対象 repo の既存 PR の分量に合わせて書きすぎを削る。PR 作成の依頼時、実装が一段落して PR 化する時、/create-draft-pr 実行時に使用(gh pr create を直接実行しない)。引数でベースブランチを指定できる。境界: 個別レビューコメントへの対応は pr-comment。
スキルを新規作成する。「スキルを作って」「この手順をスキル化して」等の依頼時、/create-skill 実行時に使用。AGENTS.md・context・既存スキルと整合させ、重複・競合を避ける。境界: 既存スキル・指示ファイルの修正は update-inst、指示ファイル全体の監査は instructions-audit。
抽象的な要件・事業側の要求を深掘りし、既存実装との整合を確認して実装マスタとシステム要件書を作成する。「こういう機能を作りたい」「この要求を満たす機能を設計して」等の抽象要件の提示時、既存機能の拡張や Phase 分割の要件定義開始時、/design-feature 実行時に使用。境界: 要件確定後の実装計画書・PR 分割と実装進行は plan-feature-prs。
画面の設計判断(ナビゲーション・重ね方・通知と空状態と読み込み・外枠とトークンと状態表現)の型を決定表で選び、アプリ内の全画面で揃える。画面・ページ・レイアウト・ナビゲーション・ダイアログ・コンポーネントを新しく作る・作り直す時、モックやダッシュボードを作る時、サイドバー・タブ・モーダル・シート・toast・バナー・空状態のどれを使うか決める時に使用。PJ に components.json があれば shadcn の部品とトークンへの対応も扱う。主要なデザインシステム(Material・HIG・Carbon・Primer・Atlassian・Fluent・GOV.UK・NN/g・WAI-ARIA APG・WCAG)の一致点を規則にし、食い違いの採否を定めてある。境界: 画面の文言は writing-ui-text、画面に何を出すかと提示前の完了基準は context/ui-artifact-standards.md、コードの実装原則は writing-code、shadcn 部品の API と組み立ては shadcn。