orca-workflow

スキル：orca-workflow

🧭 ディスパッチバックエンド — 安価なエージェント／モデルを選び、複数のワーカーを並行実行し、opencode/orchestration の構文を確認するには、orca-dispatch-reference を参照してください（唯一の信頼できる情報源です。ここで構文を重複させないでください）。

概要

目的とコンテキスト

• 目的： Orca を介して、提案 → ゲート → ディスパッチ → 検証を行います。エージェントプールはエンジンごとに 1:1（claude、agy、opencode、kiro、copilot）です。Claude は分析し、ほかのエージェントは実行します。待ち時間が長すぎる場合は opencode を終了します。
• トリガー（使用する場面）：
• 「 を提案」、「機能リクエスト」、「 を実装」
• 「lint を実行」、「wiki を検証」
• 「テンプレートを同期」、「upstream」
• 対象外： インシデント（バグ、ランタイムエラー、リグレッション）は扱いません（→ orca-issue）。ディスパッチバックエンドの構文を重複させません（→ orca-dispatch-reference）。/propose、/plan、/query の動作を再説明しません（唯一の信頼できる情報源は子スキルにあります）。

メンタルモデル

機能リクエスト → R12 sweep → /query (wiki) → /propose (SPEC .md + 安価な .html レンダリング) → 承認者ゲート → /plan (機械可読な PLAN) → プロジェクト識別情報付き task-create → HITL/AFK ゲート + 作業種別 → 原文のまま dispatch --inject → worker_done → [/qc-code] → verify-before-commit → 出力レポート。Claude は分析し、ほかのエージェントは実行します。T-id（永続的な台帳）は task_xxxx（Orca の一時的な値、ランタイム全体で共通）とは別です。

入出力の契約

	フィールド	必須？	意味
In	機能の説明（「 を提案」、「 を実装」）	はい	インシデントの場合は orca-issue に切り替えます
In	llmwiki/wiki/	いいえ	不足／空の場合は「前例なし」と記録します
In	ゲートでのユーザー承認	はい	/plan とディスパッチの前に必要です
In	利用可能なエージェント CLI（opencode/agy/kiro/gh copilot/orca）	いいえ	使い切った場合は Claude が自ら実行します
Out	SPEC ドラフト .md + .html（/propose 経由）	はい	承認者が確認するもの
Out	llmwiki/wiki/sources/draft/DDMMYY-<tên>-PLAN.md（/plan 経由）	承認後は必須	機械が実行するもの
Out	プロジェクト識別情報付き Orca タスク + T-id の状態	はい	code-logger 経由で approved/rejected/dispatched（fail-open）
Out	出力レポート llmwiki/wiki/draft/orca/DDMMYY-<ten>.md + インデックス + ログ	必須（成果物が 0 件の場合を除く）	「完了」とは、worker_done + verify-before-commit が成功し、レポートの Status が更新されている状態です

ルールと機能

