コンテンツにスキップ

プラグイン一覧

このリポジトリは プラグイン・マーケットプレイス（claude-code-setup）として、いくつかのプラグインを配布しています。Claude Code から以下のコマンドでマーケットプレイスを追加し、必要なプラグインをインストールできます。

# マーケットプレイスを追加（最初に一度だけ）
/plugin marketplace add hdknr/claude-code-setup

# インストール済み・追加済みの一覧を確認・管理
/plugin

配布中のプラグインは以下のとおりです。

プラグイン 呼び出し 種別 概要
workspace-setup /workspace-setup:workspace-setup コマンド ワークスペースの初期セットアップ
cmux /cmux:cmux スキル cmux ウィンドウで GitHub Issue/PR を操作
orca /orca:orca スキル Orca の内蔵ブラウザで GitHub Issue/PR を操作
dev-loop /dev-loop:dev-loop
/dev-loop:cruise		 スキル 1 Issue = 1 周のループ志向開発と、依存のある複数 Issue を親 Issue の一覧から回す入口（オートクルーズ）
spec-loop /spec-loop:req-loop
/spec-loop:spec-review
/spec-loop:feasibility
/spec-loop:proposal
/spec-loop:scaffold		 スキル dev-loop の手前にある要求側のループ（要求確定・仕様レビュー・実現性とコスト・提案書）と、dev-loop への引き渡し

呼び出しは プラグイン名:名前

プラグインが提供するスキルとコマンドは、名前の衝突を防ぐため 常にプラグイン名で名前空間化されます。 たとえば cmux プラグインのスキルは /cmux ではなく /cmux:cmux で呼び出します （commands/ に置いても同じ名前空間に載るため、bare な /cmux をプラグインで提供する方法は ありません）。名前空間の付かない短い名前で呼びたい場合は bare な名前で呼びたい場合 を参照してください。

プラグインの入れ方・使い方の全体像

インストール手順と日常利用の流れは Part 3: インストール後の環境準備 にもまとまっています。このページには、各プラグインが何をするか・どう入れるかを載せています。

インストールのスコープ

/plugin install を実行するとスコープの選択画面が出ます。

スコープ 意味
User 自分の全プロジェクトで使う
Project このリポジトリの全メンバーで使う（.claude/settings.json に入る）
Local このリポジトリで自分だけが使う（共有しない）

全プロジェクトで使いたい場合は User を選びます。 シェルから非対話で入れる場合は --scope を渡します。

claude plugin marketplace add hdknr/claude-code-setup
claude plugin install cmux@claude-code-setup --scope user

claude plugin install はセッションの外で走るため、反映は次回起動時か、開いている セッションで /reload-plugins を実行したときになります。

更新のしかた

version を上げただけでは届きません。 利用者のマーケットプレイスのクローンは 導入時のコミットで凍結したままになります——実測では、カタログを読み直すまで list --available が返す版も説明文も古いままでした。 実際に、dev-loop は 1.0.0 のまま 6 週間以上使われていました （インストールは 2026-07-29、クローンは 0b22552／2026-07-21 で凍結。2026-09-11 に再実測しても まだ 1.0.0 でした）。その間にリポジトリ側は 1.9.1 まで上がっています。

入っている版を確かめる

claude plugin list --json | python3 -m json.tool | grep -A3 claude-code-setup

version が入っている版です。この確認は、どんなに古い版が入っていても効きます—— 後述のバナーと違い、バナーを持たない版にも後付けで使えます。

一覧には他プロジェクトの項目も混ざります

claude plugin list にスコープ指定はありません（-s を付けると error: unknown option '-s'）。実測では、このリポジトリから実行して project スコープの項目が 8 件（6 プロジェクト分）並びました。 自分のものかは projectPath で見分けます。

他プロジェクトの項目は enabled: false と表示されますが、これは「利用者が無効にした」 という意味とは限りません——そのプロジェクトで有効にしていても、別の場所から実行すれば false になります。enabled だけで判断しないでください。 自分の user スコープの項目については、enabled: false は claude plugin disable で無効にした状態を指します（claude plugin enable で戻します）。

更新する

claude plugin marketplace update claude-code-setup      # カタログを取り直す
claude plugin update dev-loop@claude-code-setup         # 新しい版に上げる（既定は user スコープ）

2 つ目が返す答えは 2 通りです（それぞれ別の実行で得た出力です）。

✔ Plugin "dev-loop" updated from 1.0.0 to 1.9.1 for scope user. Restart to apply changes.
✔ dev-loop is already at the latest version (1.9.1).

反映は次回起動時か、セッション内で /reload-plugins を実行したときです。

「確かめるだけ」はできません

2 つ目は判定と更新を兼ねています。最新でなければその場で更新され、反映のための 再起動（または /reload-plugins）を求められます。 「最新か」に読み取りだけで答える方法は見つかっていません（list は入っている版しか 返さず、--available は後述のとおりこのプラグインを返しません）。 探し尽くしたわけではありません。

ただし「入っている版が、手元のカタログに追いついているか」なら、ファイルを読むだけで 分かります——2 つのファイルを突き合わせます。

# カタログが宣言する版
python3 -c "import json;print([(p['name'],p['version']) for p in json.load(open('$HOME/.claude/plugins/marketplaces/claude-code-setup/.claude-plugin/marketplace.json'))['plugins']])"
# 入っている版
python3 -c "import json;d=json.load(open('$HOME/.claude/plugins/installed_plugins.json'));print({k:[i['version'] for i in v] for k,v in d['plugins'].items() if 'claude-code-setup' in k})"

手元のカタログ自体が古い可能性は残ります（それを知るには取り直すしかありません）。

claude plugin list は「読み取りだけ」ではありません

claude plugin 系のコマンドは、自動更新の掃引を発火させることがあります。 実測で、list と --help を動かしただけで自動更新が有効な 5 件のマーケットプレイスが 一斉に更新されました（後述）。

