repo-orchestration について
現状のアーキテクチャ資料に基づき、目標状態と実装を計画するスキルです。根拠に基づく ADR、設計書、個別に検証可能なタスクを作成しますが、計画は実行しません。
主な機能
- 01現状資料に基づく目標状態の設計
- 02選択肢と判断を記録する ADR
- 03設計書の作成
- 04個別に検証できるタスクへの分解
- 05依存関係とトポロジカル順序の確認
活用シーン
- 01目標システムアーキテクチャの計画
- 02議論のある設計判断の記録
- 03実装目標のタスク分解
- 04タスク計画の依存関係確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ objectivlabs/ reposkillopt --skill repo-orchestrationインストール後、Claude Code で/repo-orchestrationを入力して読み込まれたか確認します。
同梱ファイルCHANGELOG.md
詳細
RepoSkillOpt — To-Be 設計と実装オーケストレーション(標準スキル)
目的
このスキルは、現状の成果物(アーキテクチャビュー+変更影響分析)と明示された 目標を入力として、(a)現状のエビデンスに基づいたレビュー可能な目標状態の設計(ADR+簡潔な設計ドキュメント)と、(b)実装オーケストレーション計画を作成します。後者は、依存関係を明示し、トポロジカル順序で並べた、小さく独立した個別に受け入れテスト可能なサブタスクに分解された、機械可読なタスク台帳です。この計画は実行者ではなく成果物です。どのオーケストレーターでも実行できます。このスキルが実装を実行することはありません。ベンダー中立で、特定のコーディングエージェントランタイムには依存しません。
発動条件
ユーザーが目標状態/To-Be を設計する、作業を計画する/タスクに分解する、または目標 X の実装計画を作成するよう求めた場合、あるいはそれに相当する依頼があった場合に発動します。無関係な依頼では発動せず、作成した計画も実行しません。
前提条件
現状の成果物(アーキテクチャビュー、変更影響分析)と明示された目標が必要です。現状の情報がない場合は、まず現状アーキテクチャスキルを使うようユーザーに案内してください。根拠のないシステム像を前提に設計してはいけません。
運用原則
- 設計を現状に基づかせる。 設計上の主張はすべて現状のエビデンスまでたどれるようにします(引用された現状の成果物を介した
file:line)。推論には**[inference]**、不明点には**[unknown]**を付けます。 - 明示的に決定する。 意見が分かれる選択肢は、2 つ以上の選択肢を比較検討する ADR にします。暗黙のデフォルトは設けません。
- 計画を立て、実行しない。 タスク台帳は持ち運び可能な成果物です。このスキルはそれを作成した時点で終了します。
- 独立した受け入れテスト可能なタスクにする。 各サブタスクは、依存関係を明記したうえで、単独で実行し、レビュー担当者が検証できる大きさにします。タスクが個別に受け入れテストできない場合は分割します。
- リポジトリに関する事実はリポジトリ内に限定する。 汎用化の候補となるパターンのみを集約対象とします。
ワークフロー
(a) 現状の成果物と目標を読む。 制約と影響範囲を特定します。
(b) ADR(.reposkillopt/decisions/ADR-NNN-<slug>.md、templates/adr.md に準拠):1 件につき 1 つの決定を記載します。Context、検討した選択肢(2 つ以上、それぞれの長所と短所)、Decision、Consequences を含めます。目標が現状の制約と矛盾する場合は、覆い隠さず、トレードオフとして ADR に記録します。
(c) 設計ドキュメント(.reposkillopt/design/design-doc.md、templates/design-doc.md に準拠):目標、目標状態の概要、現状との対応関係(各変更が影響する現在のコンポーネント/フローにひも付け、引用を記載)、リスクとトレードオフ(該当する ADR へのリンク)、対象外事項を記載します。
(d) タスク台帳(.reposkillopt/plan/task-ledger.md、templates/task-ledger.md に準拠):作業を id | goal | acceptance | depends_on の表にまとめます。各タスクは独立して個別に受け入れテスト可能であり、依存関係が明記されている必要があります。依存関係グラフは非巡回とし、フロントマターの topological_order には、すべての ID を記載し、各依存先をその依存元より前に置きます。
(e) 決定論的ゲート。 成果物は決定論的チェック(check_adr、check_task_ledger)に合格しなければなりません。各 ADR に選択肢が 2 つ以上あること、すべてのタスクに目標と受け入れ条件があること、依存先が存在すること、グラフが非巡回であること、トポロジカル順序が有効であることを確認します。
出力規律
現状スキルと同じ R10 ラベルおよび引用形式を使用します。設計上の主張には、根拠となる現状の成果物を引用します。単純な言い換えにはラベルは不要です。
人によるフィードバックループ
決定またはタスク分解に対する修正は、.reposkillopt/feedback/ 内に フィードバック項目(templates/human-feedback.md)として記録し、その内容を成果物に直接反映します。
スキル収束ループ
繰り返し寄せられる 汎用化候補 のフィードバック(関連項目が3件以上)は、スキル編集提案
(templates/skill-edit-proposal.md)になります。提案が受け入れられるのは、検証ゲート
(rubric/validation-gate.md)を通過した後に限られます。具体的には、重複のない保留データセットに対してアーティファクトを再生成し、評価軸ごとのルーブリックの後退がなく(rubric/tobe-orchestration-rubric.md を参照)、決定論的チェックも引き続き合格する必要があります。暗黙の昇格はありません。受け入れ時にはバージョンと CHANGELOG が更新され、4つのアダプターにも反映されます。