vibe

Vibe のガバナンス対象ランタイムへのエントリー

このファイルは、ホスト側から canonical vibe に入るための SOP です。内容は簡潔に保ちます。ランタイムの詳細は protocols/runtime.md に、実行規律は protocols/do.md に、ホストラッパーのレシピはインストーラーで生成されるラッパーのドキュメントに記載します。

トリガー契約

ユーザーが $vibe、/vibe、または vibe スキルを明示的に呼び出した場合、あるいはホストが複雑なタスクについて要件・計画・実行の完了までをガバナンス対象として扱うことを意図的に選択した場合は、通常の実行に入る前に canonical vibe を起動します。

関連が曖昧なタスクをすべて vibe に振り分けないでください。軽量な質問、 単一コマンドの確認、または明示的に指定された別のスキルが適しているタスクは、 ユーザーがこのエントリを明示的に呼び出していない限り、vibe の外で進めてもかまいません。

インストール済みコピーの更新には、同じ管理対象ディレクトリで update --skills-dir <skills-dir> を使用します。

CLAUDE.md、GEMINI.md、AGENTS.md、および TDD の例外など、ワークフローに関する直接的な制限を含むユーザー指示が最優先です。これらの制限の範囲内で、canonical な起動規則と証明規則を維持してください。

canonical ブートストラップ

vibe はホストの構文に依存しないスキル契約です。canonical な起動の前に、起動に必要な最小限の作業だけを行います。

• skill_root と workspace_root を解決します。
• 現在のユーザータスクを、タスク仕様としてそのまま渡します。無関係なチャット履歴は除外してかまいません。要約、書き換え、キーワードへの縮約はしないでください。入力パス、入力の不変性に関する制約、正確な出力ルート、合成データの証拠境界、モジュール依存関係、安全な並列処理の境界、受け入れ基準をそのまま維持してください。

起動前に、現在のワークスペース、リポジトリ、またはインストールルート内で canonical の証明ファイルを検索しないでください。 canonical 起動が返る前に、リポジトリ、プロトコル文書、または以前の実行結果を調べないでください。 ステージをシミュレートしたり、このファイルやラッパーのテキストを読んだだけで canonical エントリーを行ったと主張したり、ラッパーや AGENTS のテキストを証明として扱ったりしないでください。 outputs/runtime/vibe-sessions/<run-id>/ を手動で作成しないでください。 Vibe のインストールルートを、ガバナンス対象の成果物ルートとして使用しないでください。

ローカルスキル候補の監査：意味上の所有者 packages/runtime-core/src/vgo_runtime/router_contract_runtime.py、互換ブリッジ scripts/router/resolve-pack-route.ps1

この監査は canonical vibe 内で実行され、確認用の候補を提示します。作業種別、ドメイン／テクノロジー、成果物、明示的な制約、継続時に検証済みの確定事項を含めます。出力は互換性の証拠に限られます。スキルの選択、バインド、ステージの進行は Agent が担います。

canonical エントリーコマンドの形式：

$env:PYTHONPATH = "<skill_root>/apps/vgo-cli/src"
py -3 -m vgo_cli.main canonical-entry --repo-root "<skill_root>" --artifact-root "<workspace_root>" --prompt "<current user task, verbatim>"

PowerShell では、$env:PYTHONPATH=... を二重引用符で囲んだ -Command 文字列の中に置かないでください。ホストによる補間で :PYTHONPATH に書き換えられるおそれがあります。

Claude Code を含む Bash 形式のホストでは、外側のシェルで PYTHONPATH を設定し、Python を直接呼び出します。利用可能なものに応じて、py -3、python、python3 の順に試してください。

REPO_ROOT='<skill_root>'
WORKSPACE_ROOT="${WORKSPACE_ROOT:-$PWD}"
PYTHONPATH="$REPO_ROOT/apps/vgo-cli/src" python -m vgo_cli.main canonical-entry --repo-root "$REPO_ROOT" --artifact-root "$WORKSPACE_ROOT" --prompt "<current user task, verbatim>"