• RULE-01 (MUST): Caveman Mode: ファイルを読む人に合わせて詳細度を選びます。機械またはエージェントが読み取り、実行する Markdown ファイル（SKILL.md、policy.yaml、AGENT.md、プレーンな参照表）は簡潔に書いてかまいません。ここでの caveman は、問題を起こさずにトークンを節約できます。しかし、人間が読んだりレビューしたりするドキュメントでは、必ず caveman をオフにして、内容を十分に記述してください。proposal、output-report、wiki の内容（concept/ADR/registry）、README、CONTRIBUTING、runbook、およびすべての HTML ページが対象です。これらのファイルは、完全な文で構成された読みやすい文章にしてください。接続詞を省いたり、ぶつ切りの略記を使ったり、説明文の代わりに表を詰め込んだりしてはいけません。2026-06-27 の教訓：ユーザーから「ドキュメントを書くときに caveman で圧縮しすぎている」とフィードバックがあり、その後、機械が読むファイルは簡潔でよいが、人間が読むファイルは十分に記述する必要があると明確になりました。
• RULE-02 (MUST): Claude：分析します。それ以外：実行します。待ち時間が長すぎる場合は opencode を終了します。
• RULE-03 (MUST): プロセス問題台帳（problem-tree）— llmwiki/ があるプロジェクトでは、問題ツリー台帳は llmwiki/html/problem-tree.html にあります（framework リポジトリでは fdk-problem-tree.html）。プロセス／framework の問題を発見または解決したセッションでは、JSON ブロック #tree-data にノードを更新します（追記のみ。解決済みのものには solvedBy を記録します。スコープは harness/skills/llmwiki の3本柱で、3/3の場合のみ緑色です）。忘れても記録は失われません。SessionEnd hook（R17）がコードで保留タグを自動記録し、次回に distill します。
• RULE-04 (MUST): spec タスクには、必ずプロジェクトのスタンプを付けます：orca orchestration task-create --spec "$(python3 harness/scripts/orca-reconcile.py --stamp '<spec>')"（Orca タスク台帳はランタイム全体で共通です）。
• RULE-05 (MUST): HITL タスクを割り当てられたエージェントが、ユーザーの代わりに推測するしかなくなり、黙り込むのは、モデルの能力不足ではなく評価1/5に相当します — HITL をヘッドレス CLI にディスパッチしてはいけません。
• RULE-06 (MUST): --inject では、PLAN にあるタスクの brief を ## Global constraints とともに原文のまま注入します。要約し直してはいけません。
• RULE-07 (MUST): コンテナ／DB の安全性 — --force-recreate、down、再作成を行う前に、必ず docker inspect <container_name> --format '{{json .Mounts}}' | python3 -m json.tool を実行します。ボリュームが異なる場合は停止し、ユーザーに確認します（詳細は Reference を参照）。
• 機能：wiki の読み取り、オーケストレーションランタイム経由でのゲート／タスクの作成とディスパッチ、ヘッドレスのエージェント CLI または対話型ターミナルの実行、wiki のドラフトと T-id 台帳の記録、（任意）HTTP 経由のセッション間メモリ、スキルのソースリポジトリへの同期プッシュ。

失敗時の境界

• 入力がインシデントの場合 → orca-issue に振り分け、提案はしません。
• R12 sweep：リモートの後に TARGET サブリポジトリがある場合 → git pull --rebase が実行されるまでブロックします。オフラインの場合 → fail-open。
• ユーザーがゲートで拒否した場合 → cancelled、T-id は state=rejected。
• HITL タスク → ディスパッチせず、ラベルは ready-for-human（人間待ち）です。
• ヘッドレス CLI が約60～90秒を超えて無応答／ファイルを作成しない／diagram-box が不足 → 終了し、Claude が引き継ぎます（フォールバック）。
• コンテナのボリュームが compose と異なる場合 → ブロックし、ユーザーに確認します。
• task-update --status done → 何も通知せず ok:false を返します（有効な status：ready | in_progress | completed | failed）。

方法

メインワークフロー

ステップ	種類	入力	アクション	出力／終了	失敗時／次の処理
W01	決定的	ワークスペース	ステップ 0 — R12 (B) の作業前スイープ pull-gate-sweep.sh を一度実行	最新のベース	remote 後に TARGET が発生 → pull --rebase を実行して繰り返す
W02	判断	機能	ステップ 1 — /query を呼び出して Wiki のコンテキストを集約	既知の事項＋不足分	空 → 「前例なし」
W03	判断	コンテキスト	ステップ 2 — /propose を呼び出す（SPEC .md）。.html のレンダリングは watchdog 付きの低コスト CLI にディスパッチ	SPEC .md＋.html	CLI が応答しない → B03
W04	効果	SPEC	ステップ 3 — orca orchestration gate-create を実行し、ユーザーを待つ。承認／却下された T-id を記録	承認	却下 → cancelled
W05	判断	承認済み SPEC	ステップ 4 — /plan を呼び出して PLAN を作成。### Task ごとに、仕様を固定して task-create を実行	task task_xxxx	R7 で PLAN がブロック → PLAN を修正
W06	判断	task	ステップ 4b — ゲート 1 で HITL／AFK を判定し、ゲート 2 で作業タイプから archetype を選択してから、コスト表を確認	タイプと CLI を設定した AFK task	HITL → B02
W07	効果	AFK task	ステップ 5 — orca orchestration dispatch --task <id> --to <agent> --inject を実行（brief は原文のまま、1 行目で作業タイプを宣言）。T-id を dispatched にする	worker を実行	—
W08	決定的	dispatch	ステップ 6 — orca orchestration check --wait --types worker_done --timeout-ms 300000 を実行	worker_done	タイムアウト／応答なし → B03
W09	決定的	diff	ステップ 7 — verify-before-commit を実行（qc-regression.py --run を含む）	クリーンな commit	エラー → 修正
W10	効果	結果	出力レポート＋agent の Status を更新＋skill の同期 push（Delivery 項目）	draft＋index＋log	artifact が 0 件 → スキップ

