コードベース全体のレビュー・監査。perf/sec/test/arch/cq/docs の6観点を並列委譲し、優先度付き issue ファイルと観点サマリをメモリディレクトリに生成する。コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review 実行時に使用。境界: PR 単位は pr-review、自ブランチの提出前確認は self-review。
herdr-launch-cc
Herdr の指定 workspace に新しい tab(指定時は pane 分割)を作って Claude Code を起動し、remote control のセッション URL を報告する。
/herdr-launch-cc 実行時、「◯◯の workspace で cc を立ち上げて」等の Herdr 上での Claude Code 新規起動依頼時に使用。HERDR_ENV=1 必須。境界: 既存 pane・agent の確認や入力送信は herdr。
含まれるファイル(1)
- SKILL.md6.3 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Herdr Launch CC
Herdrの指定workspaceに新しいtab(明示指定時はpane分割)を作成し、fish -c "cc" でClaude Codeを起動し、remote control(デフォルト有効)のセッションURLを取得して報告する。
既存設定との関係
- herdrスキル: herdr CLIの構文・ID規約・状態モデル(idle/done等)の真実源。本スキルは起動フローの固定手順のみを規定する。コマンドの引数に迷ったら該当コマンドグループ(
herdr pane等、bareのherdrは実行しない)の出力に従う - worktree運用: Herdr操作は読み書きともCLI経由でありコード編集を伴わないため、worktree不要の例外に該当する
前提チェック
test "${HERDR_ENV:-}" = 1
失敗したらHerdr外で動いている旨を伝えて停止する。
完了基準: HERDR_ENV=1 を確認済み。
Step 1: 配置先の確認
herdr workspace listで一覧を取得する- workspaceが未指定ならAskUserQuestionで確認する(一覧のlabelとworkspace_idを選択肢にする)
配置方法のデフォルトは新規tabの作成。ユーザーが「paneを分割して」「隣に」等と明示した場合のみpane分割にする(配置方法は質問しない)。
完了基準: workspace_idが確定している。
Step 2: tab / paneの作成
新規tab(デフォルト):
herdr tab create --workspace <ws_id> --no-focus
JSON応答の result.root_pane.pane_id と result.tab.tab_id を読み取り、herdr tab rename <tab_id> "cc" と herdr pane rename <pane_id> "cc" でラベルを付ける。
pane分割(明示指定時のみ):
herdr pane list --workspace <ws_id>とherdr pane layout --pane <対象pane>でactive tabのpane矩形を確認する- 最も大きいpaneを分割対象とし、幅広(width > height×2目安)なら
--direction right、縦長・狭幅なら--direction downを選ぶ herdr pane split <pane_id> --direction <right|down> --no-focusを実行し、応答のresult.pane.pane_idを読み取ってherdr pane rename <pane_id> "cc"する
IDの推測・組み立ては禁止。必ずJSON応答から読む。
完了基準: 新pane_idをJSON応答から取得済み。
Step 3: Claude Code起動
herdr pane run <pane_id> 'fish -c "cc"'
herdr agent wait <pane_id> --until idle --timeout 60000
waitがタイムアウト(exit 1)したら、herdr pane get <pane_id> と herdr pane read <pane_id> --source visible --lines 40 で実際の画面を確認してから判断する(blocked は入力待ち、unknown は未検出)。
完了基準: pane get で agent: claude、agent_status: idle を確認済み。
Step 4: remote controlの確認とURL取得
remote controlはデフォルト有効(有効時はステータスバー右端に /rc インジケータが表示される)。
herdr pane read <pane_id> --source visible --lines 40でステータスバー右端の/rcインジケータを確認する。表示があれば有効化済み/rcを送信し、URL行の出現を待つ(有効化済みならステータスモーダルが開き、未有効なら有効化されて「is active」行が出る。どちらも下記matchに一致する):
herdr pane run <pane_id> "/rc"
herdr pane wait-output <pane_id> --match "claude.ai/code/session_" --timeout 15000
- waitの応答の
matched_lineからセッションURL(https://claude.ai/code/session_...)を控える - visibleを読み、「Remote Control」モーダル(Disconnect / Show QR code / Continueの選択肢)が表示されていたら、
❯がContinueにあることを確認してherdr pane send-keys <pane_id> enterで閉じ、再度visibleでプロンプト(❯)復帰を確認する - waitがタイムアウトした場合はvisibleを読んで実画面で判断する。「Remote Controlが設定で無効」等を示す場合は、勝手に
/configを操作せずユーザーに報告して指示を仰ぐ
完了基準: セッションURLを取得しプロンプト復帰を確認済み、または無効化状態をユーザーに報告済み。
Step 5: 報告
workspace(label + ID)・新pane_id・remote controlのセッションURLを報告する。
Gotchas
/rcはClaude Code側で/remote-controlに展開されて実行されるherdr pane runはテキストとEnterを一括送信する。起動直後のTUIに送るとテキストが失われるため、必ずidleを待ってから送る- bare
herdrはTUIをattach/起動するため実行しない(discoveryはコマンドグループ出力で行う) - 応答画面に「N MCP servers need authentication」警告が出ることがある。起動自体は成功なので、報告に含めるだけでよい
- remote controlの有効/無効はステータスバー右端の
/rcインジケータで判定する。デフォルト有効なので、通常/rc送信は「有効化」ではなくURL表示のステータスモーダルを開く操作になる /rcの応答は2形式ある: 未有効→有効化して「is active」の1行表示、有効化済み→URL・QRコード・Continue選択肢のモーダル。待つ文字列は必ずclaude.ai/code/session_(両形式にマッチ)にする- モーダルをContinueで閉じた後に「remote-control is active」の行は表示されない。確認はURL取得+プロンプト復帰で行う(is active行を待つとタイムアウトする)
- トップレベルの
herdr wait ...は存在しない(unknown command: waitになる)。agentの状態待ちはherdr agent wait <target> --until <status> [--timeout <ms>]、pane出力の待ちはherdr pane wait-output <pane_id> --match <pattern> [--timeout <ms>]を使う
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
変更をコミットする。/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。