コマンドとスキルルーティング

Chorus プラグインは、AI-DLC パイプラインの各段階につき 1 つのコマンドを追加します。このページは それらのコマンドのリファレンスで、各コマンドをいつ実行するか、API キーにどの権限が必要か、 何が得られるかを説明します。パイプラインそのものの説明は繰り返しません。それについては AI-DLC ワークフローと、下記にリンクした各段階のガイドをお読みください。

Hermes では skill_view("chorus:idea")、skill_view("chorus:develop")、skill_view("chorus:yolo") で名前空間付きスキルを読み込みます。全段階と 3 種のレビュアーが含まれます。Claude のスラッシュコマンドではなく、すべての Chorus UI 操作をゲートウェイで実行できるという意味でもありません。

ランタイムによって呼び出し方が異なる

Claude Code はこれらのコマンドを chorus 名前空間下のスラッシュコマンドとして公開します。Codex は 同じスキルを $ 接頭辞で公開します。動作は同一で、コマンドの入力方法だけが異なります。

# Claude Code — /chorus: スラッシュコマンド
/chorus
/chorus:idea
/chorus:proposal
/chorus:develop
/chorus:review
/chorus:quick-dev
/chorus:yolo

# Codex — $ 接頭辞のスキル名
$chorus
$idea
$proposal
$develop
$review
$quick-dev
$yolo

本ページのコマンドはすべて Claude Code 形式（/chorus:develop）で表記します。Codex では $ 形式 （$develop）に読み替えてください。その他のランタイム（OpenClaw、Kiro、Pi）も同じスキルを搭載しています。 ランタイムごとの呼び出しの注意点は、エージェントプラットフォーム下の各ページを参照してください。

/chorus — ルーティングと設定

/chorus      # Claude Code
$chorus      # Codex

• トリガー: セッションの開始時、またはどの段階コマンドを使えばよいか迷ったときに実行します。 概要の確認と、適切なコマンドへの振り分けを行います。
• 必要な権限: 接続済みのプラグインと API キー。特定の権限は不要です。
• 成果物: ワークフローの状態は変わりません。プラットフォームの概要、あなたの役割と有効な権限を 提示し、下記の適切な段階コマンドへ案内します。

各段階コマンド

一覧:

コマンド	必要な権限	成果物
/chorus:idea	idea:write（要件詳細化の確定には idea:admin）	要件詳細化が確定し、計画に進める担当済みの着想
/chorus:proposal	proposal:write + document:write	提出済みの提案 — 文書ドラフト + 課題 DAG（draft → pending）
/chorus:develop	task:write	作業報告と自己チェック済みの受け入れ基準を伴い to_verify まで進んだ課題
/chorus:review	proposal:admin + task:admin	承認された提案（ドラフトから実際の文書と課題を作成）と検証済みの課題（→ done）
/chorus:quick-dev	task:write（自己検証には task:admin）	独立した、または提案にひもづく課題を to_verify / done まで駆動
/chorus:yolo	管理者プリセットのキー（全リソースの write + proposal:admin + task:admin）	プロンプトから 1 つの着想を完了まで進め、完了レポートを添付

/chorus:idea — 構想

/chorus:idea     # Claude Code
$idea            # Codex

• トリガー: 要件へと形にすべき未処理の着想があるとき。担当し、構造化された要件詳細化のラウンドを 実行します。
• 必要な権限: 担当と要件詳細化の実行には idea:write。要件詳細化の確定（コミットゲート）には さらに idea:admin が必要で、PM プリセットのキーはこのステップを管理者プリセットのキーに 引き渡す必要があります。
• 成果物: 要件詳細化のラウンドに回答・確定した担当済みの着想 — /chorus:proposal に進める状態です。 着想を記録を参照してください。

/chorus:proposal — 計画

/chorus:proposal # Claude Code
$proposal        # Codex

• トリガー: ある着想の要件詳細化が確定し、作業を計画する準備が整ったとき。
• 必要な権限: 提案コンテナ、課題ドラフト、依存エッジには proposal:write。PRD、技術設計、仕様の ドラフトには document:write。
• 成果物: 文書ドラフトと課題ドラフトの依存グラフを保持し、検証を経てレビューに提出された提案 （draft → pending）。提出時、フックがメインエージェントに提案レビュー担当の起動を促します。 自動化の挙動を参照してください。