各ステップの詳細（W01～W09 の信頼できる情報源）： 0. R12 (B) — 作業前にワークスペース全体をスイープ（1回のみ、作業開始／マルチエージェントへのファンアウト前）：オーケストレーターが harness/poc-vendor-neutral/bin/pull-gate-sweep.sh を実行します。すべてのサブリポジトリをスキャンし（.harness-workspace.yaml から取得。存在しない場合は harness が設定されたリポジトリを自動検出）、並列で fetch します。リモート更新後にサブリポジトリが TARGET になった場合は停止し、そのリポジトリ内で git pull --rebase を実行してからディスパッチします（全エージェントが最新の共通ベースを使用します）。watch サブリポジトリは警告のみです。リポジトリが1つの場合、スイープは自動的に pull-gate.sh に縮退します。オフラインの場合は fail-open です。編集ごとのブロックはしません（per-edit PreToolUse は意図的に省略しています）。R12 (C) リポジトリごとの gate2：install-harness.sh --all-subrepos ですべてのサブリポジトリにインストールします。手動チェックは pull-gate.sh gate2 です。

1. query：機能のコンテキストを wiki/ から統合するため、skill query を呼び出します（Skill tool → query、または /query）。断片的に手動で読まず、正しい wiki-loop の query を使います（[[wikilinks]] を統合し、既知の内容と不足点を返します）。プロジェクトに wiki/ がない場合（または query が空を返した場合）は、「前例なし」と記録してステップ2に進みます。
2. propose — 説明を繰り返すのではなく、skill propose を呼び出します（Skill tool → /propose。ステップ1で query を呼ぶのと同じパターンです）。R7 のすべての要件（.md+.html のペア、## Plan、## Agent Task Assignment、glass-style docs-site-macos、詳細な文章）は子 skill にあります。propose の動作を変更する場合は、llmwiki/skills/dev-loop/propose.md だけを修正し、ここは変更しないでください（single source of truth。[[ADR-003-skill-as-single-source-of-truth]] を参照）。
   • Claude が考え、安価な CLI がレンダリング：Claude（/propose 経由）が作成するのは SUBSTANCE のみです。つまり、レンダリング可能な .md（Plan、文章、## Render brief ＝データ形式の図の手順、および各タスクの文章）です。.html は ## Render brief の機械的な RENDER なので、コスト表に従って 安価な CLI にディスパッチします（OpenCode big-pickle → agy → kiro、$0）。レンダリングは無料なので、docs-site-macos のリッチな Full 形式を使い、省略しないでください。Claude のトークンは substance にのみ使われ、HTML のリッチさに応じて膨らむことはありません。
   • ウォッチドッグ + R7 gate（250626 の教訓 — headless への引き渡しで約1/5しか完了しない）：約60～90秒待ちます。応答がない／ファイルが生成されない／diagram-box が欠けている場合は、停止して Claude によるレンダリングへフォールバックします。安価な CLI を利用可能な順に試します（--version で probe）。候補が尽きたら Claude を使います。R7 は write+commit 時にもブロックするため、誰がレンダリングしても品質が保たれます。
3. gate：orca orchestration gate-create --question "この提案を承認しますか？" を実行し、ユーザーの応答を待ちます（html のプレビュー URL を添えて送信します）。
   • ライフサイクルの支柱3（ベストエフォート、fail-open）：ユーザーが承認したら python3 harness/scripts/code-logger.py --task set <T-id> state=approved note="gate" を実行します（<T-id> は /propose が発行した draft の frontmatter にある task: フィールドです。空欄なら省略します）。ユーザーが拒否したら --task set <T-id> state=rejected を実行します。コマンドは fail-open で、フローをブロックしません。