つまり autoUpdate を有効にしている場合、claude plugin list を「確認のため」に 打つと、それ自体が更新を起こしうるということです。 本当に何も動かしたくないときは、上のファイルを直接読んでください。

ただし 2026-09-14 には観測できませんでした。 claude plugin list を --debug-file つきで動かしても、ログ 38 行に更新に関する行は 1 行も出ず、 lastUpdated も動きませんでした（-p でのセッション起動でも動かず）。

これは「発火しない」の証拠ではありません。 そのログが覆うのは プロセスが生きていた 0.13 秒だけで、遅れて走る分は見ていません （実体には最大 10 分ほどの待ちを入れる形が読めます）。条件も揃っていません——

80 の観測は list と --help の両方を、フラグを立てた直後に、

2 日止まっていたマーケットプレイスに対して動かしたときのものです。 どの条件で発火するのかは特定できていません。 一度は発火した以上、注意はそのまま残します。

カタログの取り直しは、必須ではありません（実測）

claude plugin update は、更新の前に自分でカタログを取り直します。 2026-09-13 に、marketplace update を走らせずに plugin update だけを実行して 確かめました。

実行前 実行後
クローンの HEAD 92a9936（09-11） 650af0c（09-13）
カタログが宣言する版 1.9.1 1.9.2
入っている版 1.9.1 1.9.2

更新が要るかどうかに関わらず取り直します——すでに最新の状態でもう一度走らせても、 最終更新の時刻が進みました。

それでも 2 段階で書いているのは、marketplace update が害にならないからです。 「取り直してから更新する」と覚えておけば、どちらの経路でも正しく動きます。

以前ここには「取り直しが必須かは未検証」と書き、逆向きの手がかりとして Failed to refresh marketplace '...' before update; using cached data: という文字列を 併記していました。その手がかりは当たっていました。

以下は CLI の実体を読んだもので、動かして確かめたものではありません。 直前に取り直したときは省く分岐があり、閾値は 30 秒と読めます。 取り直しに失敗した場合も黙らず Warning: marketplace not refreshed (...) — version shown may be stale. を付けて返す形で、 取り直せなかったことが利用者に見える——この経路は安全側に見えます。

--available は dev-loop を返しません（理由は不明）

claude plugin list --json --available の available に、dev-loop は一度も 現れませんでした（更新の前も後も）。理由は分かっていません—— 「インストール済みだから」ではありません。実測では入っている 12 件のうち 7 件は available にも出ています。

したがって少なくとも dev-loop については、入っている版と並べて比較する用途には 使えません。

使えるのはカタログ自体の古さを見ることです。取り直す前は cmux も workspace-setup も 1.0.0、取り直した直後は 1.1.3 と 1.0.1 を返しました。 説明文も古いものが返ります。なお --available を付けると出力が 配列から {"installed": [...], "available": [...]} のオブジェクトに変わるので、 上の grep のレシピはそのままでは使えません。

スコープを取り違えると、別のものが更新されます

install / update の既定は user です。Project / Local で入れたなら -s project / -s local を付けます。そのスコープに入っていなければ Plugin "<name>" is not installed at scope <scope> と返るので、ここは気づけます。

気づきにくいのは別の形です。 CLI の実体には、同じスコープに project インストールが 複数あり、どれも現在のディレクトリに一致しないとき、先頭のものを選んで更新する分岐が あります（... project-scope installs, none match CWD '...'; updating '...' only）。 一致しないものが 1 件だけのときも先頭が選ばれ、そのときはこの文字列すら出ません。 しかもこの文字列がログ用なのか端末に出るのかは確かめていませんので、 警告が見えることを当てにしないでください。複数のプロジェクトで同じプラグインを project スコープで入れているなら、更新はそのプロジェクトのディレクトリから実行します。

段階ごとに何が変わるか

段階 クローン カタログが宣言する版 入っている版
更新前 0b22552（2026-07-21） 1.0.0 1.0.0
カタログを取り直した直後 92a9936（2026-09-11） 1.9.1 1.0.0 のまま
プラグインも更新した後 同上 1.9.1 1.9.1

上下の行は実行前後の状態を保存してあります。中段だけは記録を取っておらず、 実行中に目視したものです（クローンとカタログの値はいまでも確かめられますが、 「その時点で入っている版が 1.0.0 だった」ことは再現できません）。

カタログを取り直しただけでは、入っている版は変わりません。 更新しても古い版はキャッシュに残ります（~/.claude/plugins/cache/<marketplace>/<plugin>/）。

セッション内から実行する場合は対話形もあります（同じことをします）。

/plugin marketplace update
/plugin update <プラグイン名>@claude-code-setup

版のバナー（補助）

スキルを提供するプラグイン（cmux / orca / dev-loop）は、入っている版が SKILL.md の冒頭に 書いてあります。読み込まれた版がリポジトリより古ければ、上の 2 段階で更新してください。 原因は「キャッシュが更新されていない」とは限りません——取得済みの新しい版が在るのに 古いほうが読み込まれた実測があります（#120）。どちらであっても対処は同じです。 workspace-setup はコマンドのみを提供するため SKILL.md を持たず、この表示はありません。

バナーは、バナーが入った版が届いてからしか効きません

バナーを入れたのは、dev-loop が 1.7.1、cmux が 1.1.2（どちらも #67）です。 それより前の版で凍結している利用者には、バナー自体が届いていません ——対策が届くには対策より後の版が届いている必要があるという循環です。 orca は最初の版（1.0.0）からバナーを持っているので、この循環は当たりません。 だから上の claude plugin list を先に案内しています。そちらは古い版にも効きます。

リポジトリ側からできること／届かないこと

