Tailored Build ja - nguyenhx2/agent-harness-bootstrap GitHub Wiki

テーラードビルド

English · 日本語

spec-builder は契約で終わります。harness-bootstrap はコードベースから始まります。その間のステップでチームが決まり、ほとんどのエージェントキットにはこのステップがありません。

何に答えるのか

よくあるエージェントキットは全部を配ります。すべてのエージェント、百のスキル、すべてのルールとフックを、誰かがコードベースを読む前にインストールします。その代償は見た目以上です:

すべてに対して、毎セッションでコンテキストを払う。 どのファイルにも一致しないルールは、すべてのリクエストにかかる税です。
持ち主のいない席が生まれる。 誰も作業を振らないエージェントは、ルーティング表を読みにくくするだけの名前です。
助言が一般論になる。 どのリポジトリでも正しいガイダンスは、あなたのリポジトリで行動に移せるほど具体的であることはまれです。
何が荷重を支えているか見えない。 すべてが入っていると、誰も安全に何かを取り除けません。

網羅性が適合性と取り違えられています。お金を払う価値があるのは適合性だけです。

何が何を決めるか

編成は証拠から決まり、それ以外からは決まりません。契約が示す作るべきもの、コードベースの分析が見つけたもの、そしてあなたにしか出せない回答です。

flowchart LR
    C[/"コードベース分析"/]
    S[/"契約"/]
    A["あなたの回答"]
    B["編成とフラグ"]
    SE[/"席"/]
    RU[/"パス限定ルール"/]
    SK[/"スキル候補"/]

    C --> B
    S --> B
    A --> B
    B --> SE
    B --> RU
    B --> SK

    classDef mod fill:#5A189A,stroke:#240046,stroke-width:1px,color:#E0AAFF
    classDef hum fill:#1D3557,stroke:#0B1B2B,stroke-width:1px,color:#A8DADC
    classDef art fill:#495057,stroke:#212529,stroke-width:1px,color:#F8F9FA
    class B mod
    class A hum
    class C,S,SE,RU,SK art

何から決まるか	何を決めるか
実在するモジュール	モジュールごとに dev エージェントを一つ、実在するパスに限定して。モジュールがなければ席もない。
リポジトリの目的	コード、調査、戦略、ドキュメント、任意の組み合わせ。調査リポジトリには `researcher` と `checker`、ドキュメントリポジトリには `writer` と `checker` が付き、どちらにもテストスイートやコードレビューのゲートは付きません。
契約とあなたの回答	18 の席のどれを埋めるか。一回の実行でインストールされるのは 18席のうち3〜17席で、既定で全部が入ることはありません。
リポジトリ内のマニフェスト	どのスキルを提案するか。その候補からあなたが選びます。
実在するパス	どのルールをパス限定にするか。ルール本文の大半を既定のセッションの外に置けるのはこのためです。

数字は主張ではなく測定

最も軽い回答では 3 席 (ドキュメントや調査のリポジトリ) です。データベース、テスト、長期プロジェクトのあるコードリポジトリでは 17 席になります。

scripts/check_numbers.py はこの範囲を、エージェントを左右するフラグの全組み合わせについて スキャフォルダ自身の選択関数で計算します。実際の実行とずれることはありません。どのエージェントをフラグで左右するかを変えると、範囲を引用している箇所 (このページを含む) はすべて、直すまで失敗します。

発見と配線は別の問題

flowchart TD
    M[/"マニフェスト"/]
    P["候補を提案"]
    U{"あなたが選ぶ"}
    N["/new-skill"]
    W["/skill-wire で席へ"]
    G[/"グラフのノード"/]

    M --> P --> U
    U -->|"合うものがある"| W
    U -->|"合うものがない"| N --> W
    W --> G

    classDef det fill:#2D6A4F,stroke:#081C15,stroke-width:1px,color:#D8F3DC
    classDef mod fill:#5A189A,stroke:#240046,stroke-width:1px,color:#E0AAFF
    classDef hum fill:#1D3557,stroke:#0B1B2B,stroke-width:1px,color:#A8DADC
    classDef art fill:#495057,stroke:#212529,stroke-width:1px,color:#F8F9FA
    class P,N,W mod
    class U hum
    class M,G art

スキル発見 (Skill Discovery) - 読んだことのないカタログからは選べません。このプロジェクトのマニフェスト (Python、Ruby、.NET、Java と Kotlin、JavaScript、モノレポの目印) を読んでスタックを割り出し、それから提案します。マーケットプレイスは情報源であって権威ではありません。あなたが選ばない限り、何もインストールされません。
/new-skill - 繰り返し発生するワークフローに合うものがないとき、まずプロジェクトスキルに値するかを判断し (断るのも普通の結果です)、それからスキャフォールドして skill-check.py で検査します。
/skill-wire - インストール済みは到達可能と同じではありません。スキルを、それを使う席やコマンドに接続し、その接続を文書の慣習ではなくグラフのノードとして記録します。

配線がノードなので、harness-view はどのスキルが配線済みで、どれがディスクにあるだけかを示し、 assess はその差を所見として報告します。

検証できる

持ち主のいない席、誰も使えと言われていないスキル、どのファイルにも一致しないルールは、どれもコストです。harness-view assess は三つとも名指しします:

harness-view assess .

「テーラード」は誰でも README に書ける言葉です。18席のうち3〜17席、そしてモジュールのない席には所見が出る は、検証できることです。