4. 承認後 — 分解の前に skill plan を呼び出します（Skill tool → /plan）。 /propose が生成するのは SPEC（人が承認のために読むもの）です。/plan はそれを llmwiki/wiki/sources/draft/DDMMYY-<名前>-PLAN.md に展開します。これは機械が実行するために読みます。各 ### Task には **Files:**（正確なパス）、**Interfaces:**（Consumes/Produces — 隣接タスク向けのシグネチャ）、および実際のコード・コマンド・期待する出力を含む、TDD 形式の2～5分の手順が必要です。PLAN 分岐では、これらが欠けていると R7 がブロックします。その後で各 ### Task に対して orca orchestration task-create を実行します — spec にはプロジェクトのスタンプを付ける必要があります： orca orchestration task-create --spec "$(python3 harness/scripts/orca-reconcile.py --stamp '<spec>')". Orca のタスク台帳は ランタイム全体で共通です（Orca のガイドにも明記されています）。2026-07-20 の計測では、複数プロジェクトの18個の terminal が同じ台帳に書き込んでいました。そのため、repo A での task-list に repo B のタスクも表示され、オーケストレーターが別プロジェクトのタスクを誤って claim する可能性があります。これは物理層での分離という目的を損ないます。Orca にはプロジェクトフィールドがなく（task-create にタグがなく、task-list にフィルターもありません）、正確に所属を特定する唯一の方法がこのスタンプです。タスクを作成した terminal が終了した後も有効です（実測では、以前の terminal 17個のうち稼働中のものは0個でした）。照合には orca-reconcile.py [--scope current|all] を使います。
   • 「推奨」ではなく必須である理由：安価な CLI エージェントは headless で動作し、このセッションのコンテキストを一切引き継ぎません。また、聞き返すこともできません。与えられたものだけで作業し、曖昧な点があると推測して黙ったまま進めます。brief が薄いことこそが、実測で「引き渡しの完了率が約1/5」という結果になった原因（250626 の教訓）であり、モデルの能力不足ではありません。
   • PLAN に .html は不要です。HTML は SPEC（承認時に人が見るもの）に紐づき、/propose が生成します。エージェントに図を読ませるのは、無駄なトークン消費です。 4b. 作業の種類に応じた正しい割り当て — CLI を選ぶ前にゲートを通します。 下記のコスト表が答えるのは「どのモデルが最も安いか」だけです。「この作業は人間なしでできるか」は問われていません。これが完了率約1/5の原因として残っていた要素です。2つのゲートを、次の順序で通します。
   • ゲート1 — HITL/AFK。生身の人の回答が必要なタスク（設計上の決定、トレードオフ、ユーザーにしか分からないこと、外部へのアクセス、手動チェック）は HITL です。台帳では ready-for-human とラベル付けし、headless CLI にディスパッチしてはいけません。先に進めるのは AFK タスク（ready-for-agent）だけです。絶対ルール：HITL タスクを割り当てられたエージェントに残された選択肢は、ユーザーの代わりに推測して黙ることだけです。それが完了率1/5の原因であり、モデルの能力不足ではありません。
   • ゲート2 — 作業の種類 → archetype。タスクの種類を割り当てます：research（事実を掘り出す）· prototype（反応を見るための粗い版）· grilling（一問ずつ尋ねる）· build（brief に従って実行する）· sweep（機械的な整理）。archetype（ADR-015）にマッピングし、persona preamble を設定します。その後で初めて、コスト表から CLI を選びます。コスト表は最後のステップであり、最初ではありません。
5. dispatch：orca orchestration dispatch --task <id> --to <agent> --inject
   • --inject は、そのタスクの PLAN にある brief（Files + Interfaces + Steps）を、PLAN の ## Global constraints とともにそのまま注入します。要約し直してはいけません。要約こそがコンテキストが抜け落ちる場所であり、抜け落ちるのは常にエージェントが必要とする情報です。
   • brief の冒頭には作業の種類を明記します：このセッションがどのようなものかを、1文で率直に述べます。「あなたは決定事項を解決するのであり、実装を行うのではありません」／「あなたは機械的な整理を行っており、機能を追加してはいけません」。作業の種類はモデルを選ぶだけでなく、セッションの形を決めます。自分が何をしているかを理解しているエージェントは、説明の塊だけを渡されたエージェントとはまったく異なる行動を取ります。
   • ライフサイクルの支柱3（ベストエフォート）：タスクを割り当てたら python3 harness/scripts/code-logger.py --task set <T-id> state=dispatched note="<agent>" を実行します。これは永続的な T-id（不変の監査証跡）であり、orca orchestration の一時的な task_xxxx とは独立しています。fail-open です。
   • archetype に基づくペルソナ（Boris Cherny — ライフサイクル上の5つの役割）：特定の posture でディスパッチしたい場合は、キーワードで呼び出します — /proto /build /sweep /grow /maintain。仕組み： python3 harness/scripts/archetype.py --get /<kw> → (a) その archetype に推奨される CLI （Prototyper→安価な opencode · Builder/Grower/Maintainer→Claude · Sweeper→opencode）と、(b) ペルソナ PREAMBLE（llmwiki/personas/<archetype>.md）を出力します。ディスパッチ前に、その preamble を <task> に注入し、agy/opencode/kiro が適切な役割を担えるようにします（例：Sweeper は機能の追加を禁じられています）。各 CLI がどの archetype に適しているかは、harness/archetypes.config.yaml の verified:false アダプターで定義されています。ADR-015 を参照してください。