できること（リポジトリ側・CI で強制） 届かないこと（クライアント側の状態）
version を 3 箇所で揃える 更新を実行すること（更新する の手順）
description を共変させる 再起動すること（または /reload-plugins）
SKILL.md にバナーを刻む 掃引を起こすこと——リポジトリからできるのは掃引に加わることまでで、起こすのはクライアント側です（下記）

CI では強制できないが、リポジトリから届くものが 1 つあります——.claude/settings.json に extraKnownMarketplaces を置くと autoUpdate を宣言できます（2026-09-14 に実測。下記）。 ここで CI が何も言わないのは、このリポジトリがそのファイルを置かないと決めているからです （置くと決めたなら、CI で存在を強制することもできます）。 置いても、利用者がその workspace を信頼していなければ届きません。

autoUpdate

~/.claude/plugins/known_marketplaces.json のマーケットプレイスごとのブール値です。 公式スキーマの説明は「このマーケットプレイスとそのプラグインを起動時に自動更新するか」。

設定する手段は少なくとも 3 つあります。

手段 確からしさ
/plugin の画面 CLI の実体に Auto-update enabled. Claude Code will automatically update this marketplace and its installed plugins. という画面用の文言があります。この手順は試していません
~/.claude/plugins/known_marketplaces.json を直接編集 2026-09-13 に実測。書いた値は CLI の書き込み経路を通しても消えませんでした（plugin update が同じファイルの lastUpdated を書き換えても autoUpdate は残った）
settings の extraKnownMarketplaces 2026-09-14 に実測。リポジトリの .claude/settings.json でも効きます（信頼済みの workspace に限る）。宣言した値は known_marketplaces.json に書き込まれ、宣言を消しても残ります。下記

非対話の claude plugin には該当するオプションが見当たりません（marketplace 配下の 4 つを含む 18 枚の --help を確認）。 シェルから設定したい場合はファイルを編集することになります。

known_marketplaces.json は真の出所ではありません（実測）

settings で宣言した値は known_marketplaces.json に書き戻されます。 2026-09-14 に、リポジトリの .claude/settings.json で宣言するだけで ファイルの値が true → false → true と両方向に書き換わるのを確認しました。 つまり ファイルの値だけを見ても、それがどこから来たのかは分かりません—— 今開いているリポジトリの settings が書いた値かもしれません。 /plugin の画面には Auto-update for '...' is set by <source> and can't be changed here. という 出所を示す文言があります（画面は試していません）。

ファイルを見るだけなら:

python3 -c "import json,os;d=json.load(open(os.path.expanduser('~/.claude/plugins/known_marketplaces.json')));print(d.get('claude-code-setup',{}).get('autoUpdate'))"

設定していなくても自動更新されるものがあります（名前による既定）

CLI の実体を読むと、判定はこの順です——(1) settings の宣言 → (2) known_marketplaces.json の値 → (3) claude.ai ホストなら有効 → (4) 名前による既定。

(4) は「Anthropic 公式の名前の一覧にあり、かつ除外の 2 件に入っていない」というもので、 一覧には claude-plugins-official と anthropic-agent-skills が含まれます （除外は knowledge-work-plugins と first-party-plugins の 2 件で、一覧にあっても 既定は無効）。

claude-code-setup はその一覧に入っていないので、設定しなければ自動更新されません。

（この段落は CLI の実体を読んだもので、動かして確かめたものではありません。 実測したのは「未設定のまま 2 日置いてもカタログが進まなかった」という事実のほうです。）

リポジトリの settings から宣言できます（実測・2026-09-14）

できます。 claude 2.1.270 で測りました。リポジトリの .claude/settings.json に

{
  "extraKnownMarketplaces": {
    "claude-code-setup": {
      "source": { "source": "github", "repo": "hdknr/claude-code-setup" },
      "autoUpdate": true
    }
  }
}

と書いて、そのディレクトリを信頼した状態でセッションを起動すると、 ~/.claude/plugins/known_marketplaces.json の autoUpdate がその値になります。 デバッグログに Synced autoUpdate=<値> from settings for marketplace: <名前> が出ます。

測ったこと（claude 2.1.270・2026-09-14）:

宣言した対象 結果
既に登録済みのマーケットプレイス（claude-code-setup・github） 値が書き換わる。true → false → true の両方向とも、Synced autoUpdate=<値> from settings のログとファイルの値の両方で確認（true 方向もリポジトリの .claude/settings.json 経由）
名前も source も未登録のマーケットプレイス（directory 形式） 新規に登録される——Added marketplace source ＋ Synced autoUpdate=false が出て、known_marketplaces.json に autoUpdate つきで載る
宣言を消してからもう一度起動 書き換わった値は残る——宣言は 1 度で恒久的に効く
宣言を消したあと、別の実行から新規登録を見る known_marketplaces.json に残っていた（一覧に出た）。確かめたのは登録が残っていることまでで、セッション起動での再確認はしていない
名前だけ新しく、source は登録済みと同じもの 登録されない。Source already materialized as '<既存名>', skipping clone で短絡する
信頼していないディレクトリに置いた .claude/settings.json 宣言が届かない（reconcile の行自体が出ない）。ファイル経由の場合の話で、--settings フラグは下の行のとおり別
宣言を置いて claude plugin marketplace list を実行 宣言が当たらない。信頼済みディレクトリで登録済みのマーケットプレイスの値を変える宣言を置いても、known_marketplaces.json の値は動かなかった（セッション起動なら同じ宣言で動く）。17 行のデバッグログに Synced も [reconcile] も無い。当たらない理由までは確かめていません
同じ未信頼のディレクトリで claude --settings '<JSON>' 届いて、値まで当たる——Dropped 1 project-scoped permissions.allow entry — workspace not yet trusted と同じ実行の中で Synced autoUpdate=false from settings が出て、ファイルの値が変わった。関門はファイル経由の設定に掛かっており、フラグはその外