--host-id と --entry-id は、ラッパーまたは旧式の自動化との互換性のためだけに残されています。通常の起動では省略してください。

canonical-entry が session_root を返した後に限り、canonical の証明成果物を検証してください。 check が証明するのは installed locally であることです。ランタイムの整合性と納品物の受け入れには、それぞれ別の証拠が必要です。 canonical 起動の証明は起動後に行い、返された session_root の下にある host-launch-receipt.json、runtime-input-packet.json、governance-capsule.json、stage-lineage.json が必要です。 local-agent-kernel にも同じ証明規則が適用されます。これらの真実を示す成果物を生成できない場合、ローカル作業用の足場は生成してかまいませんが、canonical verified として扱ってはいけません。 canonical 起動に失敗した場合、不足しているステージや証明成果物をシミュレートせず、具体的な失敗理由を添えて blocked と報告してください。

合意形成とタスクの進化

ユーザーとエージェントが目標、範囲、制約、成果物、関連する未確定事項、完了基準について合意するまで、deep_interview を使用します。そのタスク固有の要約を確認して要件を確定します。最初の確認事項は会話への入力として扱います。

合意内容は既存の TaskCard に記録します。承認された改訂を追記し、影響を受ける作業とチェックを更新します。入力と受け入れ条件が引き続き有効な場合に限り、結果を再利用します。合意した成果、範囲、リスク、または必要な人間の判断を変える決定は明示します。

ハードストップと再開

段階的なガバナンス下での停止ポイントは、requirement_doc、xl_plan、phase_cleanup です。

bounded_return_control.explicit_user_reentry_required = true の場合、現在のアシスタントターンを停止します。後続のユーザーメッセージで現在の境界への承認または改訂が示されるまで、再開用の認証情報を使用しないでください。

これは推奨事項ではなく、実行時の厳格な境界です。「完了するまで続行する」といった通常のホスト自律性ルールより優先されます。詳細な元の依頼も、確定済みの要件または計画への承認にはなりません。ハードストップ後は、同じアシスタントターン内で、ガバナンス下の再開手続きを経ずに同等の手作業を行ってはいけません。計画の作成、タスクの実行、手動の回避策の提供、最終成果物の提供も禁止されます。

再開時は、runtime-summary.json -> bounded_return_control.host_decision_contract を確認し、ユーザーの意図を推測したうえで、構造化されたホスト決定 JSON ファイルを作成します。同じ run_id、bounded_reentry_token、安定した workspace_root を使用します。

要件の停止ポイントでは、agent_skill_organization を agent_skill_organization_contract から直接作成します。それまでは preferred_payload は不完全です。失敗した再試行や実行時のソース確認を通じてスキーマを把握してはいけません。 ブートストラップ時と同じ REPO_ROOT と WORKSPACE_ROOT を使用します。

DECISION_JSON="$WORKSPACE_ROOT/.vibeskills/tmp/host-decision.json"
mkdir -p "$(dirname "$DECISION_JSON")"

cat > "$DECISION_JSON" <<'JSON'
{
  "decision_kind": "approval_response",
  "decision_action": "approve_requirement",
  "approval_decision": "approve",
  "agent_skill_organization": {
    "schema_version": "agent_skill_organization_v1", "derived_by": "agent", "workflow_level": "L",
    "modules": [{"module_id": "module-a", "goal": "...", "candidate_skill_ids": ["skill-a"], "depends_on": [], "execution_mode": "skill_assigned", "acceptance_criteria": [{"criterion_id": "module-a-result", "description": "The module result satisfies the frozen requirement.", "verification_mode": "automated"}]}],
    "selected_skills": [{"skill_id": "skill-a", "module_ids": ["module-a"], "responsibility": "...", "reason": "..."}],
    "uncovered_modules": [],
    "workflow_level_contract": {"L": "smallest complete organization", "XL": "bounded multi-lane organization"}
  }
}
JSON