6. 待機：orca orchestration check --wait --types worker_done --timeout-ms 300000 6b. （任意）コミット前のシニア QC — 確定前にシニアの目で差分を確認したい場合は、/qc-code（Skill tool → qc-code）を呼び出します。4項目（security/performance/naming/logic）をレビューしてスコアと判定を出し、各ロジックバグを再現する qc-* テストも生成します。判定が修正必須なら、コミット前に修正します。任意であり、必須ではありません — LLM の判定は助言であり（最終判断は人が行います）、強制されるのはステップ7で実行される qc-* テストです。
7. 検証：コミットの前に verify-before-commit が自動実行されます（ステップ3bを含みます。qc-regression.py --run が確定的な qc-* テストを実行するため、再現済みのバグがいつの間にか再発することはありません）。

分岐

ID	種類	条件	動作	スキップ／失敗	再合流
B01	conditional_required	入力が不具合（bug、ランタイムエラー、regression、「昨日は動いていた」）である	propose する代わりに skill orca-issue を呼び出す	深刻な不具合で fan-out が必要な場合 → orca-issue が W07 へエスカレーションし、2 つのハードゲートを維持する	終了（またはエスカレーション時は W07）
B02	conditional_required	人間の回答が必要なタスク（HITL）である	ledger に ready-for-human ラベルを付け、ヘッドレス CLI には dispatch しない	—	人間を待ってから W06
B03	recovery	ヘッドレス CLI が約 60〜90 秒間応答しない／ファイルを作成しない／diagram-box が不足している	kill して Claude が spec に従って引き継ぐ。利用可能な順に、次に低コストの CLI を試す（--version を probe）	CLI を使い切ったら → Claude	実行中のステップ（W03/W08）
B04	user_optional	確定前に diff を確認したい	ステップ 6b — /qc-code（判定は参考扱い＋テスト qc-*）	判定が修正必要 → commit 前に修正	W09
B05	user_optional	posture（/proto /build /sweep /grow /maintain）に応じて dispatch したい	python3 harness/scripts/archetype.py --get /<kw> → 推奨 CLI ＋ persona の PREAMBLE を <task> に注入	—	W07
B06	conditional_required	docker を操作しようとしている（--force-recreate、down、recreate）	docker inspect で mounts を確認し、compose と比較する。不一致 → 停止して user に確認	バックアップと確認がない場合 → volume を変更しない	実行中のステップ
B07	capability_optional	AGENTMEMORY_TOKEN がある	セッション開始時に検索／decision の後とセッション終了時に記憶（Reference — AgentMemory）	ない場合 → スキップ	W02 / W10

不具合分岐の詳細（原文）：

分岐：不具合 ≠ 機能

入力が不具合（bug、ランタイムエラー、regression、「昨日は動いていた」）である場合 → propose する代わりに skill orca-issue を呼び出す：専用の triage → repro-first gate（再現するまでは修正不可）→ red→green の fix → 二重の distill。不具合が深刻で fan-out が必要な場合、orca-issue はここへエスカレーションして dispatch しますが、その 2 つのハードゲートは維持されます。

検証と停止

人間のゲート：W04 の gate（SPEC の承認）と、W06 の Gate 1 HITL。マシンのゲート：R7 が write と commit の際に項目の不足した SPEC/PLAN をブロックします。各 commit の前に verify-before-commit と qc-regression.py --run を実行します。CLI watchdog は約 60〜90 秒（B03）、check --wait の timeout は 300000 ms です。プロジェクトごとのタスク照合：orca-reconcile.py [--scope current|all]。