測っていないこと: 未登録の名前を github の source で宣言した場合。 上の 2 行目は directory 形式で測ったもので、github でも同じかは確かめていません。

信頼の関門について確かめたのは、2 つのキーだけです

信頼していないディレクトリで落ちることを確認したのは permissions.allow（Dropped 1 project-scoped permissions.allow entry — workspace not yet trusted と明示される）と extraKnownMarketplaces の 2 つです。 enabledPlugins は試していません。

permissions.allow を 1 件置いたのは対照としてで、 「宣言が届かないこと」と「そもそもファイルが読まれていないこと」を切り分けるためです ——信頼済みでは 1 件適用され、未信頼では 0 件になりました。

これは「リポジトリが利用者の設定を書き換えられる」ということです

宣言が効くのは宣言したリポジトリの中だけではありません。書き込まれる先は 利用者全体の ~/.claude/plugins/known_marketplaces.json で、 そのディレクトリを離れても、宣言を消しても残ります（上の表の 3 行目）。 知らないマーケットプレイスを新規に登録することもできます（上の表の 2 行目）。 測ったのはローカルの directory 形式で、github 形式は試していません—— どこまで起きるか（クローンまで作られるか）は、その形式で測らないと言えません。

信頼の関門があるのはこのためです。知らないリポジトリを信頼するということは、 そのリポジトリに autoUpdate を書かせることを含みます。

このリポジトリは .claude/settings.json を置いていません。 置くかどうかは利用者が決めることなので、この文書は手順を案内するだけにします。

一度、できないと書きました。撤回します。 根拠にした文字列 （must be declared under extraKnownMarketplaces in USER or managed settings）が出るのは 記録された場所やソースのパスが「ネットワーク形状、または一度も調べていないので分類できない」 と判定されたときで、ソースの種類とは別の話でした。 その後「試していないので、できるともできないとも書かない」に退きました。 今回それを実際に動かして決着させました。

有効にすると、掃引の対象に入ります（実測）

2026-09-13 に claude-code-setup の autoUpdate を true にしたところ、 その直後の掃引に加わりました。同じ時刻に、有効なものだけが一斉に更新されています。

auto-update マーケットプレイス 直前 掃引後
有効（明示） claude-code-setup 2026-09-11 07:55:18
有効（明示） spin-dd / automedia 06:01:49 07:55:18
有効（名前による既定） claude-plugins-official / anthropic-agent-skills 06:01:4x 07:55:1x
無効 astral-sh / awesome-claude-code-plugins / impeccable / taiheicloud 1〜8 か月前 動かず

有効 5 件は全部進み、無効 4 件は 1 つも動きませんでした。 とくに claude-code-setup は、2 日間止まっていたものが、フラグを立てた直後の掃引に 加わった——同じマーケットプレイスの前後比較になっています。

ここまでしか言えません

  • 確かめたのは「取り直しに行くようになった」ことだけです。このときクローンは すでに最新だったので、新しいコミットを実際に引いてくるところは見ていません。
  • この掃引はclaude plugin 系のコマンドを動かしたときに発火しました。 スキーマには「起動時に」とあり、起動時の経路も実体にあります。 2026-09-14 に発火条件を特定しようとして、できませんでした—— claude plugin list でも -p での起動でも lastUpdated は動きませんでした。 ただし条件が揃っていません（このときは --help を動かしておらず、 フラグを立てた直後でもなく、対象も 2 日止まってはいませんでした）。 「起きなかった」とまでは言えません。対話での起動も試していません。
  • どれくらいの間隔で走るかは測っていません。実体には最大 10 分ほどの 待ちを入れる形が読めます。

更新の実行と再起動は、リポジトリ側からはどうにもなりません——ここに対策を書いても 届きません。リポジトリ側からできるのは「気づける材料を置くこと」までで、 実行するのは利用者です。

autoUpdate は例外です（上記）——リポジトリの .claude/settings.json から宣言でき、 利用者が workspace を信頼していれば届きます。信頼していなければ届きません。

常に最新を使いたい場合は、bare な名前で呼びたい場合 の symlink 経路を 選びます——キャッシュを経由しないので、git pull した時点で反映されます。 ただし link-skills.sh が張るのはプラグインと同じ名前のスキル （plugins/<name>/skills/<name>）だけで、workspace-setup（スキルを持たない）と spec-loop（どのスキルもプラグイン直下の共有物を ../../ で指すので、素のスキルとしては置けない）は 対象外です。またスクリプトは自分の位置からリポジトリを解決して絶対パスで張るので、 worktree から実行するとその worktree に固定されます。メインの作業ツリーから実行してください。

workspace-setup

作業用ワークスペースの初期セットアップを対話的に行うプラグインです。Claude Code を使い始める最初の一歩をまとめて実行します。

このプラグインだけスキルを持ちません

提供するのはスラッシュコマンド 1 つです（commands/ のみ）。 そこから来る制約は 更新のしかた にまとめてあります。

インストール

/plugin install workspace-setup@claude-code-setup

提供コマンド

/workspace-setup:workspace-setup

以下を対話的にセットアップします。

  1. ワークスペースディレクトリの作成 — ~/Projects/ 配下にディレクトリを作成し git init（デフォルト名 my-workspace）
  2. CLAUDE.md の作成 — リポジトリの目的・日本語応答の指示などを記述
  3. GitHub プライベートリポジトリの作成と連携 — gh repo create --private で非公開リポジトリを作成・プッシュ
  4. 完了確認 — 作成先パス・リポジトリ URL・次のステップの提示

必ずプライベートで作成

作業用リポジトリには個人情報や機密情報が含まれる可能性があるため、必ず非公開（Private）で作成します。詳細は Part 3: インストール後の環境準備 を参照してください。

前提

  • gh CLI が認証済みであること

cmux