PYTHONPATH="$REPO_ROOT/apps/vgo-cli/src" py -3 -m vgo_cli.main canonical-entry \
  --repo-root "$REPO_ROOT" \
  --artifact-root "$WORKSPACE_ROOT" \
  --prompt "<current user task, verbatim>" \
  --continue-from-run-id "<source_run_id>" \
  --bounded-reentry-token "<reentry_token>" \
  --host-decision-json-file "$DECISION_JSON"

後続のユーザーメッセージによる構造化された承認があれば、次の段階的な停止ポイントへ進みます。構造化された改訂には、空でない revision_delta を含める必要があります。改訂の場合、ユーザーに別途承認を求めずに、同じ限定された段階を再度確定します。

{
  "decision_kind": "approval_response",
  "decision_action": "revise_requirement",
  "approval_decision": "revise",
  "revision_delta": ["Use the revised dataset and agreed output scope."]
}

限定された範囲での承認または改訂は、提示された限定段階のアクション契約の範囲内にとどめる必要があります。

requirement_doc では、runtime-summary.json -> host_user_briefing を読み、host_user_briefing.rendered_text をユーザーへの返信の骨子として使用します。フィールドの順序は変えないでください。 この停止ポイントでは、エージェント主導のスキル検索ガイドに沿って説明します。タスクをモジュールに分割し、各モジュールについてローカルスキルを検索し、候補の SKILL.md を読み、L / XL の両方の計画を構成し、対応できないモジュールは正直に明示します。要件確定時に、候補リストの件数、選択されたスキルの順位、生のルーター順序を提示してはいけません。 各タスク固有のワークフローを説明し、その選択肢に応じたタスク固有の候補スキル名を挙げるまでは、ユーザーに L と XL のどちらを選ぶか尋ねないでください。名前を挙げるすべてのスキルには、まだ選択も使用もされていない候補であることを明記します。正式な選択は、要件承認後に作成されるエージェントの整理結果でのみ行います。 要件の承認後、エージェントは承認済みの作業をモジュールに分割し、各モジュールについて、宣言されているすべてのローカルスキルルートを検索して、保持する候補の各 SKILL.md を読み込む必要があります。ホストは xl_plan に入る前に、検証済みの結果を HostDecisionJson.agent_skill_organization に設定する必要があります。ルート出力は候補の監査証跡として残しても構いませんが、このフィールドへの設定には使用できません。選択した Skill が複数のモジュールを担当する場合は、モジュールごとに module_assignments エントリーを1つずつ含め、正確なモジュール ID、owner、support、verifier のいずれかの役割、モジュール固有の責任、具体的な書き込み範囲1つ、期待される出力、検証を記載します。役割の順序は実行順を示します。support は owner より先に実行され、その結果を owner に引き継ぎます。verifier は owner の後にのみ実行されます。owner の実行後に行うレビューや最小性チェックには、support ではなく verifier を使用する必要があります。agent_direct モジュールでは、モジュール独自の具体的な write_scope、expected_outputs、verification を宣言する必要があります。ランタイムはそれらを汎用的なモジュールラベルや目標の言い換えに置き換えてはなりません。タスクの作業範囲に、module-execution.json などの正規ランタイム成果物を含めてはなりません。代わりに、タスクが所有する安定した出力範囲を指定するか、読み取り専用の作業では no task-file writes と指定してください。モジュール、Skill、役割、依存関係、書き込み範囲、出力、検証、ワークフローレベルを変更する計画の改訂では、更新後の agent_skill_organization 全体を再提出する必要があります。revision_delta はテキストを記録するだけであり、凍結された構成を変更するものではありません。 保持する SKILL.md が直接格納されているディレクトリ名を、candidate_skill_ids と selected_skills[].skill_id の両方で正確な skill_id として使用してください。表示される Skill 名やフロントマターの name は説明用であり、実行時の識別子ではありません。ネストされた SKILL.md の場合は、そのファイルが格納されているディレクトリ自身の名前を使用します。失敗した再試行を経て識別子を把握するのではなく、提出前に候補パスから特定してください。 モジュールの受け入れ基準は、正規のモジュール結果への再入力前に満たせるものでなければなりません。正規の phase_cleanup は module-execution.json の受け入れ後にのみ、クリーンアップの受領記録、納品の受け入れ、完了を示す表現の使用許可を作成するため、受け入れ基準でそれらを要求してはなりません。通常のモジュールは、実際の成果物と通常のコマンドまたはテストの出力を基に検証してください。実行順、Skill の使用、ファイル範囲を証明するだけの目的で、タスク固有のハッシュ、受領記録、台帳、マトリクス、スキャン、証明ファイルを作成してはなりません。ユーザーまたはドメインの契約上その成果物が必要な場合に限り、追加の証拠成果物を要求してください。 計画の承認後は、凍結された agent_skill_organization を plan_execute とクリーンアップで再利用し、ユーザーが凍結された要件または計画を改訂しない限り、手続き的な Skill 選定を再実行したり、暗黙に Skill を追加したり、宣言済みの不足を置き換えたりしてはなりません。stage_order は依存関係の深さを記録するものであり、並列実行の許可を示すものではありません。依存関係の段階が同じ独立した単位であっても、L では一度に1単位ずつ順次実行するウェーブを出力します。XL では、依存関係の準備が整った単位を1つのウェーブに最大2つまで配置できます。書き込み範囲がネストしている場合や重複している場合は、必ず順次実行してください。