例

• 成功例：「レポート用の CSV export を提案して」→ クリーンな sweep → /query で関連ページを 2 つ取得 → /propose で SPEC を生成し、.html を opencode run -m opencode/big-pickle で render → user が gate を承認 → /plan で 3 task の DDMMYY-export-csv-PLAN.md を生成 → task-create に stamp を付与 → AFK の 2 task を build で --inject dispatch、HITL の 1 task（「日付形式を選択」）に ready-for-human を付与 → worker_done → verify-before-commit が成功 → レポートを出力。
• 境界／失敗例：「昨日はログインできたのに、今日は 500」→ B01：propose せず、orca-issue を呼び出す（repro-first）。
• 境界例：opencode run による .html の render が 90 秒間無応答で、ファイルも作成されない → B03：kill して Claude に render をフォールバックさせる。R7 は引き続き write 時の品質を監視します。

Reference — オーケストレーション CLI の落とし穴（教訓 230626）

• task-create --json の 2 つの id：response には envelope の id（uuid）と result.task.id（task_xxxx）が含まれます。後続のすべてのコマンド（gate-create --task、dispatch --task、task-update --id）では result.task.id を使用する必要があり、envelope の id は使用しません。誤った id を使うと、gate は作成／解決されますが、存在しない task を参照し、実際の task は ready のまま停止します。
• task-update --status で有効なステータス：ready | in_progress | completed | failed。done はありません — done を渡すと、明確なエラーを表示せずに ok:false が返されます。
• 実際の id を確実に取得する方法：orca orchestration task-list --json を実行し、spec によって照合します。

Reference — コンテナ／DB の安全性（docker を操作する前に必須）

コンテナを操作する前に（docker compose / docker run）

# BẮT BUỘC chạy trước bất kỳ --force-recreate, down, recreate nào:
docker inspect <container_name> --format '{{json .Mounts}}' | python3 -m json.tool

使用する compose ファイル内の Source パスとボリュームを比較してください。異なる場合は → 停止して、ユーザーに確認してください。

Cozyroom の本番 DB： /mnt/c/Users/olive/orca/workspaces/home-spotify/m/data/metadata.db バックアップとユーザーの確認なしに、ボリュームのマウントを変更してはいけません。

2026-05-29 の教訓：誤ったパスを指定した compose でコンテナを再作成した結果、ユーザーの DB がすべて失われました。

参照 — クイックディスパッチ

⚠️ ヘッドレス CLI エージェントは信頼できません（250626 の教訓 — orca-eval）： Claude Code からバックグラウンドで実行した opencode run / agy -p / kiro run は、通常成果物を納品しません（プロセスが終了／ハングし、ファイルが作成されません。実測で 5 件中 1 件のタスクのみ成功）。ルール：ウォッチドッグを設定し（約 60～90 秒）、応答がない／ファイルがない場合は → 終了させ、Claude が仕様に沿って引き継ぐ（無駄に待たない）。検証済みの独立した定型タスクには OpenCode を使用します。依存関係や微妙な判断が必要なタスクは Claude が担当します。エージェントに実際にディスパッチするには、-p / run ではなく、orca terminal の対話モードを優先してください。

# OpenCode non-interactive (DEFAULT — dùng big-pickle miễn phí):
# ⚠ KHÔNG dùng --dangerously-skip-permissions khi dispatch từ Claude Code — auto-mode classifier sẽ DENY (bài học 120626)
opencode run -m opencode/big-pickle --dir "<project>" "<task>"

# Antigravity non-interactive:
agy -p "<task>"

# Kiro non-interactive:
kiro run --dir "<project>" "<task>"

# GitHub Copilot Coding Agent (async — via GitHub issue):
gh issue create --title "<task>" --body "<task details>" --assignee "@me"
# Then: gh copilot suggest "<task>" or trigger via VS Code Copilot Chat

# Nếu dùng Orca terminal (interactive):
orca terminal list
orca terminal create --worktree active --title "OpenCode" --command "opencode"
orca terminal send --title "OpenCode" --text "<task>"
orca terminal wait --for tui-idle && orca terminal read --title "OpenCode"

参照 — コストに応じたタスクの割り当て