cmux ウィンドウ内で GitHub の Issue/PR を扱うためのプラグインです。ブラウザペインに Issue/PR を表示し、worktree でレビューを行えます。

インストール

/plugin install cmux@claude-code-setup

提供スキル

/cmux:cmux [-n] [-w|-r] <number>

cmux のブラウザペインで GitHub Issue/PR を開き、worktree でレビューを行います。

呼び出し モード 動作
/cmux:cmux <number> Issue Issue の URL をブラウザペインに表示
/cmux:cmux -w <number> PR worktree PR をブラウザ表示し、worktree を作成して gh pr checkout
/cmux:cmux -r <number> PR レビュー worktree でチェックアウトし、gh pr diff でレビュー開始

-n フラグを付けると、処理の最初に新しいターミナルタブ（サーフェス）を作成し、そこで実行します。

使用例:

# Issue 番号 12 をブラウザペインに表示
/cmux:cmux 12

# PR 番号 34 を worktree でチェックアウトしてレビュー
/cmux:cmux -r 34

動かすための前提（cmux CLI・gh CLI・EnterWorktree ツール）は プラグインの README にあります。

orca

Orca の中で GitHub の Issue/PR を扱うためのプラグインです。cmux の Orca 版で、引数と動作は揃えてあります。Orca の内蔵ブラウザに Issue/PR を表示し、worktree でレビューを行えます。

インストール

/plugin install orca@claude-code-setup

orca より前にマーケットプレイスを追加していた場合は、先にカタログを取り直す。 手元のカタログのクローンは追加した時点のコミットで止まっており、install はそれを取り直さない。 orca を含まないカタログのまま install すると、Plugin "orca" not found in marketplace で失敗する （#201 で実測。取り直してからの install は通った）:

/plugin marketplace update claude-code-setup
/plugin install orca@claude-code-setup

提供スキル

/orca:orca [-n] [-w|-r] <number>

Orca の内蔵ブラウザで GitHub Issue/PR を開き、worktree でレビューを行います。

呼び出し モード 動作
/orca:orca <number> Issue Issue の URL を内蔵ブラウザに表示
/orca:orca -w <number> PR worktree PR をブラウザ表示し、worktree を作成して gh pr checkout
/orca:orca -r <number> PR レビュー worktree でチェックアウトし、gh pr diff でレビュー開始

-n フラグを付けると、処理の最初に新しいターミナルタブを作成し、現在のディレクトリへ cd します。タブが付くのは現在のディレクトリを含む Orca 管理の worktree（いちばん内側のもの）で、.claude/worktrees/ 配下のように Orca に登録していない worktree の中からだと、それを含む Orca 管理の worktree に付きます（メインのチェックアウトが Orca 管理なら、その配下からはメインのチェックアウト。この環境の 1 件で確認）。Orca のリンク worktree の配下から始めた場合は測っていません。

動かすための前提（Orca アプリと orca CLI・gh CLI・EnterWorktree ツール）は プラグインの README にあります。

dev-loop

GitHub Issue 1 件を、検証（verify）が通ることを停止条件として 1 周させる、 ループ志向開発のスキルを提供するプラグインです。どのプロジェクトでも使える汎用版で、 プロジェクト固有の事情は対象リポジトリの CLAUDE.md から発見して従います。

設計の背景

「なぜループ志向か」「verify を停止条件に据える理由」「Dreaming・トークンコスト・ アンチパターン」といった設計思想は dev-loop の設計（ループ志向開発） にまとめています。

インストール

/plugin install dev-loop@claude-code-setup

提供スキル

/dev-loop:dev-loop <issue-number>

対象 Issue を、Issue 選択 → 文脈収集 → 計画 → 実装 → 検証（停止条件） → レビュー／PR → 本番反映 → 経験の還元、という 8 つの手順で 1 周させます （6 番目の「レビュー／PR」は 1 つの手順です）。 実装と検証を往復しますが、関門（Verifier とレビュー）は 2 パスで打ち切ります。

手順の中身と前提は、ここには書いてありません

各手順の必須要件は スキル本文 だけにあります。動かすための前提（gh CLI・git・worktree・レビューの手段・ 検証エージェントなど）は プラグインの README、 設計の理由は dev-loop の設計です。

このページに写すと、片方だけが古くなります。 実際に #75 の周で、縮退の注記に足した 参照が README には入ってこのページには入りませんでした（別の周のレビューで気づきました）。

そして #94 の周では、この注記自身が古くなりました——README から必須要件を外して スキル本文に一本化したのに、ここが「README にまとまっています」と言い続けていた。 レビューが見つけるまで、入口の数え上げにこのページを入れていながら落としていた。

使用例:

# Issue 番号 42 を 1 周させる
/dev-loop:dev-loop 42

依存のある複数の Issue を、不在のあいだに回す

台帳で複数の Issue を束ね、利用者が席を外していても起票からマージまで進める使い方は dev-loop のオートクルーズにまとめています。

/dev-loop:cruise <親 Issue> [--absent]

親 Issue のチェックリスト（- [ ] #13 (depends: #12)）に並べた Issue を台帳にし、1 件ずつ dev-loop の周として回します。 取り出した一覧は起動時に確かめてから台帳になり、同じ引数で起動し直すと台帳から再開します。 使い方は dev-loop のオートクルーズ を参照してください。

spec-loop

dev-loop の手前にある、要求側のループ（要求確定・仕様レビュー・実現性とコスト・提案書）と、 確定した仕様を dev-loop の入力（Issue）に変える引き渡しを扱うプラグインです。 設計の背景は記事 spec-loop プラグインの構成案 にあります。

スキルとデータの決まり