必要な計画確認の後は、単位ごとに通常の許可を求めず、依存関係の準備が整った作業を続行してください。節目となるタイミングで簡潔に進捗を報告してください。ユーザーが合意済みのタスクを改訂した場合は、その改訂を記録し、続行する前に影響を受ける作業のみを再計画してください。

統一ランタイム契約

正規の vibe は、1つのランタイム権限と、ユーザーに表示される要件／計画の窓口を1つだけ持ちます。固定の状態遷移は次のとおりです。

1. skeleton_check
2. deep_interview
3. requirement_doc
4. xl_plan
5. plan_execute
6. phase_cleanup

単純な作業では、これらのステージを簡略化できますが、暗黙のうちにスキップすることはできません。完全なランタイム契約、ステージの所有権、リネージュのルール、内部の M／L／XL グレード、ユーザーに表示される L／XL ワークフローの確認、クリーンアップのルール、および出力一覧は protocols/runtime.md で定義されています。

vibe は唯一の公開ラッパーエントリです。インストール済みコピーの更新には、上記で説明したコマンドパスを使用します。

互換性維持のためのステージラッパーは、引き続き内部専用です。古い呼び出し元がそれを送信した場合は、ランタイムの起動前に正規の vibe に集約し、ホストから見えるスキルの一覧には表示しないでください。

スキルの実行

凍結された agent_skill_organization が、タスクスキルに関する唯一の正となります。計画の承認前に、モジュール、候補、選択したスキルとその理由、不足事項、および L／XL の違いを明示してください。

確認済みの各モジュールを、検証可能な作業単位として構成します。宣言されたスキルの出力を所有権の特定に使用し、plan_hints で作業手順を組み立て、verify_hints でモジュールのチェックを拡張します。明示されたモジュール間の依存関係を維持し、適切なスキルがないモジュールでは agent_direct を表示上のフォールバックとして保持してください。各作業単位には、意図した出力、チェック、紐付けの理由、および依存関係のリンクを、既存の WorkPlan に保持する必要があります。紐付けられた各割り当てでは、それらのフィールドと選択したスキルのガイダンスを、既存の ModuleAssignments アーティファクトに反映する必要があります。