タスク	エージェント	モデル
検索、grep、一覧表示、読み取り	OpenCode	opencode/big-pickle ($0)
定型コード、CRUD の作成	OpenCode	opencode/big-pickle ($0)
Wiki の取り込み／lint	OpenCode	opencode/big-pickle ($0)
差分のレビュー、説明	agy	default
アーキテクチャ上の判断	Claude Code	Opus 5 (claude-opus-5) — /orca-dispatch-reference の Claude chain を参照
難しいエラーのデバッグ	Claude Code	デフォルトは Sonnet 5 (claude-sonnet-5)、行き詰まったら Opus 5 に切り替え
フロントエンド UI の定型コード	Kiro	default
複数ファイルのリファクタリング	Kiro	default
PR のレビューと修正案の提示	Copilot	gpt-4o (GitHub)

参照 — エージェントのバイナリ

エージェント	バイナリ	確認
Antigravity	agy	agy --version
OpenCode	opencode run -m opencode/big-pickle	opencode --version
Kiro	kiro run	kiro --version
GitHub Copilot	gh copilot suggest	gh copilot --version
Orca	GUI のみ — orca terminal * コマンド経由で使用	orca terminal list

参照 — Antigravity のディスパッチ状況（2026-05-21 にテスト、2026-05-23 に更新）

バイナリ：agy — %LOCALAPPDATA%\agy\bin\agy.exe。antigravity ではなく、~/.local/bin/agy（Linux）でもありません。

ターミナルの作成：

orca terminal create --worktree active --title "Antigravity" --command "agy"

フック：Orca v1.4.21 で Windows フックの引用符の問題を修正済み — antigravity-hook.cmd の手動編集は不要です。

OpenCode：opencode — %APPDATA%\npm\opencode.cmd に npm グローバルとしてインストールされています。

ディスパッチの状況：

手順	状態
dispatch --inject	v1.4.21 以降でテスト — 失敗した場合は terminal send を使用
手動の terminal send	OK
Antigravity によるファイルの読み取り／コマンドの実行	OK
worker_done の inbox への到着	再テストが必要

参照 — エージェント CLI ごとの Slash Skill のインストール

ディスパッチを受けたエージェントは、作業を始める前に llmwiki/skills/ から自分でスキルをインストールしてください。

Claude Code CLI

mkdir -p .claude/commands/
cp llmwiki/skills/<loop>/<name>.md .claude/commands/<name>.md
# User-level:
mkdir -p ~/.claude/commands/
cp llmwiki/skills/<loop>/<name>.md ~/.claude/commands/<name>.md

OpenCode CLI

mkdir -p ~/.agents/skills/<name>/
cp llmwiki/skills/<loop>/<name>.md ~/.agents/skills/<name>/SKILL.md
# Restart OpenCode để discover skill mới.

Antigravity CLI

mkdir -p ~/.agents/skills/<name>/
cp llmwiki/skills/<loop>/<name>.md ~/.agents/skills/<name>/SKILL.md

Kiro CLI

mkdir -p ~/.kiro/skills/<name>/
cp llmwiki/skills/<loop>/<name>.md ~/.kiro/skills/<name>/SKILL.md

GitHub Copilot

# Workspace-level steering via .github/copilot-instructions.md
# Skills injected as context file:
mkdir -p .github/
cat llmwiki/skills/<loop>/<name>.md >> .github/copilot-instructions.md
# Or per-skill steering file (Copilot Workspace):
mkdir -p .github/skills/
cp llmwiki/skills/<loop>/<name>.md .github/skills/<name>.md

すべてのエージェントに適用するルール

• スキルファイルのみをコピーしてください — README.md、index.md、log.md は除外します。
• ファイルごとにコピーしてください — cp -R は使用しないでください。
• 配置先：.claude/commands/（Claude Code）；~/.agents/skills/（OpenCode/agy）；~/.kiro/skills/（Kiro）；.github/（Copilot）。
• インストール後、以下を報告してください：

  | Agent       | Skill   | Installed at                            |
  |-------------|---------|------------------------------------------|
  | claude-cli  | propose | .claude/commands/propose.md              |
  | opencode    | propose | ~/.agents/skills/propose/SKILL.md        |
  | antigravity | propose | ~/.agents/skills/propose/SKILL.md        |
  | kiro        | propose | ~/.kiro/skills/propose/SKILL.md          |
  | copilot     | propose | .github/skills/propose.md                |
  