スキルは、要求確定のループ req-loop・仕様レビューのループ spec-review・ 実現性とコストのループ feasibility・提案書のループ proposal と、 dev-loop への引き渡し scaffold の 5 本です（計画は #214）。 どのスキルも共有するデータの決まり（正本リポジトリのツリー・Q&A 表の列・スケジュールと見積りの列・ サインオフのタグの命名・バージョンアップの版の重ね合わせ）と、それを検査するスクリプトも入っています （版の構成と、旧い構成からの移し方は下の「正本リポジトリの版と凍結」）。

データの決まりは プラグインの references/ を正とします。 中身と検査の使い方は プラグインの README にあります。

インストール

/plugin install spec-loop@claude-code-setup

req-loop — 要求確定のループ

/spec-loop:req-loop

1 回の実行がレビュー会 1 回分です。前回のレビュー会でもらった回答を仕様に反映し、 未決定事項を選択肢と提案側の推奨（理由つき）付きの質問として Q&A 表に起票し、レビュー会用の PPTX を作って、 利用者の回答待ちで止まります。

  • 回答をスキルが推測で埋めることはありません。 回答は、Q&A 表に利用者が書くか、 会話で番号ごとに伝えます（スキルは転記だけして、反映は次の実行で行います）。
  • 再開点は会話ではなく Q&A 表の状態から読みます。 別のセッションで呼び直しても続きから始まります。
  • 利用者の指示で推奨案などを暫定で採ったときは、状態 暫定反映 で表します。 仕様には反映済みとして扱い、 資料には「暫定の回答（反映済み・確認待ち）」として載せて、レビュー会で確かめてもらいます。 暫定の回答が残るうちは、要求確定のサインオフを付けません（提案書の照合が落とします）。
  • 推奨は提案側の意見で、回答の推測ではありません。 推せない質問は「推奨なし」と理由（事実の確認・見積り待ち）を書きます。 資料では推奨の選択肢を目立たせ、理由を載せます。
  • Q&A 表は 2 つの層に分かれます。 利用者に見える結果が選択肢で変わる質問は共有の表（shared/qa.csv）に、 費用・運用・内部の値だけが変わる選択は内部の表（spec/qa-dev.csv）に置きます。資料に載るのは共有の表だけで、 内部の表は開発者が決めて記録します（費用は予算の責任者へ）。線は spec-scope.md の「振り分けの区分」を正とします。
  • 0.18.0 で Q&A 表の見出しが変わりました（推奨の 2 列）。前の形の表と、写し済みの MkDocs のフックを移す手順は tree.md の「Q&A 表を移す」を正とします。
  • PPTX は同梱のスクリプト（標準ライブラリのみ）で作ります。正本リポジトリの CLAUDE.md に スライドの形式の指定があれば、そちらに従います。

手順は スキルの本文 を正とします。プラグインとしてだけ使えます（素のスキルとしては置けません。理由は プラグインの README）。

spec-review — 仕様レビューのループ

/spec-loop:spec-review

確定した要求から開発者向けの仕様を書き下し（スキルが書く側）、仕様を批判する 3 つの判定役 （Red Team・Domain Checker・Formal Checker）にレビューさせて、指摘を振り分けます。

  • 判定役はファイルを直接書くツールを持たず、仕様を書いたモデルとは別のティアで呼びます （dev-loop の Verifier と同じ形）。
  • 開発者が決めてよい指摘は仕様を直し、利用者の判断が要る指摘は Q&A 表に起票して req-loop の回答待ちに差し戻します。
  • 仕様に書くのは、範囲の中の守るべき性質とそれを確かめるテストだけです。 範囲の外の場面は範囲の文書に記録し、 実現の手段の指摘は実装に渡し、誤った指摘は理由をつけて退けます（区分は仕様を直す・共有の Q&A 表に起票する・ 内部の Q&A 表に記録する・範囲の外として記録する・実装に渡す・退けるの 6 つ。線と振り分けの区分の原本は プラグインの references/spec-scope.md）。
  • ループを抜ける条件を満たしたときだけ「抜けた」と報告します。 満たさないか、判定できなければ、 どの条件が満たせていないかを示して止まります。
  • 収束を判定役に委ねません。 判定役は指摘に重さを付け、利用者の判断が要るか同じ入力で結果が割れるものだけが条件に効きます。 2 回目のレビューのあとの直しは、その差分だけを判定役に確かめさせ（未レビューの直しを残して「抜けた」としない）、 条件を満たさない回が、利用者が最後に判断してから決まった回数に達したら（続けてでなくても数えます）、利用者に判断を返します。 仕様の規模も毎回記録し、要求より速くテストケースが増えたら削る見直しを入れます。
  • 判定役を起動する前に、要る検査器（形式検査の対象に選んだ業務フローなら TLC、権限なら Alloy）と、 正本リポジトリの CLAUDE.md に書いた照合先（改修の対象のリポジトリの clone など）が手元にあるかを確かめます。 足りなければ判定役を呼ばずに、何をどう用意すればよいかを示して、用意してから呼び直すか、用意せずに進めるかを訊きます （スキルが入れたり clone したりはしません）。

3 つの判定役

仕様を書いた側（スキル本体）は自分の仕様に甘いので、別の立場から仕様を突く役を 3 つ置いています。 どれも指摘と判定を返すだけで、仕様も Q&A 表も直しません——指摘をどの区分に振り分けるかも案として出すだけで、 決めるのはスキル本体です（判定役の案に「退ける」はありません）。