選択されたスキルのみが、モジュールに紐付けられた実行単位になります。ホストはスキルを捏造したり、ルート候補を昇格させたり、スキルセッションを隠したり、別の要件／計画／ランタイムの窓口を開いたりしてはなりません。選択、読み込み、計画、ディスパッチ、または汎用マニフェストは、貢献の証明にはなりません。完了には、観測可能なモジュールの結果と protocols/runtime.md で定義されたモジュールの受け入れが必要です。計画の承認後は、module-work-plan.json が唯一のディスパッチ権限となります。agent-execution-handoff.json.result_contract は module_execution_v1 の提出バインディングを固定します。ハンドオフ後は result_contract.submission_template をコピーし、固定されたすべてのバインディングを維持して、結果フィールドのみを記入してください。criterion_results の状態は、passing、failing、blocked のいずれかでなければなりません。クリーンアップ前に正規プロセスがフォーマットを拒否した場合は、同じ module-execution.json を修正し、別のハンドオフを作成せずに同じ返却コマンドを再利用してください。コードタスクの TDD エビデンスは、ハンドオフテンプレートに tdd_evidence が含まれる場合、同じ module-execution.json に記載します。正規プロセスに返却する前に、その構造化セクションを記入し、別個の tdd-evidence.json サイドカーは作成しないでください。契約は実行エビデンスではありません。 Agent は引き続き実作業を行い、module-execution.json を作成します。失敗、ブロック、エビデンスの欠落、または人によるレビュー待ちが必要な場合、タスクの完了はブロックされます。

XL の委任では、ルート／子の階層が引き続き適用されます。正規の要件／計画を固定したり、最終的な完了を主張したりできるのは、root_governed のみです。child_governed レーンは固定されたコンテキストを継承し、割り当てられた書き込み範囲内にとどまり、delegation-envelope.json を検証して、ローカルの受領記録のみを出力します。

品質ルール

証拠なしに成功を主張しないでください。最低限、次の不変条件を守ってください。

• 完了前に検証してください。
• 回帰がないと根拠なく主張しないでください。
• 要件と計画の成果物を、実行したランまで追跡可能な状態にしてください。
• フェーズの完了を主張する前に、クリーンアップの記録を出力してください。
• 失敗、フォールバック、劣化状態、またはブロック状態を明示してください。
• 成功を装う処理、エラーの握りつぶし、テンプレートだけの合格結果を追加しないでください。
• スキャフォールドまたはドラフトの成果物は needs_execution かつ proof_ready = false として扱い、完了した作業と呼ばないでください。
• 有効なタスク入力、選択された Skill の内容、依存関係の出力、および納品済み成果物のハッシュが変わっていない場合に限り、完了済みの作業を再利用してください。検証前に影響を受ける依存関係チェーンを再実行し、前提条件が失敗した場合は依存する処理をブロックしてください。
• フォールバックや境界動作を使って、実行、検証、または根本原因の修正を回避しないでください。
• 確認済みの範囲内でチェックが失敗した場合、その失敗に対する的を絞った修正は最大 1 回までとし、影響を受けたチェックを再実行してください。修正に失敗した場合、範囲の判断が必要な場合、または必要な証拠が不足している場合は、残っているブロッカーを報告してください。

ユーザーへの納品

既存の WorkDossier を詳細な証拠の情報源として使用してください。検証済みの結果、その保存場所、実際に実行したチェック、および実際のブロッカーを含む、簡潔な納品概要をユーザーに提示してください。スキャフォールドは完了済みの結果に含めないでください。内部の記録や診断の詳細は、ユーザーの判断に役立つ場合を除き、Dossier 内に保管してください。

プロトコルマップ

これらの参照資料は、正式な起動後、またはリポジトリの保守時にのみ読んでください。

• protocols/runtime.md：統制対象のランタイム契約とステージの責任範囲
• protocols/think.md：計画、調査、実行前の分析
• protocols/do.md：コーディング、デバッグ、検証
• protocols/review.md：レビューと品質ゲート
• protocols/team.md：XL マルチエージェントのオーケストレーション
• protocols/retro.md：振り返りと証拠に基づく修正

保守

• ランタイムファミリー：統制対象ランタイム優先
• バージョン：4.1.1
• 更新日：2026-10-18
• 主要な契約メタデータ：core/skill-contracts/v1/vibe.json