/chorus:develop — 開発

/chorus:develop  # Claude Code
$develop         # Codex

• トリガー: 承認済みの課題があり、そのうちの 1 つを実装する準備ができたとき。人が Chorus から 着想の開発を開始すると（start_development リクエスト）、エージェントはその着想の残りの課題すべてを依存順に進めます。
• 必要な権限: 担当、作業報告、受け入れ基準の自己チェック、提出には task:write。
• 成果物: 担当され、in_progress → to_verify と進んだ課題。作業報告と自己チェック済みの受け入れ基準を 伴います。提出時、フックは課題レビュー担当の起動を促します。課題を実行を 参照してください。

/chorus:review — レビューとガバナンス

/chorus:review   # Claude Code
$review          # Codex

• トリガー: 提案が pending、または課題が to_verify にあり、あなたが管理者（人間の代理となる役割）として 対応するとき。
• 必要な権限: 提案の承認や終了には proposal:admin、課題の検証・再オープン・終了と受け入れ基準の マークには task:admin。完全な管理者プリセットのキーは両方に加え、着想と文書を終了するための ガバナンス権限も備えます。
• 成果物: 承認された提案（その文書ドラフトと課題ドラフトから実際の文書と課題が作成される）と検証済みの 課題（to_verify → done）、あるいはフィードバック付きで却下・再オープンされた項目。 提案を審査と検証して完了を 参照してください。

/chorus:quick-dev — 直接課題

/chorus:quick-dev # Claude Code
$quick-dev        # Codex

• トリガー: 小規模で内容が明確な作業（バグ修正、ホットフィックス、後続パッチ）で、完全な 着想 → 提案の一巡が過剰なとき。
• 必要な権限: 課題の作成、担当、実行には task:write。結果の自己検証には明示的な task:admin が 必要で、それがなければエージェントは証拠を投稿し、人間に検証を引き渡します。
• 成果物: 独立した課題（または proposalUuid で既存の提案にひもづく課題）を to_verify まで、 キーが task:admin を持つ場合は done まで進めます。

/chorus:yolo — 全自動パイプライン

/chorus:yolo <prompt>                        # Claude Code
$yolo <prompt>                               # Codex
/chorus:yolo <prompt> --project <project-uuid>

• トリガー: 自然言語のプロンプトから、無人でパイプライン全体を実行したいとき。Chorus からの yolo_requested リクエストでは、既存の着想を現在の段階から再開します。
• 必要な権限: 管理者プリセットの API キー — 全リソースの write に加え proposal:admin と task:admin（具体的には idea:write、proposal:write + proposal:admin、task:write + task:admin、および project:write）。いずれかの権限が欠けていると、スキルは起動時に中止します。
• 成果物: 完全な一巡 — （未指定なら）プロジェクト、着想、自己要件詳細化、提案、依存順に段階的に進める課題の実行、 レビューのループ、管理者検証、そして必須の完了レポート。人間の明示的な承認なしに PR をマージ・ プッシュすることは決してありません。

エージェント向け

• トリガー: ルーティングと役割の確認には /chorus（$chorus）。各段階コマンドはその段階に達したとき、 または人間による起動で発火します — start_development は着想の残り課題すべてに対して /chorus:develop を再開し、yolo_requested は着想の現在の段階から /chorus:yolo を再開します。
• 制約:
  • ツールの可視性はキーの権限セットに従いますが、ハンドラのガードは依然として有効です。例えば task:write を持っていても、課題の担当者だけが chorus_submit_for_verify を呼び出せます。
  • /chorus:yolo は管理者プリセットのキーを必要とし、必要な権限が 1 つでも欠ければ中止します。 /chorus:quick-dev は明示的な task:admin を持つ場合のみ自己検証し、そうでなければ人間に 引き渡します。
  • Codex では同じスキルを $ 接頭辞で呼び出します。レビューと自動化の見え方はランタイムによって異なります。 自動化の挙動を参照してください。
  • /chorus:yolo 下も含め、人間の明示的な承認なしに PR をマージ・プッシュすることは決してありません。