自作の Claude Code Skill を集めた、成長し続けるレパートリーで、単一のプラグインとして配布されています。一度インストールすれば、すべての Skill が手に入ります。コレクションが拡大するにつれて、さらに多くの Skill が利用できるようになります。
/plugin marketplace add PythonShe/Repertoire
/plugin install repertoire@repertoireその後、再起動するか /reload-plugins を実行してください。Skill はプラグインの名前空間の下に置かれます（例: /repertoire:maestro）。
これらの Skill は意図的にトークンを多く消費します。実行のたびに新規の subagent 群を medium〜xhigh の推論労力で編成して動かします——ビルドシート（実装者、フィクサー、QC ゲート）はあなたのセッションモデルで、レビューシート（調査者、レビューパネル、検証者）は Opus に固定——その点こそが信頼性の源泉となっています。プランはそれに見合ったものを用意してください。
- Claude Max（5x または 20x）、もしくは API 課金 — 想定されている構成です。これより軽量なプランでは、実行の途中で利用上限に達する可能性が高くなります。
- OpenAI の
codex-ccプラグイン をインストールした Codex アカウント — 強く推奨します。Presto、Jam、Legato を除く各 Skill は、これを通じてクロスモデルの Codex エージェント（レビュアーまたは調査者）をディスパッチします（Presto が意図的にこの席を持たないのは、クロスモデルのパスが時間に見合うのはブランチ全体に対してであって、1 つの変更に対してではないからです。Legato も同じ理由でこの席を持ちません — 対象が 1 つのスコープされたモーションの磨き上げだからです。Jam が持たないのは、その実行が無人だからです — ハングしたクロスモデル呼び出しは、誰も見ていないセッションを止めてしまいます。代わりに Jam のフィナーレでは、Opus に固定されたレビュアーとセッションモデルで動くレビュアーがペアを組みます）。Codex がなくても Skill は適切にデグレードして動作し、Opus のみのパネルで実行したうえでその旨をレポートに記載しますが、クロスモデルでのチェックは設計の一部です。
モデルに関する注記： これらの Skill は 2 つの階層で動作します。ビルドシート——実装者、フィクサー、QC／最終ゲート——はモデルを固定しません。セッションモデルを継承するので、アクセスできる最も高性能なモデルでセッションを開始してください。
/model bestは、アクセス権があれば Fable 5、なければ最新の Opus に解決されます——ビルドシートで Fable の速度を活かしつつ、Opus への自動フォールバックを備え、モデル名をハードコードしないため、Fable が再び停止されても壊れません。レビューシート——調査者、レビューパネル、検証者——は、安定した敵対的ベースラインとして Opus に固定されます（唯一の意図的な例外は Jam のフィナーレの 2 人目のレビュアーで、モデルを固定せずセッションモデルで動きます — このクロスティアのペアはshared/invariants.mdに記録されています）。これらの Skill はbestまたはopusで実行してください——Sonnet は決して使わないでください。
| Skill | Invoke | What it does |
|---|---|---|
| Eureka | /repertoire:eureka |
何かを作り始める前に、作る価値のあるアイデアを発掘します。まず対話の範囲（既存のコードベース、オープンな領域、または半分形になったひらめきの周辺）とフォーカスする次元を定め、ペースを管理した対話で候補を探します。シードスケッチ、継続的に維持されるアイデアボード、そしてオンデマンドで編成される 3〜4 名の多様なレンズを持つアイディエーター（ideator）のバーストです。ファイナリストを収束させたら、逐次的な審査ファネル（アイデンティティ → コンプライアンス → 需要 → 実現可能性）にかけます。どのキル評決も、ユーザーの確認があって初めてアイデアの死が確定します。成果物はランク付けされ審査済みのショートリストで、チャンピオンは任意で Libretto に引き継ぎます。spec もコードも書きません。一致するリクエストで自動的に起動します。 |
| Libretto | /repertoire:libretto |
ガイド付きの設計対話を通じて、漠然としたアイデアをビルド可能な仕様に変え、最終的なユーザー承認ゲートの前に、敵対的な subagent のレビューパネル（多様なレンズを持つ 2〜3 名の Opus 懐疑者 + クロスモデルの Codex レビュアー）で堅牢化します。委譲するのはコンテキスト収集とレビューのみで、承認された仕様で完了し、それを構築するための Maestro を案内します。自動連鎖はしません。一致するリクエストで自動的に起動します。 |
| Score | /repertoire:score |
承認された仕様を、意思決定が完了した実装計画に変えます。Maestro がそのまま扱えるタスクグループの楽章（movement）として、正確なパス、インターフェース、テストの期待値を備えつつ、関数本体は含めません。その後、最終的なユーザー承認ゲートの前に、同じ敵対的なレビューパネルで堅牢化します。1 つのゴールに複数の計画が必要な場合はプランセット（plan set）に拡張します：コントローラー自身が計画横断の契約を担う 00-overview.md を執筆し、並列の plan-writer subagent が計画ファイルを 1 つずつ書きます（単一の計画では overview は作りません）。ユーザーとの構造的なチェックポイントは 1 回で、承認された計画で完了し、それを指揮するための Maestro を案内します。自動連鎖はしません。一致するリクエストで自動的に起動します。 |
| Maestro | /repertoire:maestro |
実装計画の subagent 駆動の実行を指揮します。関連するタスクをグループ化し、各グループを新規の実装者で構築したうえで、ブランチ全体を敵対的なレビューパネル（多様なレンズを持つ 3 名の Opus 懐疑者 + クロスモデルの Codex レビュアー）と、エビデンスに基づく品質管理のマージゲートでゲートします。その間、指揮者は自身のコンテキストを軽量に保ちます。一致するリクエストで自動的に起動します。名前が明示的に指定されていない場合は、ディスパッチの前に範囲とコストを確認します。 |
| Coda | /repertoire:coda |
オープンな PR のレビューフィードバックを最後までやり切ります。事務担当（clerk）がすべてのレビュー、インラインスレッド、会話コメント、失敗した CI チェックを収集し、1 名の読み取り専用の検証者が各項目をコードベースの実態と照らし合わせて検証します（修正するか、押し返すか、質問するか — 判断はエビデンスが決めます）。逐次的に動くフィクサーが残った項目を修復し、大きい修正やリスクのある修正は 3 レンズの Opus パネルにかけられます。すべての実行は段階的な最終評決で締めくくられます。これは各修正を全文読むエビデンスベースの QC で、QC をクリアすると PR 全体に対するクロスモデルの Codex パスが 1 回走ります。1 つの承認ゲートが、プッシュとドラフトされたスレッド返信の投稿の両方をカバーします。マージは行わず、スレッドの解決（resolve）も行いません。一致するリクエストで自動的に起動します。名前が明示的に指定されていない場合は、ディスパッチの前に範囲とコストを確認します。 |
| Encore | /repertoire:encore |
完成済みのコードベース、機能、モジュールを再訪し、すでに動いているものをさらに磨き上げます。スカウトがターゲットをプロファイルして品質レンズの編成（パフォーマンス、セキュリティ、堅牢性、DX など）を提案し、並列で動く多様なレンズの Opus ハンターが強化の機会をコールし、1 名の読み取り専用の検証者がすべてのコールをコードベースの実態と照らし合わせます。反証されたコールは記録に残して棄却し、フィーチャー規模のものは Libretto または Score にルーティングして、この実行では決して実装しません。実装されるのは、セットリストのゲートでユーザーが選んだものだけです。新規の encore/ ブランチ上で逐次的なフィクサーが実装し、大きい変更やリスクのある変更は 3 レンズの Opus パネルにかけられ、すべての実行は段階的な最終評決 — エビデンスベースの QC、その通過後に 1 回のクロスモデルの Codex パス — で締めくくられます。プッシュと PR の作成は 1 つの承認ゲートの先にあり、マージは行いません。一致するリクエストで自動的に起動します。 |
| Presto | /repertoire:presto |
生産ラインの隣にある高速レーンです。スコープの定まった 1 つの変更を、spec も計画も前段に置かずに、一気に作り切ります。1〜2 名の読み取り専用の Opus スカウトが着地点を特定して実装アプローチを比較検討し、ユーザーはただ 1 つの AskUserQuestion ゲートで選択します — このゲートが通るまで、1 行も書きません。その後、サイズゲートが席を決めます。小さい変更は引き継ぎのコストを払うより速いので、コントローラー自身が実装し、それより大きいものは 1 名の実装者 subagent が引き受けます。その後には必ず Opus レビュアーが 1 名続きます — とりわけコントローラー自身が書き手だった場合にこそ。続いて修正が 1 パス（自分が書いたもの、および些細なものはコントローラーが直し、残りはフィクサー subagent が引き受けます）、最後に短いビルド + テストの QC ゲートで締めくくります。通常の経路ではエージェントは下限 3 名、上限 6 名。設計として編成を増やしたくなった実行 — 3 人目のスカウト、2 巡目のレビュー、複数レンズのパネル — は高速レーンの範囲を超えています。出口は 2 つあります。規模が大きすぎる作業は承認ゲートの時点で Libretto または Score に引き継がれ、QC に 2 回続けて通らなかった変更は Maestro に引き継がれます。クロスモデルの Codex 席を意図的に持たない 3 つの Skill の 1 つです（Legato は同じ理由で、Jam は別の理由で持ちません）— こちらは、あのパスが時間に見合うのはブランチ全体に対してであって、1 つの変更に対してではないからです。一致するリクエストで自動的に起動します。名前が明示的に指定されていない場合は、偵察の前にブリーフとブランチを確認します。 |
| Jam | /repertoire:jam |
自律セッションです。ユーザーが鍵を手渡すと、Jam は自分で作業リストを見つけ、自分で出荷まで持っていきます。3 名の読み取り専用の Opus スカウトが並列でリポジトリを研究します。視点は常にエンドユーザーの席からで、互換性を壊さない新機能、ユーザーが黙って我慢している素早い修正、UI/UX の磨き上げの 3 レンズです。その後、Opus のセレクターが候補を 1 セッションに収まる 3〜5 件のジョブからなるドケット（docket）に絞り込み、承認を待つのではなくユーザーに告知して着工します。新規の実装者がジョブを 1 件ずつ逐次構築し、ジョブごとの Opus レビューを送るかどうかは指揮者の裁量です（挙動に触れるものは必須、ドキュメントや見た目だけのものはスキップ可）。2 回ブロックされたジョブは粘らずにドロップします。フィナーレは決して薄めません。ブランチ全体に対する 2 名のレビュアーが並列で走ります — 1 名は Opus に固定、1 名はセッションモデルで動き、この無人実行が意図的に持たない Codex 席をこのクロスティアのペアが代替します — 続いてエビデンスベースの QC ゲートがビルドとテストを実行し、出荷できないジョブはクリーンな revert で切除（amputate）できます。QC の 2 ストライクでユーザーにエスカレーションします。プッシュは求められたときのみ、マージは決して行いません。一致するリクエストで自動的に起動します。名前が明示的に指定されていない場合は、ディスパッチの前に範囲とコストを確認します。 |
| Legato | /repertoire:legato |
モーションのレーンです。ユーザーが名指しした UI サーフェスのアニメーションを、中〜小規模で磨き上げます。読み取り専用の Opus スカウトが 1 名、同梱のモーションクラフト基準 — Emil Kowalski のアニメーション標準を MIT ライセンスに基づき references/ に複製したもの — に照らして、名指しされたページやウィジェットを監査し、モーションの棚卸しと正確な数値付きの提案を返します。数値は必ず引き写しで、概算はしません。ユーザーはただ 1 つの AskUserQuestion ゲートで方向を確定します。具体的なゴールを持ち込んだ場合は標準に照らして評価したうえで踏み込んで確認し、決めかねている場合は最大 3 つの一貫した方向性と推奨を提示します。その後、1 名の実装者 subagent が承認済みのモーション spec を構築し、新規の Opus レビュアーが 1 名、diff を 10 の譲れない標準に照らして審査し（発見は Before/After/Why の表で示します）、最後にビルド + テストの QC ゲートで締めくくります — アプリがすでに起動していれば、ブラウザ越しに実際の動きを確かめることもできます。締めくくりに、決定をターゲットプロジェクトの docs/repertoire/animation.md に書き込みます — 以後の実行が従う恒常的なガイダンスで、行はその場で置き換え、changelog にはしません。クロスモデルの Codex 席を持たない 3 つの Skill の 1 つです（理由は Presto と同じです）。アプリ全体のモーション刷新はこのレーンの外です — それは Libretto、Score、Maestro に進みます。一致するリクエストで自動的に起動します。名前が明示的に指定されていない場合は、スカウトを送る前にブリーフとブランチを確認します。 |
| Tuner | /repertoire:tuner |
2 名のライバル調査者とともに、バグをその根本原因まで追い詰めます。1 名はバグのブリーフが存在した瞬間にディスパッチされる xhigh 推論労力の Codex エージェント、もう 1 名はトリアージのスカウトがランク付けした障害箇所で準備された、同じく xhigh の推論労力で動く体系的な Opus 調査者です。そして 2 つの仮説を突き合わせて反対尋問し、確信度ゲートとします。修復はテストファーストで進めます。フィクサーが、最小限の修正の前に意図的にレッドな再現テストをコミットし、懐疑的なレビュアーが修正をゲートし、機械的な検証者がレッド→グリーンとグリーンなテストスイートを証明します。フィーチャーブランチにコミットし、マージは行いません。一致するリクエストで自動的に起動します。名前が明示的に指定されていない場合は、ディスパッチの前に範囲とコストを確認します。 |
クローンから直接、インストールせずに変更をテストします。
claude --plugin-dir .
/reload-plugins # after edits, no restart needed
claude plugin validate .Repertoire/ リポジトリルート = プラグインルート = marketplace ルート
├── .claude-plugin/
│ ├── plugin.json プラグインマニフェスト（name: repertoire）
│ └── marketplace.json このプラグインを掲載するカタログ（source "./"）
├── skills/ Skill ごとに 1 ディレクトリ
│ └── <name>/ eureka、libretto、score、maestro、coda、encore、tuner、presto、jam、legato
│ ├── SKILL.md
│ ├── evals/evals.json コミット済みの trigger evals
│ ├── *-template.md 同梱のドキュメント構造（libretto、score、legato）
│ ├── *-prompt.md 同梱の subagent プロンプトテンプレート
│ └── references/ 同梱のサードパーティ参照資料（legato。MIT ライセンス、同ディレクトリの LICENSE を参照）
├── shared/
│ ├── codex-reviewer-core.md 共有の Codex 呼び出し契約
│ └── invariants.md 規範となる 2 階層モデルポリシー
├── docs/
│ ├── adr/ アーキテクチャ決定記録（ADR）
│ └── authoring/ Skill 作成の指針
├── CHANGELOG.md
└── README.md
skills/<name>/SKILL.mdを作成します（YAML フロントマター:name、description、when_to_use— 指針はdocs/authoring/skill-descriptions.mdにあります）。サポート用のプロンプト/リファレンスファイルがあれば、その隣にまとめて置きます。あわせて、トリガー評価（trigger evals）をskills/<name>/evals/evals.jsonに置きます。- 上記の Skills テーブルに行を追加します。
claude plugin validate .を実行してからコミットします。新しい Skill は自動的に検出されます。リポジトリ全体が 1 つのプラグインなので、カタログに新しいエントリは一切必要ありません。
version を上げます。.claude-plugin/plugin.json と .claude-plugin/marketplace.json 内のプラグインエントリの両方で同じ値にします。既存のインストールに変更を反映させたいときに行ってください（ユーザー側には /plugin marketplace update 実行後に反映されます）。