判定役 何をする役か 何を判定するか（抜ける条件の番号）
Red Team（批判役） 仕様が破れる入力・順序・状態を探します——エッジケース（二重送信・空入力・上限ちょうど・途中での取り消し・同時実行など）、同じ入力に 2 つの結果を書いている矛盾、書き漏れ。名前は、攻撃側に立って弱点を探す演習の役から来ています 条件 2（仕様チェックリストの各項目が、仕様のどこに書いてあるかを指せる）と条件 3（決定表の各行・各シナリオに、対応するテストケースがある）。指せなかった項目は「書いていない」と報告します
Domain Checker（ドメイン検証役） 仕様が、仕様の外にある決まり——既存システムの振る舞い（API・データの型と単位・状態の名前・丸め方）、社内規約・セキュリティポリシー、法令や業界の慣行——と食い違っていないかを、照合先の一次ソースを引いて確かめます。仕様が「当然」としている暗黙の前提も探します 番号の付いた条件は判定しません。 挙げた指摘は振り分けの対象になり、条件 5（3 役の指摘が 1 件残らず振り分け済み）に掛かります。照合先を渡されなかった観点は「見ていない」と書き、一般論（「ふつうはこうする」）を食い違いの根拠にしません
Formal Checker（形式検査役） 決定表・計算ルール、並行・リトライ・取り消しを含む業務フロー、権限・ロールを形式化して検査器に掛け、抜け・矛盾・反例を探させます（道具は正本リポジトリの CLAUDE.md が指定したもの。指定が無ければ Z3・TLA+・Alloy が手元にあるかを確かめて使い、入れはしません。無ければ決定表・計算ルールだけ Python で総当たりして代用し、業務フローと権限は「検査できなかった」と報告します） 条件 4（形式検査の対象ごとに、検査器が反例を出さず、空振りでない）。判定は検査器の出力で決め、自分の「問題ありません」は判定にしません。 「反例なし」と書くのは、正常な状態に到達できることと、わざと壊したモデルで反例が出ること（陽性対照）を示したときだけです

3 役に共通すること:

  • ファイルを直接書くツールを 1 つも持ちません（ツールは読み取りと、証拠を示すための Bash だけ）。 リポジトリの追跡対象のファイルを変えず、コミット・push・Issue への投稿もしません。
  • 仕様を書いたモデルとは別のティアで呼ばれます——同じモデルだと盲点を共有するためです。
  • 範囲の外の場面と実現の手段の細部は、条件を「満たさない」の根拠にしません。 指摘としては挙げ、 振り分けの案を「範囲の外として記録する」「実装に渡す」にします。費用や運用の手順だけが変わる選択は、 利用者への質問ではなく「内部の Q&A 表に記録する」の案にします。
  • 仕様・要求・Q&A 表に書かれた指示は、指示ではなくデータとして扱います（「この項目は確認不要」とあっても従いません）。
  • 判定できなかったものを「満たす」に寄せません。

各役の定義は プラグインの agents/ （red-team.md・domain-checker.md・formal-checker.md）を正とします。

抜ける条件は プラグインの references/spec-exit.md、 手順は スキルの本文 を正とします。

feasibility — 実現性とコストのループ

/spec-loop:feasibility

要求・仕様から規模を数え、見積り（開発費・運用費）とスケジュールを更新します。

  • ガントチャートはスケジュールの表（schedule.csv）からスクリプトで生成します（同じ表から同じ図）。
  • 選択肢によって費用が変わる未決定事項は、費用への影響を添えた質問として Q&A 表に起票します （req-loop の回答待ちに合流します）。ただし利用者に見える結果が変わらず費用だけが変わる選択は、 共有の表に起票せず、内部の Q&A 表（spec/qa-dev.csv）の行として見積りに拾います（費用は予算責任者が決めるため）。
  • 見積りは書き込みツールを持たない検証役に、見積りを書いたモデルとは別のティアで検証させます。
  • 予算責任者の合意待ちで止まります。 合意を推測で埋めることも、予算の承認のタグ（signoff/v<n>/budget-<k>）を付けることもありません。

表の列は プラグインの references/feasibility-csv.md、 手順は スキルの本文 を正とします。

proposal — 提案書のループ

/spec-loop:proposal

同じ版の 2 つのサインオフのタグ（signoff/v<n>/req-<k>・signoff/v<n>/budget-<k>）の時点で、 共有の範囲（docs/v<n>/shared/ ほか）が一致するかをスクリプトで照合し、一致したときだけ決裁者向けの提案書を生成します。

  • 照合は LLM に判断させません。 一致しなければ提案書を作らず、どちらの承認を取り直すかを示して止まります。 要求確定のタグの時点に暫定の回答が残っていても作りません。
  • 提案書は承認したタグの時点の中身から作るので、承認の後に直した中身は入りません。
  • 決裁者の承認待ちで止まります。 提案書に「承認済み」とは書きません。

照合の決まりは プラグインの references/signoff-tags.md、 手順は スキルの本文 を正とします。

scaffold — dev-loop への引き渡し

/spec-loop:scaffold

仕様レビューを抜けた仕様を中間表現（spec_ir.json）に書き起こし（スキルが書く側）、そこから OpenAPI・型・Red テスト（実装が無いと失敗するテスト）と、dev-loop に渡す Issue の本文を スクリプトで生成して、1 機能 = Issue 1 件で登録します。

  • 生成のスクリプトは、生成の前に仕様レビューを抜ける条件 1 を自分で確かめます（仕様に反映していない Q&A・ 未決定の印が残っていれば何も作りません。暫定の回答で反映した Q&A はこの条件では止めません）。中間表現が指す Q&A と仕様のファイルが実在することも見ます。 中間表現が暫定の回答の Q&A を指していれば止めます——利用者が確かめる前の回答を Issue にしないため。
  • Issue の本文から、受入基準（ケースごとの Red テスト）・Q&A の回答・仕様の原文を辿れます。 本文は中間表現の中のその機能の指紋と Red テストの sha256 を持ち、dev-loop は手元のファイルが Issue の時点と同じかを 確かめられます（指紋は機能単位なので、関係の無い機能を直しても登録済みの Issue は不一致になりません）。
  • 登録の前に利用者に確かめます。 Issue の登録で止まり、以降は dev-loop が受け持ちます。
  • 開発中に仕様の穴が見つかったら、dev-loop は実装で決めず、Q&A 表に起票して要求側に差し戻します （規定は dev-loop の references/spec-gap.md）。