参照 — AgentMemory — セッションをまたいで保持するメモリー

https://agentmemory.giatbh.io.vn/ のサービス — セッション間でコンテキストを保存します。

BASE="https://agentmemory.giatbh.io.vn"
TOKEN="${AGENTMEMORY_TOKEN}"

# Health check
curl -sk -H "Authorization: Bearer $TOKEN" "$BASE/agentmemory/health"

# Ghi memory (cuối session hoặc sau quyết định quan trọng)
curl -sk -X POST "$BASE/agentmemory/remember" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"content":"<nội dung>","category":"fact|preference|decision|context"}'

# Tìm kiếm (đầu session hoặc trước khi propose)
curl -sk -H "Authorization: Bearer $TOKEN" \
  "$BASE/agentmemory/search?query=<từ+khóa>"

使用タイミング：

• セッションの開始時：作業を始める前にコンテキストを検索します
• 判断の後：アプローチとその理由を保存します
• セッションの終了時：完了したタスク、コミット、現在の状態を保存します

参照 — 主なコマンド

orca orchestration run --spec "Propose: <tính năng>. Query wiki, tạo draft, gate chờ duyệt."

ディスパッチの詳細：llmwiki/skills/orchestrate/orca-dispatch-reference.md

---

納品 — 出力レポート（実装完了後）

これは実装後の結果レポートであり、計画の提案ではありません。 計画の提案は、作業を始める前にステップ 2 で作成してください。

すべての実装タスクが完了したら、出力レポートを Wiki に書き込みます。

手順

1. ファイル名を作成する：

• 形式：DDMMYY-<ten>.md
• DDMMYY = 今日の日付（例：2026 年 6 月 2 日の場合は 020626）
• <ten> = 実施内容を要約する 2～4 個のケバブケースの単語（例：landing-page-coteccons、brand-kit-fintech、ingest-auth-spec）

2. llmwiki/wiki/draft/orca/DDMMYY-<ten>.md に書き込む：

---
type: draft
title: "DDMMYY-<ten>"
status: proposed
tags: [<skill-name>, output-report]
timestamp: YYYY-MM-DD
---

# DDMMYY-<ten>
**Type:** draft
**Status:** proposed
**Tags:** <skill-name>, output-report
**Proposed:** YYYY-MM-DD

## Agent Task Assignment
| Task | Agent | Status |
|------|-------|--------|
| <mô tả task 1> | <tên agent> | pending / in-progress / done |
| <mô tả task 2> | <tên agent> | pending / in-progress / done |

## What
<One sentence — what this skill invocation produced or decided>

## Output
<Key artefacts, files created/modified, or decisions made>

## Files
| File | Action |
|------|--------|
| `path/to/file` | created / modified |

## Notes
- Invoked via: `/<skill-name>` skill

## Origin
- **Draft:** `wiki/draft/orca/DDMMYY-<ten>.md`
- **Commit:** _(filled by verify-before-commit)_
- **Date promoted:** _(filled by verify-before-commit)_

3. Wiki のインデックスとログを更新する：

• llmwiki/wiki/index.md — 次の行を 1 行追加します：| [DDMMYY-<ten>](draft/orca/DDMMYY-<ten>.md) | draft | YYYY-MM-DD |
• llmwiki/wiki/log.md — 次の行を追加します：## YYYY-MM-DD — <skill-name> — <ten>

4. エージェントのステータスを更新して同期プッシュする — 必須、省略不可：

• llmwiki/wiki/draft/orca/DDMMYY-<ten>.md を再度開きます
• ## Agent Task Assignment の表にある Status 列を、各エージェントの実際の状態に合わせて更新します（pending → in-progress → done）
• rheinmir/setup の orca ブランチをクローンし、変更したスキルファイルをコピーして、プッシュバックします：

  git clone [email protected]:rheinmir/setup.git /tmp/rheinmir-setup-sync -b orca --depth 1
  cp /path/to/skill.md /tmp/rheinmir-setup-sync/skills/<skill-name>/SKILL.md
  cd /tmp/rheinmir-setup-sync
  git add .
  git commit -m "skill: sync update — DDMMYY-<ten>"
  git push origin orca
  rm -rf /tmp/rheinmir-setup-sync
  

スキルが成果物も判断も生み出さない場合に限り、省略できます。