中間表現と Issue の本文の形は プラグインの references/spec-ir.md・ references/handoff-issue.md、 手順は スキルの本文 を正とします。

正本リポジトリの版と凍結

5 本のスキルと同梱のスクリプトは、正本リポジトリの docs/ を版ごとのディレクトリ docs/v<n>/ として読みます。 決まりの原本は プラグインの references/versions.md で、ここには要点と指し先だけを置きます。

  • 版が 1 つしか無いうちから docs/v1/ に置きます。 v2 以降には前の版からの差分だけを置き、 スクリプトが版を重ね合わせて全体を作ります。作業中の版は番号が最大の版です。 ツリーと重ね合わせの決まりは versions.md の「ツリー」「重ね合わせ」、版の中の置き方は references/tree.md を正とします。
  • サインオフのタグも版ごとです（signoff/v<n>/req-<k>・signoff/v<n>/budget-<k>。 references/signoff-tags.md）。
  • リリースした版は凍結します。 リリースは release-v<n> のタグで示し（タグはスキルが付けず、人間が付けます）、 その版の docs/v<n>/ はタグの時点から直しません。変えたいことは作業中の版に差分として置きます。 直されていないかは同梱の check-frozen.py で確かめ、正本リポジトリの CI で走らせます。 終了コードと CI での取り方は versions.md の「凍結」を正とします。

0.11.x 以前から更新した場合 — 旧い構成と旧いタグは読みません

0.7.0 から、版に分ける前の構成（docs/shared/・docs/spec/… が docs/ の直下）を読みません。 そのままの正本リポジトリでは、scaffold.py も check-signoff.py も「版（v1 など）が 1 つも無い」と出して 2 で終わり、 何も作らず・照合しません（check-signoff.py に版を指定しても同じです）。 移し方は versions.md の「移し方」を正とします。

前の名前のサインオフのタグも読みません——版を分ける前の名前（req-signoff-v<n> など）も、 0.7.0〜0.11.x の名前（v<n>/req-signoff-<k>・v<n>/budget-signoff-<k>）もです。 後者は、取り直したあとも手元とリモートから消さないと、素の v<n> タグでリリースしているリポジトリでは v<n> を付けられません（凍結のタグ release-v<n> は衝突しません）。 取り直し方と片付け方は signoff-tags.md を正とします。 タグはスキルが付けません——承認を取り直すのは、承認した利用者・予算責任者です。

bare な名前で呼びたい場合

プラグイン経由の呼び出しは必ず プラグイン名:名前 になります（スキルもコマンドも同じ）。/cmux のように 名前空間の付かない名前で呼びたい場合は、マニフェスト（.claude-plugin/）を持たない素のスキル として skills ディレクトリに置きます。置き場所で有効範囲が変わります （スキル活用ガイド の置き場所の表と同じ区別です）。

置き場所 有効範囲
~/.claude/skills/<name>/ すべてのプロジェクトで自動的に読み込まれる
<プロジェクト>/.claude/skills/<name>/ そのプロジェクトだけ

以下は全プロジェクトで使う場合の手順です。リポジトリを clone して、付属のスクリプトを実行します。

git clone https://github.com/hdknr/claude-code-setup.git ~/src/claude-code-setup
~/src/claude-code-setup/scripts/link-skills.sh

引数なしで実行すると、このリポジトリが配布する素のスキル（現在は cmux・orca・dev-loop）を すべて張ります。名前を渡せばその分だけ張ります。

~/src/claude-code-setup/scripts/link-skills.sh cmux
オプション 意味
-d <dir> 置き場所を変える（既定は ~/.claude/skills）。プロジェクト単位で入れたいときに使う
-n 何をするかだけ表示して、実際には変更しない

なぜスクリプトなのか

素朴に ln -s を並べるだけだと、宛先や clone の状態によって黙って壊れます。実際に 起きた壊れ方:

  1. clone が無い／パスの指定を間違えた場合 — 動いているスキルを退避したうえで 壊れた symlink を張り、終了コード 0 で何も出力せずに終わる（/<name> が消える）。
  2. ~/.claude/skills/<name> に symlink 以外のものがある場合（個人スキルとして直置きした 実ディレクトリなど）— ln -sfn はエラーを出さずに <name>/<name> を作り、/<name> は 古いスキルを指したままになる（-f はディレクトリを unlink できないため）。

この手順を文書に手で複製していたところ、4 ラウンド連続でこの類のバグが出ました（しかも 毎回、前回の修正が次の穴を開けていました）。そこで手続きを 1 箇所に集め、テスト （scripts/test-link-skills.py）を当てています。

スクリプトはリポジトリの位置を自分で解決するので clone 先を入力する必要がなく （入力が無ければパス指定ミスも起きません）、同名の実ディレクトリがあれば .bak.<日時> へ 退避し、張った後に解決を確認して、できていなければ非 0 で終わります。

次のセッションから、どのプロジェクトでも /cmux /orca /dev-loop で呼べます。更新は clone 先で git pull するだけでよく、symlink の張り直しは不要です。

プラグインと併用すると両方並びます

プラグインを入れたまま symlink も張ると、/cmux と /cmux:cmux の両方がスキル一覧に 出ます（中身は同じなのでどちらでも動きます）。片方だけにしたい場合は、プラグインを 入れずに symlink だけにしてください。

Windows は未検証です

スクリプトは POSIX sh で書いてあり、sh / bash / zsh / dash でテストしています （scripts/test-link-skills.py、CI でも実行）。テストを回しているのは macOS ですが、 dash も含めて通るので Linux でも同じ挙動になる見込みです。

Windows は未検証です。symlink を使わない場合はディレクトリをコピーし、git pull の たびにコピーし直してください。