English | 简体中文 | 日本語 | 한국어 | Tiếng Việt | Português | Español | Deutsch | Français | हिंदी

世界トップクラスのエンジニアが、バイブコーダーのために開発
flowser.ai — GTM向けコンピュータ付きAIエージェント

vibecode-pro-max-kit

「全集中——スペックの呼吸 拾ノ型・ヴァイブの流れは決して途切れない。」
——竈門炭治郎

プロジェクトにドロップするだけ。AIエージェントが完全なプラン優先の開発プロセスを手に入れます——7つのゲート付きフェーズ、自己修復チェックループ、最初から最後まで場所を失わずに動くオートパイロット。

📦 ワンコマンドインストール 1行のcurlでどんなプロジェクトにも導入できます。新規・既存ユーザーを自動判別し、既存ファイルを上書きしません。	🌐 どこでも動作 あらゆるテックスタック、あらゆる言語、あらゆるAIコーディングエージェント——Claude Code、Codex、Cursor、Windsurf、Copilotなど。
🧭 RIPER-5 プラン優先ワークフロー 7つのゲート付きフェーズ（Research → Spec → Innovate → Plan → Validate → Execute → Update-Process）でエージェントが即コードに飛びつくのを防ぎます。	🚀 オートパイロットモード（quick / fast / full） 1つのフレーズでどのフェーズからでもハンズフリー実行を開始できます。3つのレーンでリスクに合わせた手順を選択。
🎯 /goal ——完了まで走り続けるトークン 1つのコピペ可能なブロックで、エージェントがフェーズをまたいで止まらず走り続けます——新しいセッションでも再開できます。	🔁 PVL + EVL 自己修復ループ プランチェックと修正、テストチェックと修正のループが自動でギャップを見つけて修正し、再確認します——それぞれ最大10サイクル。
🔍 vc-autoresearch プラン、テスト、スペック、ドキュメント、評価に向けられる再利用可能なギャップ発見→修正→繰り返しループ。	🧪 フィージビリティプローブ エージェントが設計アプローチを確定する前に、実装前検証（VIABLE / NOT-VIABLE）を行います。
🎛️ スマート戦略選択 各フェーズ前に、1エージェントか複数か協調チームかをコスト見積もり付きで比較し、最安値の適切な選択をします。	🧮 スマートなモデル活用 高コストモデルはコード作成のみ。それ以外はすべて安価なモデルが担当。コストを下げつつ品質を維持。
🤔 インテント明確化 リクエストが曖昧な場合、エージェントは推測して間違ったものを作る代わりに、事前にいくつかの的確な質問をします。	🛡️ 36バリデーター 意見ではなく機械的な正確性チェック——キット自体の構造を守り、問題が出荷前にドリフトを検出します。
🏗️ フェーズプログラム 大規模プロジェクトを品質ゲート付きの独立フェーズに分割するので、大きな作業が途中で崩壊しません。	🔀 学びながら自己再構成するプログラム 学習しながら、エージェントが新フェーズを挿入し、作業を並べ替え、ブロックされたステップをスキップします——プランは動的に適応します。
🧠 場所を失わない 進捗はフェーズごとにディスクに書き込まれるので、メモリリセットが起きても実行が継続し、正確に中断した場所から再開します。	📚 自己改善型プロジェクトメモリ セットアップ時にコードベースを学習し、機能をリリースするたびに共有メモを最新状態に保ちます。ドキュメントが古くなりません。
⚡ Quick Fix + Fast Mode 小さな変更向けの軽量レーン。1行の修正は1行のままで済みます。	🧱 レイヤー化された自動発見スキル スキルは明確なレイヤーに整理され、自動的に発見されます——エージェントは常にそのステップに適切なツールを見つけます。
🤖 15エージェント · 33スキル · 10フック 専門化されたエージェント、再利用可能なスキル、セーフティフックのフルチームが最初からすべて連携済み。	🔄 フルキットライフサイクル インストール、セットアップ、アップデート、パブリッシュがそれぞれ1コマンド——すべてのプロジェクトを安全に最新キットで維持。
📝 SPEC——平易な言葉での合意 設計の前に、シンプルなユーザーストーリーで何を作るかを明記します——誤解を最も安くキャッチできる場所。	🎯 常にインテントを確認 後続のすべてのフェーズがSPECに照らし合わせます：作っているものは本当に求められているものか？

最もシンプルで、最も柔軟で、チームフレンドリーなコーディングキット

     
   

あらゆるテックスタック、あらゆる言語、あらゆるプロジェクトで動作

デコレーションではありません。vc-setupを実行すると、エージェントがコードベースをスキャンし、
スタックを検出して、すべてのスキルが動作前に参照するプロジェクト固有のナレッジグループを構築します。
他のハーネスはエージェントを1言語にロックします——rust-review-agent、python-linter——他では役に立ちません。
このキットは上記のあらゆる組み合わせに適応し、機能をリリースするたびに知識を蓄積します。

⚡ はじめる——1コマンド、30秒

前提条件： Node.js ≥ 22、git、bash（macOS / Linux / WSL；Alpineの場合：apk add bash）。

コマンドは1つだけで、誰でも同じです。 プロジェクトフォルダー内で実行してください。新規か既存ユーザーかを自動検出し、ファイルを上書きせずに安全にインストールし、次に何を言えばいいかを正確に教えてくれます。

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

完了したら2つのメッセージのいずれかが表示されます——出力の最後を読んで、そこに書いてある通りにしてください：

💡 コマンドを推測する必要はありません。 install.shがルーティングします：新規 → vc-setup、アップグレード → vc-update。インストールを再実行しても常に安全です——何も壊しません。Codexユーザー： チャットで言う代わりに /vc-setup（または /vc-update）を実行してください。

your-project/
├── .claude/
│   ├── agents/              # 🤖 15のエージェント定義（.md）
│   ├── skills/              # ⚡ 33のスキル（各ディレクトリにSKILL.md）
│   └── hooks/               # 🪝 10のライフサイクルフック（.cjs / .mjs）
├── .codex/agents/           # 🔄 Codex用ミラーエージェント
├── .agents/skills →         # 🔗 .claude/skillsへのシンボリックリンク（Codex発見用）
├── CLAUDE.md                # 📋 オーケストレーター＋ルーティングルール
├── AGENTS.md                # 📖 エージェント＋スキルレジストリ（クロスツール）
└── process/
    └── development-protocols/  # 📜 22の共有ワークフロードキュメント（installで配置）
                                #    context/、プラン、フィーチャー → vc-setupで構築

First, install the vibecode-pro-max-kit agent harness by running this command:

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

After install completes, run vc-setup and follow the full interactive flow:

1. DETECT — Read package.json (or go.mod, Cargo.toml, pyproject.toml, etc.), detect my
   stack: framework, package manager, monorepo structure, test framework, database, auth.
   Also check for any existing .claude/, process/, or context files.
2. SHOW ME WHAT YOU FOUND — Summarize detection and wait for me to confirm. If this is an
   existing project, tell me what looks good vs what could be improved.
3. ASK ME ABOUT THE PROJECT — Have a real conversation. Ask follow-ups, probe anything
   vague, keep going until you genuinely understand it. Summarize back and confirm.
4. SCAFFOLD — Create the process/ directory. If process/ already exists, show me the plan
   and wait for approval. Never silently move or delete my files.
5. STUDY — Deep-scan and populate process/context/all-context.md with REAL content: repo
   structure, stack + versions, patterns, import aliases, env vars, routes, schema, tests.
   No placeholder text.
6. VALIDATE — Run all validation checks to confirm everything is wired correctly.

Rules: read and preserve good existing context; show me a summary before each major change
and wait for my OK; never create empty placeholder files; ask before reorganizing.

🎁 一目でわかる概要

🔥 課題

Claudeに「Webhook対応を追加して」と頼むと、すぐにコードを書き始めます。アーキテクチャについて質問もしない。既存パターンのチェックもしない。プランもなし。コードベースに合わない400行ができあがって、修正に1時間かかります。

でもこれは表面的な問題に過ぎません。 より深い問題が重くのしかかります：

あなたのエージェントには知性があっても、プロセスも記憶もチームとのコラボレーション手段もないのです。 開発者であれ、PMであれ、バイブコーディングを始めたばかりのCEOであれ——この問題は誰にとっても同じです。解決策も同じです：エージェントに本物の開発プロセスを与えること。

🛠️ 解決策

このキットは単なるCLAUDE.mdではなく、15の専門エージェント、33のスキル、10のフック、22のプロトコルという完全な開発システムをプロジェクトにインストールします——エージェントが理解してからビルドし、証明してから出荷するステップロック型ワークフロー付きで。

フルRIPER-5フロー——7フェーズ、すべてのステップにゲート

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    R["RESEARCH\nリードオンリーのファクト収集"]
    S["SPEC\n要件ドキュメント"]
    I["INNOVATE\n2〜3のアプローチ"]
    P["PLAN\n詳細チェックリスト"]
    V["VALIDATE\nプラン→コントラクト\n（PVLループ）"]
    E["EXECUTE\n実装\n（EVLループ）"]
    U["UPDATE PROCESS\nキャプチャ＋アーカイブ"]

    R -->|"go"| S
    S -->|"go"| I
    I -->|"go"| P
    P -->|"ENTER VALIDATE"| V
    V -->|"Gate: PASS"| E
    E -->|"gates green"| U

    style R fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style S fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style I fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style P fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style V fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style U fill:#00695C,stroke:#004D40,color:#FFFFFF

インタラクティブモードでは、各フェーズが「go」を待ってから次に進みます——あなたはすべてのステップでループに入っています。オートパイロットまたは /goal モードでは、最初に1回承認すれば、システムが完了まで自動で動かします。以下の3つの特定のハードストップのみで止まります。VALIDATEと実行後の再テストは省略不可能で——バグ作業が出荷されるのを防ぐハードゲートです——どちらのモードでも自動実行されます。

バイブコーディング革命

バイブコーディングはソフトウェアを作れる人を変えました。プラン優先開発は出荷できるものを変えます。

ほとんどのツールはプロジェクトの開始を助けます。このキットは完成させることを助けます——チームがレビューできるプラン、古くならないナレッジ、ミスが出荷される前にキャッチするセーフティチェックとともに。

誰のためのツール？

比較

ランタイムの幅について： GSDは14ランタイムをサポートしています。私たちは7つを深くサポートします——すべてのプラットフォームにフルエージェントハーネス、スキル発見、ライフサイクルフックを備えています。幅 vs 深さ：あなたの選択です。

⚡ 何が違うのか

🧭 仕組み：コーディネーター

メインセッションはコーディネーター（オーケストレーターとも呼ばれます）であり、ワーカーではありません。4つのことのみを行います：

Your request
  → Step 0: Skill Discovery (scan 33 skills, match keywords, attach candidates)
  → Detect intent (feature / bug / question / refactor / UI) + score ambiguity
  → Route to the right agent in a fresh context window
  → Monitor: step compliance, status codes, loop driving

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    REQ["User request"]
    SD["Step 0: Skill Discovery\nscan 33 skills, match keywords"]
    INT{"Detect intent\n+ score ambiguity"}
    RES["vc-research-agent\n(feature / question)"]
    PLN["vc-plan-agent\n(after INNOVATE)"]
    VAL["vc-validate-agent\n(PVL loop)"]
    EXE["vc-execute-agent\n(EXECUTE)"]
    TST["vc-tester\n(EVL loop)"]
    UPD["vc-update-process-agent\n(closeout)"]
    MON["Monitor\nstatus codes · loop driving\nno inline execution ever"]

    REQ --> SD --> INT
    INT -->|"feature / research"| RES
    INT -->|"plan phase"| PLN
    INT -->|"validate phase"| VAL
    INT -->|"execute phase"| EXE
    EXE -.->|"EVL"| TST
    INT -->|"update phase"| UPD
    RES --> MON
    PLN --> MON
    VAL --> MON
    TST --> MON
    UPD --> MON

    style REQ fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style SD fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style INT fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style RES fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style PLN fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style VAL fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style EXE fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style TST fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style UPD fill:#00695C,stroke:#004D40,color:#FFFFFF
    style MON fill:#37474F,stroke:#263238,color:#FFFFFF

なぜこれが重要か： 決定も秘密の編集もできるエージェントはプランをスキップする方法を見つけます。コーディネーターとワーカー（サブエージェント）を分離することで、プロセスが構造的に正直になります——コードを書く唯一の方法は必須ステップを経由することです。

📊 RIPER-5ライフサイクル

📝 SPECが独自フェーズである理由： ほとんどのハーネスは「理解」から「設計」へ直接ジャンプします。プロダクトディスカバリーSPECステップを挿入することで、エージェントがどのように作るかを議論する前に、あなた（またはPM）が何を作るかを——シンプルなユーザーストーリーと受け入れ基準で——承認できます。誤解をキャッチする最も安価な場所です。（フェーズプログラムのインナーループでは、SPECはスキップされます——アンブレラSPECが全フェーズを管轄します。）

SPECは測定基準です。 1分でスキャンできるシンプルな言葉で期待される動作を示します。その後のすべてのフェーズ——Innovate、Plan、Validate、Execute——が照らし合わせて同じ質問をします：作っているものは本当に求められているものか？ 作業がずれ始めたとき、SPECがそれを検出します。

flowchart TD
    U["You: what I really want<br>(plain words)"] --> S["📝 SPEC<br>expected behavior + acceptance<br>criteria — you approve"]
    S --> I["💡 INNOVATE"]
    S --> P["📋 PLAN"]
    S --> V["✅ VALIDATE"]
    S --> E["⚡ EXECUTE"]
    I -.->|"check back"| Q{"Is this what<br>you asked for?"}
    P -.->|"check back"| Q
    V -.->|"check back"| Q
    E -.->|"check back"| Q
    Q -->|yes| GO["keep building"]
    Q -->|no| S

💻 セッション例

# 🆕 Feature request
You: "add webhook support to the API"
→ Skill discovery surfaces: vc-scenario, vc-security
→ research-agent gathers context (read-only, can't touch code)
→ "go" → spec-agent writes requirements doc → you approve
→ "go" → innovate-agent compares approaches → decision summary
→ "go" → plan-agent writes the plan, listing which files it will touch
→ "ENTER VALIDATE MODE" → validate-agent gates the plan (PVL loop) → Gate: PASS
→ "ENTER EXECUTE MODE" → execute-agent implements → tester re-runs gates (EVL) → reviewer → git-manager
→ Closeout packet: what changed, what's verified, recommended next step

# 🐛 Bug fix
You: "login redirect is broken"
→ Routes to vc-debugger → gathers evidence FIRST → 2-3 competing hypotheses
→ Systematically eliminates each → root cause with proof chain
→ execute-agent implements the fix → EVL re-test → quality pipeline

# ⏩ Fast mode
You: "ENTER FAST MODE - add rate limiting middleware"
→ Compressed RESEARCH + SPEC + INNOVATE + PLAN + VALIDATE in one pass
→ Mandatory safety pause after VALIDATE → you review → "ENTER EXECUTE MODE"

# 🤖 Autopilot (hands-free)
You: "autopilot full: build a notifications system"
→ ONE consolidated clarification round → provisional /goal block (standing consent)
→ Drives the full RIPER-5 sequence autonomously, pausing only on hard stops

# 🏗️ Large program
You: "build a full testing platform"
→ Umbrella plan + phase plans in a feature folder
→ Each phase inner loop: research → innovate → plan → PVL → execute → EVL → update
→ Progress survives context compaction — durable reports on disk

🎯 インテント明確化

ルーティング前に、リードエージェントはリクエストの曖昧さを**4つの2値シグナル（0〜4）**でスコアリングし、層を選択します。実際に何をするかが変わる場合のみ質問します。

🧠 最大2ラウンド。 層2の後もまだ不明な場合、最後に1つの平易な質問をして、最も狭い合理的なスコープのリサーチにデフォルトします。明確化を永遠にループしません。RESEARCH後、インテントを再確認します——リサーチが当初の想定と異なることを示した場合は再提示し、確認された場合は再質問せずに進みます。

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    REQ["User request"]
    SCORE{"ambiguity score\n0–4 binary signals"}
    AUTO["Auto-skip conditions\n(go / continue / mid-phase\n/ trivial / explicit mode\n/ resuming plan / pure info)"]
    T0["Tier 0\nsilent auto-route\n(score 0–1 OR auto-skip)"]
    T1["Tier 1\ninline summary\n(score 2)"]
    T2["Tier 2\nask focused questions\n(score 3+)"]
    ROUTE["Route to matching agent\n(research / plan / execute / …)"]
    STILL{"still unclear\nafter Tier 2?"}
    FINAL["One final plain question\n(max 2 clarification rounds)"]
    NARROW["Default: vc-research-agent\nnarrowest reasonable scope"]

    REQ --> AUTO
    AUTO -->|"auto-skip matches"| T0
    AUTO -->|"no auto-skip"| SCORE
    SCORE -->|"0–1"| T0
    SCORE -->|"2"| T1
    SCORE -->|"3+"| T2
    T0 --> ROUTE
    T1 --> ROUTE
    T2 --> STILL
    STILL -->|"resolved"| ROUTE
    STILL -->|"still unclear"| FINAL --> NARROW

    style REQ fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style AUTO fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style SCORE fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style T0 fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style T1 fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style T2 fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style ROUTE fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style STILL fill:#F57F17,stroke:#F9A825,color:#000000
    style FINAL fill:#AD1457,stroke:#880E4F,color:#FFFFFF
    style NARROW fill:#00695C,stroke:#004D40,color:#FFFFFF

✅ 2つの品質ループ——PVL + EVL

ほとんどのハーネスは1回だけ確認します（あっても）。このキットはEXECUTEを2つの独立したループで囲みます——1つはコードを書く前、もう1つは後。

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '15px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    PLAN["📋 PLAN written"]
    PVL{"✅ PVL\nValidate the plan\nV1–V7 gates"}
    PASS["Gate: PASS"]
    SUPP["📝 plan-agent supplements\n(addresses gaps)"]
    EXEC["⚡ EXECUTE\nimplement the plan"]
    EVL{"🧪 EVL\ntester re-runs the\nvalidate-contract gates"}
    FIX["⚡ execute-agent\nsupplement (fix gate)"]
    DONE["🧠 UPDATE PROCESS"]

    PLAN --> PVL
    PVL -->|"CONDITIONAL / BLOCKED"| SUPP
    SUPP -->|"re-run from V1"| PVL
    PVL -->|"PASS"| PASS
    PASS -->|"ENTER EXECUTE"| EXEC
    EXEC --> EVL
    EVL -->|"gate fails"| FIX
    FIX -->|"re-run"| EVL
    EVL -->|"all gates green"| DONE

    style PLAN fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style PVL fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style PASS fill:#00695C,stroke:#004D40,color:#FFFFFF
    style SUPP fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style EXEC fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style EVL fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style FIX fill:#AD1457,stroke:#880E4F,color:#FFFFFF
    style DONE fill:#00695C,stroke:#004D40,color:#FFFFFF

💎 判定ラダー： PASS → 続行 · CONDITIONAL → 修正可能なギャップ；ループが起動（またはあなたが記録上受け入れる） · BLOCKED → より深い問題；PLANに戻る（オートパイロット下：ギャップはバックログに入り実行は継続）。

🔁 vc-autoresearch——共有ループエンジン

PVLとEVLは同じトラッキングレイヤーを使用します：vc-autoresearch——ギャップ発見→修正→繰り返しループ。リードエージェントがループを駆動します——ラウンドカウンター、ラウンドごとのレポート、TSVログ、プラトー/上限/リグレッションチェックを所有します。ワーカーエージェントはファイア・アンド・フォーゲット：結果を返して止まります。エージェントが自分自身を再起動したり別のフェーズエージェントを起動したりすることはありません。

同じエンジンを単独でも使えます：「このスペックを強化して」、「すべてのリントを修正して」、「テストカバレッジを改善して」、「これらのドキュメントを改善して」——6つのドメイン（spec · tests · ux · docs · plan · errors）にわたるあらゆる繰り返しギャップ発見・修正タスク。

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    START["Start loop\n(orchestrator init results.tsv\nheader + baseline row)"]
    FIND["Find gaps\n(validate-agent / tester\nreturns gap list)"]
    RPT["Write iteration report\n{slug}-iteration-{NNN}_REPORT_{dd-mm-yy}.md"]
    TSV["Append results.tsv row\n(cycle N, gap count)"]
    FIX["Fix gaps\n(plan-agent supplement\nOR execute-agent supplement)"]
    CHK["Guard checks\nplateau? cap hit? regression?"]
    RECHECK["Re-check\n(re-run validate / tester)"]
    SUCC["SUCCESS\nall-clear 2 consecutive rounds"]
    HALT["HALT\nplateau / 10-cycle cap / regression"]

    START --> FIND --> RPT --> TSV --> FIX --> CHK
    CHK -->|"safe to continue"| RECHECK
    RECHECK --> FIND
    CHK -->|"plateau / cap / regression"| HALT
    FIND -->|"no gaps found (×2)"| SUCC

    style START fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style FIND fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style RPT fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style TSV fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style FIX fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style CHK fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style RECHECK fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style SUCC fill:#00695C,stroke:#004D40,color:#FFFFFF
    style HALT fill:#B71C1C,stroke:#7F0000,color:#FFFFFF

停止条件： SUCCESS（2ラウンド連続オールクリア）· HALT_PLATEAU（3ラウンド進捗なし）· HALT_CAP（10ラウンドのハードリミット）· HALT_REGRESSION（以前パスしていたチェックが失敗）。

👥 戦略比較＋モデルポリシー

すべてのフェーズ遷移時に、リードエージェントはvc-agent-strategy-compareを呼び出して、コスト見積もり付きで次のフェーズの実行方法を推奨します。

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    SS["vc-agent-strategy-compare\n(every phase transition)"]
    SC{"signal score\n0–7"}
    SEQ["Sequential\none agent at a time\n(output feeds next)"]
    PAR["Parallel subagents\nfire-and-forget\n(independent dimensions)"]
    WF["Workflow\nscripted steps\nacross a list"]
    TEAM["Agent team\nTeamCreate + TaskCreate\n+ SendMessage\n(must coordinate mid-run)"]
    MC{"which phase?"}
    OPUS["🔴 opus\n(EXECUTE only)"]
    SONNET["🔵 sonnet\n(every other phase)"]

    SS --> SC
    SC -->|"low / dependent"| SEQ
    SC -->|"mid / independent"| PAR
    SC -->|"predictable split"| WF
    SC -->|"high / must coordinate\nor 3+ phase plans"| TEAM
    SS --> MC
    MC -->|"EXECUTE / fast-mode\nquick-fix (real code)"| OPUS
    MC -->|"Research / Spec\nInnovate / Plan\nValidate / Update\nall reviewers"| SONNET

    style SS fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style SC fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style SEQ fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style PAR fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style WF fill:#00695C,stroke:#004D40,color:#FFFFFF
    style TEAM fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style MC fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style OPUS fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style SONNET fill:#37474F,stroke:#263238,color:#FFFFFF

⚠️ 「エージェントチーム」は本物の機構を意味します——名前付きのチームメイト、共有タスクリスト、エージェント間メッセージング——単に「チーム」と呼んだ並列エージェントではありません。3つ以上のフェーズプランの作成と、エージェントがそれぞれ自分のファイルに留まる必要があるマルチファイル編集には必須（オプションではない）です。真のチームのみが実行中に通信できます。

🧮 モデル選択ポリシー

作業を複数のエージェントに分割する場合、コーディングエージェントのみがopusを使用します。すべてのレビュアー、リサーチャー、バリデーター、プランナーはsonnetを使用します。リードエージェントはワーカーを起動するたびにモデルを明示します。

🤖 オートパイロットモード——ハンズフリーRIPER-5

autopilot [task]（またはrun autopilot、autonomous mode、ENTER AUTOPILOT MODE）と言えば、エージェントが残りのRIPER-5シーケンス全体を最初に1回の明確化ラウンドで実行し——完了するまで一時停止しません。

どこからでもトリガー： オートパイロットはセッションの開始時または途中のどの時点からでも開始できます。トリガー時、リードエージェントはディスクに保存されたファイルを読み取って、すでにどのRIPER-5フェーズにいるかを把握し、そこから引き継いで残りを自律的に進めます。

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    TRG["autopilot trigger phrase\n(anywhere in session)"]
    DISK["Read saved files on disk\ndetect current phase"]
    CLR["ONE consolidated\nclarification round"]
    GOAL["Emit provisional /goal block\n(≤4000 chars, copy-pasteable\nstanding EXECUTE consent)"]
    ACT["AUTOPILOT_ACTIVATED\nautonomous run begins"]
    PHASES["Drive remaining phases\nRESEARCH → … → UPDATE PROCESS\n(no user pauses)"]
    HS1["🛑 Irreversible / outward action\nnot pre-approved"]
    HS2["⛔ Cascade BLOCKED\n(several phases stuck)"]
    HS3["💸 Live-provider billed probe\n(double opt-in required)"]
    DONE["Run complete\nautopilot deactivates"]

    TRG --> DISK --> CLR --> GOAL --> ACT --> PHASES
    PHASES -->|"hard stop 1"| HS1
    PHASES -->|"hard stop 2"| HS2
    PHASES -->|"hard stop 3"| HS3
    PHASES -->|"all phases done"| DONE

    style TRG fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style DISK fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style CLR fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style GOAL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style ACT fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style PHASES fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style HS1 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
    style HS2 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
    style HS3 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
    style DONE fill:#00695C,stroke:#004D40,color:#FFFFFF

You: "autopilot full: add team invitations with email + role management"
→ Reads saved files → detects current phase → enters there
→ ONE consolidated clarification round (scope, hard stops, autonomy boundaries, first-phase strategy)
→ Provisional /goal block emitted (≤4000 chars, copy-pasteable, standing EXECUTE consent)
→ AUTOPILOT_ACTIVATED → drives remaining phases on its own
→ Stops ONLY for hard stops

3つのレーン——リスクに合わせた手順

🌙 ハンズフリー：1フレーズで、寝ている間に構築

autopilot full: [task]と言う——または/goalブロックを貼り付ける——と、次のすべてがゼロの人間入力で起こります：

• プランチェック・修正ループ——プランのギャップを見つけ、修正し、再確認。自力で最大10ラウンド。
• ビルド・テスト・修正ループ——コードを書き、テストを実行し、失敗を修正し、再実行。自力で最大10ラウンド。自分の「オールグリーン」を信頼しません——別のチェッカー（vc-tester）がすべてのテストを独立して再実行して確認します。
• フェーズ間の自動進行——リサーチからプラン、コード、完了まであなたを待たずに進みます。
• メモリリセット後も再開——プラン、レポート、進捗はすべてディスク上のファイルとして保存されています。コンパクション後（AIの短期記憶がクリアされた後）、次のセッションがそれらのファイルを読み込んで、中断した正確な場所から続行します。
• 詰まった機能を脇に置いて続行——1つのフェーズが解決できない場合、エージェントはバックログノートを書いて次の機能に進みます。1つのブロッカーがすべてを止めることなく、複数の機能を並行して実行できます。
• 並列機能のエージェントチーム——複数のエージェントが同時に別々の機能を構築でき、それぞれが自分のファイルにロックされているので衝突しません。詰まった機能は停車されますが、残りのブロッカーにはなりません。

ハードストップは常にサーフェスされます（オートパイロット中でも）

止まってあなたに尋ねる唯一の3回：

• 🛑 取り消せないもの、または事前承認なしに外の世界に達するもの（本番公開、実際のメッセージ送信、課金）
• ⛔ 複数のフェーズが連続して行き詰まり進捗なし——本物の行き詰まりで目を向ける価値がある
• 💸 有料の外部サービスに実際のお金を使うテスト——実行前に確認を求めます

🎯 /goal——自律実行トークン

必須、飾りではありません： すべてのVALIDATEフェーズが完了した後、リードエージェントはEXECUTE開始前にコピペ可能な/goalブロックを必ず出力しなければなりません。これは必須のハンドオフファイルです——オプションのコメントではありません。

フォーマット制約：

/goalコマンドは4000文字を超えるブロックを拒否します。短く保ちましょう——必須フィールドを構造として使い、散文のエッセイにしないでください。

スタンドアロン /goal モード： 新しいセッションに/goalブロックを貼り付けると、STARTに名前付きのフェーズから実行が再開されます。明確化と決定ルールはすでに設定されています——新しい明確化ラウンドはありません。スタンディング/goal下では、エージェントはすべての可逆的なステップで自律的に決定し、BLOCKEDアイテムをバックログに送り、自分でレポートを書きます——しかしワーカーエージェントの委任は必須のままです。オートパイロットが削除するのは承認一時停止のみで、インライン実行禁止ルールは削除しません。

validate-autopilot-goal-block.mjsで検証されます。

🔬 フィージビリティプローブ＋バリデーターセーフティネット

🔬 フィージビリティプローブ——構築前に前提をテストする

SPEC、INNOVATE、またはVALIDATEが読み取りだけでは確認できない重要な前提に当たったとき、VC-FEASIBILITY-PROBE-NEEDEDを出力して停止します。リードエージェントがvc-debuggerを起動して実際のテストを実行し、VERDICTを書き込みます：

各判定には3部構成の設計ノートが付きます：結果が許可するもの · 禁止するもの · まだ不確かなもの——一字一句そのまま一時停止したフェーズに戻されます。プローブはコストクラス分けされています（cheap-local / needs-container / needs-live-provider → ダブルオプトイン / needs-browser / needs-cf）ので、有料または共有リソースのプローブが無音で実行されることはありません。

🛡️ 36バリデーター——機械的な正確性、意見ではない

このキットには36のバリデータースクリプトが付属し、「エージェントはルールに従ったか？」を明確なパス/フェイル結果に変えます。ハーネスファイルに触れるあらゆるフェーズの後、およびUPDATE PROCESSの必須チェックポイントとして実行されます：

🛡️ 組み込みセーフティシステム

これらはガイドラインではありません——すべてのエージェントに組み込まれたハードルールです。

🔍 実装前インテリジェンス

コードを1行も書く前に、3つの専門スキルが問題をキャッチできます：

✅ 品質パイプライン——実行に組み込み済み

テスト優先、その後コード。 合意済みチェックリスト（コードに触れる前に作成）が通過しなければならない正確なテストを定義します。execute-agentはそれらのテストがグリーンになるまでコードを書きます。その後、別のチェッカー——vc-tester——がすべてのテストを独立して再実行して確認します。execute-agent自身の「オールグリーン」は額面通りに受け取られません。最後に、レビュアーが新しい部分だけでなく、プロジェクト全体がまだ一緒に動作することを確認します。

execute-agentはコードを書いて終わりではありません。品質パイプラインを自動的に経由します：

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '16px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    E["⚡ Execute-Agent\nImplements the plan"]
    SR["🔎 Self-Review\nLine-by-line check\nagainst plan"]
    T["🧪 Tester (EVL)\nDiff-aware — re-runs\nthe contract gates"]
    CR["🔍 Code Reviewer\nEdge case scout\n+ adversarial review"]
    CS["✨ Code Simplifier\nClarity refactoring"]
    GM["📦 Git Manager\nLogical commit splitting\nfrom touched_files"]

    E --> SR --> T --> CR --> CS --> GM

    style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style SR fill:#AD1457,stroke:#880E4F,color:#FFFFFF
    style T fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style CR fill:#283593,stroke:#1A237E,color:#FFFFFF
    style CS fill:#00695C,stroke:#004D40,color:#FFFFFF
    style GM fill:#37474F,stroke:#263238,color:#FFFFFF

📋 プランライフサイクル

すべての重要な機能はプランライフサイクルに従います——作成され、レビューされ、その通りに構築され、永続的なプロジェクト履歴としてアーカイブされる成文化されたスペック。

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '16px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    A["🆕 Feature Request"]
    B["📝 Plan Created\nin active/{slug}_{date}/"]
    C{"👀 User Reviews\nthe Plan"}
    D["✅ VALIDATE\n(PVL gates)"]
    E["⚡ Execute + EVL"]
    F["📦 Plan Archived\nto completed/"]
    G["🧠 Learnings →\nall-context.md"]
    H["🔄 Next Feature\nStarts Smarter"]

    A --> B --> C
    C -->|"✏️ Needs Changes"| B
    C -->|"✅ Approved"| D --> E --> F --> G --> H
    H -.->|"context compounds"| A

    style A fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style B fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style C fill:#F57F17,stroke:#F9A825,color:#000000
    style D fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style F fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style G fill:#00695C,stroke:#004D40,color:#FFFFFF
    style H fill:#1565C0,stroke:#0D47A1,color:#FFFFFF

💡 6ヶ月後に誰かが*「なんでこの認証方式にしたんだっけ？」*と聞いた時、答えはcompleted/にあります。Slackのスレッドに埋もれてはいません。

プランの保存場所——タスクフォルダー規約：

process/
├── general-plans/
│   ├── active/
│   │   └── webhooks_28-05-26/          # 📋 タスクフォルダー：プラン＋コロケートされたレポート/refs
│   │       └── webhooks_PLAN_28-05-26.md
│   ├── completed/                       # ✅ アーカイブ済み（検索可能な履歴）
│   └── backlog/                         # 📌 延期された作業
└── features/
    └── billing/                         # 🏷️ フィーチャースコープ（5以上のアーティファクト）
        ├── active/{slug}_{date}/
        ├── completed/
        └── backlog/

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    PC["vc-plan-agent creates task folder\nprocess/general-plans/active/{slug}_{date}/\nOR features/{feature}/active/{slug}_{date}/"]
    PLAN["{slug}_PLAN_{dd-mm-yy}.md\n— plan file\n— Validate Contract appended here"]
    REF["{slug}_REF_{dd-mm-yy}.md\n— optional references"]
    RPT["{slug}-iteration-{NNN}_REPORT_{dd-mm-yy}.md\n— per PVL/EVL cycle report"]
    TSV["results.tsv\n— rolling loop log\n(header + baseline + cycle rows)"]
    PP["PHASE PROGRAM extras"]
    UMB["umbrella_PLAN_{dd-mm-yy}.md\n— Program Goal Charter\n— /goal block"]
    PHN["phase-N_PLAN_{dd-mm-yy}.md\n— one file per phase"]
    REG["phase-blast-radius-registry.md\n— per-phase file ownership"]

    PC --> PLAN
    PC --> REF
    PC --> RPT
    PC --> TSV
    PC --> PP
    PP --> UMB
    PP --> PHN
    PP --> REG

    style PC fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style PLAN fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style REF fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style RPT fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style TSV fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style PP fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style UMB fill:#00695C,stroke:#004D40,color:#FFFFFF
    style PHN fill:#00695C,stroke:#004D40,color:#FFFFFF
    style REG fill:#37474F,stroke:#263238,color:#FFFFFF

すべてのプランには次が含まれます：📍 タッチポイント（作成・変更されるファイル）· 📜 パブリックコントラクト · 💥 触れるファイル（何が壊れる可能性があるか、何をテストするか）· ✅ 検証エビデンス · 🔄 再開ハンドオフ。vc-plan-discoveryが再開する適切なプランを見つけ、post-write-plan-checkフックがすべてのプラン書き込み時にプラン構造を確認します。

🏗️ フェーズプログラム——崩壊しない大規模プロジェクト

通常の機能は1つのプランを使います。大規模なマルチフェーズプロジェクトはフェーズプログラムを使います——アンブレラプランとフェーズごとのプラン、それぞれ独自のチェックポイントと保存されたレポートを持つ7ステップのインナーループ全体を実行します。

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    UP["🎯 Umbrella Plan\nProgram Goal Charter\n(north star · done · scope tiers)"]
    P1["📋 Phase 1"]
    P2["📋 Phase 2 ..."]

    subgraph LOOP["🔁 Per-phase inner loop (skips SPEC)"]
        direction TB
        R["🔍 Research"]
        I["💡 Innovate"]
        PL["📋 Plan-supplement"]
        PVL["✅ PVL"]
        EX["⚡ Execute"]
        EVL["🧪 EVL"]
        UPD["🧠 Update"]
        R --> I --> PL --> PVL --> EX --> EVL --> UPD
    end

    UP --> P1 --> LOOP
    LOOP -.->|"learnings feed\nnext phase"| P2

    style UP fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style P1 fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style P2 fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style R fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style I fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style PL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style PVL fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style EX fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style EVL fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style UPD fill:#00695C,stroke:#004D40,color:#FFFFFF

🔀 学びながらプログラムが自己再構成する

最初に書いたプランは粗削りな地図であり、固定のコントラクトではありません。プログラムが実行されるにつれ、調整します——すべてのステップを事前に予測する必要はありません。

実行の途中に新しいフェーズを追加できます。 作業中、エージェントが欠けているステップを発見することがあります——次のフェーズが進む前に行わなければならないこと。その場合、そこに新しいフェーズを挿入し、残りの番号を付け直して続行します。人間の介入は不要です。（内部シグナル：MID_PROGRAM_PLAN_CREATED——新しいプランがディスクに書き込まれ、自動的にレジストリに追加されます。）

フェーズを並べ替えることができます。 リサーチで計画した順序が間違っていることが判明する場合があります——例えば、フェーズ3がフェーズ4が生成するものに依存している場合など。エージェントは残りのフェーズを並べ替えて理由を記録します。（内部シグナル：PHASE_RESTRUCTURE_NOTICE——監査証跡としてフェーズレポートに保存され、ブロッカーにはなりません。）

各フェーズのプランをコーディング直前に更新します。 フェーズのコーディングが始まる前に、クイックリサーチパスがプログラムがこれまでに学んだことを確認します。その後、そのフェーズのチェックリストを新しい発見で更新します。これはプランサプリメントステップと呼ばれます。プランは固定されません——前のフェーズからの新しい事実を吸収します。

まだ開始できない作業をスキップします。 フェーズがまだ準備できていないものに依存している場合——まだ構築されていないサービス、まだ決定されていない決定——エージェントそのフェーズを依存関係ブロックとしてマークし、脇に置いて次に進みます。1つのフェーズが待っているためにプログラム全体が止まることはありません。

いつ停止して質問すべきかを知っています。 詰まった1つのフェーズはバックログに入れられてプログラムが続行します。しかし複数のフェーズが連続して壁にぶつかり進捗がない場合、エージェントはそれを本物の行き詰まり——カスケードストップ——として扱い、何が起きたかを示して一時停止します。1つの詰まったフェーズは正常です。連続して複数が詰まると構造的な問題を示します。

ライブスコアボードを維持します。 すべてのプログラムには、アンブレラプランに1ページのステータスセクションがあり、どのフェーズが現在進行中か、完了しているか、レポートがどこにあるかを示します。誰でも——またはメモリリセット後のエージェント自身でも——読んでどこにいるかを正確に把握できます。また、同時に作業している2つのフェーズが同じファイルを編集しないようにシンプルなファイルレジストリも維持します。

最後に1つの大きな最終チェック。 プログラム全体の終わりに、エージェントがプロジェクト全体がまだ一緒に動作するエンドツーエンドテストを実行します——各部品が単独でではなく。個々のフェーズチェックポイントが各部品が動作することを証明し、この最終チェックが部品が全体として動作することを証明します。

🧠 場所を失わない（メモリリセットを生き延びる）

長い仕事は正確に完了します——AIのメモリが途中でリセットされても。プラン、進捗、証拠はすべてディスク上のファイルに保存され、エージェントの頭の中だけにあるわけではありません。

AIエージェントには限られたワーキングメモリがあります。長い仕事ではそのメモリが埋まり圧縮されます——詳細がぼやけることがあります。新しいセッションが始まったとき（またはメモリがクリアされたとき）、エージェントはどこで止まったかを推測しません。ファイルを読みます。

正確にこう動作します：

1. フェーズごとに短いレポートを書きます。 フェーズが完了したら、レポートファイルがディスクに書き込まれます。進捗はエージェントの頭の中だけでなく、プロジェクトフォルダーに保存されます。メモリ圧縮でファイルは消えません。

2. どのステップが完了したかのチェックリストを維持します。 各フェーズプランにはPhase Loop Progressリスト——すべてのステップ（リサーチ、プランチェック、ビルド、テスト、学びのキャプチャ）のチェックボックスがあります。リセット後、エージェントはそれらのボックスを読んで正確な次のステップを把握します。追いつかせる必要はありません。

3. 各フェーズの開始時に短い「エンベロープ」。 すべてのワーカーエージェント（作業の1フェーズを担う集中したヘルパー）はContext Envelope——10フィールドのノート：どの機能、どのフェーズ、どのブランチ、どのプランファイル、どのテストを実行するか——を出力することから始めます。読むのに数秒かかります。エージェントは何かする前に準備完了です。

4. 自分のメモリよりファイルを信頼します。 再開時、エージェントはコードとgit履歴に実際に何があるかをプランが言うことと照合します。実際の状態が勝ちます。古くなったプランはエージェントを誤って作業を繰り返させたりステップをスキップさせたりすることができません。

5. 実行中のスコアボードとラウンドごとのレポート。 すべての修正ループ（プランチェックループとビルドテストループ）はresults.tsvスコアボードファイルを維持します——残っている問題数を追跡するラウンドごとの行。セッションがループの途中で終了したとき、次のセッションがカウントを読み、適切なラウンドから再開し、続行します。ラウンドは失われません。

6. 再開時にリマインダーを再注入します。 メモリが圧縮されたとき、システムは自動的に最新のステータスノートを新しいセッションにリロードします。承認待ちがあった場合——例えば、先に進む前に「はい」が必要なチェックポイント——リマインダーがそれをフラグします。何も黙ってスキップされません。

💡 要するに：オートパイロット実行を開始し、ラップトップを閉じて、数時間後に戻ることができます。エージェントはあるべき場所に正確にいるか——または最後に保存されたチェックポイントから再開し、ディスク上の証拠でそれを証明します。

🧠 コンテキストグループ

プロジェクトの知識はコンテキストグループに整理されます——安定したナレッジエリアで、それぞれにエージェントに何をいつ読むべきかを指示するall-{group}.mdルーターファイルがあります。エージェントはルーターに従い、毎回ナレッジベース全体ではなく関連するものだけを読み込みます。

process/context/
├── all-context.md              # 🧭 ルートルーター——アーキテクチャ、スタック、パターン、規約
├── tests/all-tests.md          # 🧪 テストランナー、コマンド、デバッグ手順
├── container/all-container.md   # 🐳 Docker、デプロイ、インフラ手順
├── uxui/all-uxui.md            # 🎨 コンポーネント、デザイントークン、パターン
├── infra/all-infra.md          # 🖥️ サーバーインフラ、デプロイ
└── {your-domain}/all-{domain}.md  # 📚 3つ以上の永続ドキュメントがあるドメイン（自動昇格）

キットはプロトコルシードのみを提供します——コンテキストグループはvc-setupによってあなたのプロジェクト向けに構築されます（実際のコードをスキャン）。これらはパターンであり、固定リストではありません。

📁 フィーチャーフォルダー

トピックが5つ以上のファイルを積み重ねると、独自のフィーチャーフォルダーが付与されます——完全なライフサイクルコンテナです。

process/features/{feature}/
├── active/{slug}_{date}/   # 📋 作業中のプラン（レポート/refsがコロケート）
├── completed/              # ✅ アーカイブ済みプラン（検索可能な意思決定履歴）
└── backlog/                # 📌 延期された作業（エージェントが重複作成前にチェック）

🧱 スキルレイヤー

33のスキルは3つのレイヤーに分類されます。すべてのSKILL.mdがフロントマターでlayerとtrigger_keywordsを宣言し、生成されたカタログが発見を高速化します。

🧠 自己改善型プロジェクトメモリ

完了したすべての機能が学びをコンテキストシステムにフィードバックします——ナレッジは積み重なり、リセットされません。

AIアシスト型コードベースのほとんどは逆の特性を持ちます：新しいセッションはコールドスタートします。エージェントは同じファイルを再読し、同じパターンを再発見し、同じ決定を再び行います——前のセッションの洞察がチャットウィンドウにしか存在しなかったから。キットの答えはプロンプトのトリックではありません。永続的なコンテキストファイルシステム（process/context/）——すべてのエージェントがセッション開始時に読み、すべてのバリデーターが保護し、すべての完了した機能が豊かにする——です。

6ヶ月後、多くのメモリリセットを経ても、エージェントはなぜ認証がそのように機能するかを知っています——その知識がディスクに、ルーティングされた形で、監査可能な形でオンディスクにあるから、死んだセッションに閉じ込められているのではなく。

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    FEAT["Feature ships\n(EXECUTE + EVL complete)"]
    UP["UPDATE PROCESS phase\nvc-update-process-agent"]
    CTX["process/context/ updated\nsmallest relevant file\n+ all-context.md router"]
    AGENT["Next agent spawned\nreads context router\n→ routes to correct group file"]
    BETTER["Better next feature\nno re-discovery, no stale patterns"]
    FEAT --> UP --> CTX --> AGENT --> BETTER
    BETTER -.->|"compounds each feature"| FEAT

    style FEAT fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style UP fill:#00695C,stroke:#004D40,color:#FFFFFF
    style CTX fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style AGENT fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style BETTER fill:#E65100,stroke:#BF360C,color:#FFFFFF

核となるメカニズム：ポータブルな共有メモリとしてのprocess/context/

process/context/はトピックグループに整理された構造化されたナレッジを保持します——アーキテクチャの決定、コーディング規約、デプロイ手順、テストパターン、インフラの事実。チャット履歴とは異なり、このナレッジは：

• すべてのワーカーエージェントに伝わります——vc-context-discoveryが起動された各エージェントをタスクに適したall-{group}.mdルーターに、そして最小の関連するディープファイルにルーティングします。リサーチエージェント、プランエージェント、コーディングエージェントがすべて同じ共有理解でスタートします
• メモリリセットを生き延びます——コンテキストウィンドウではなくディスクにあります；圧縮されたセッションはそれを失いません
• ClaudeとCodexの両方で読めます——.agents/skillsは.claude/skills/へのショートカットリンクであり、同じコンテキストシステムが重複なく両方のエージェントに機能します

ルートルーター（all-context.md）がグループルーター（all-{group}.md）を指し、グループルーターが最小の関連するディープファイルにルーティングします。エージェントはルーターに従います——ファイルパスをハードコードしません。これはリネームやグループ分割にルーターの編集のみが必要で、コードベース全体の検索は不要になることを意味します。

process/context/
├── all-context.md                  ← ルートルーター（アーキテクチャ、スタック、パターン）
├── tests/all-tests.md              ← テストランナー、デバッグ、コマンド
├── container/all-container.md      ← Docker、デプロイ、インフラ手順
├── uxui/all-uxui.md                ← コンポーネント、デザイントークン、ビジュアル規約
└── {domain}/all-{domain}.md        ← 3つ以上の永続ドキュメントがあるドメイン（自動昇格）

自己改善する理由（単なる「リビングドキュメント」ではない）

「リビングドキュメント」というフレーズは通常「更新し続けるつもりだが大抵忘れるドキュメント」を意味します。このシステムは意図を機械的に強制します。

UPDATE PROCESSフェーズは、終了する前にファイルごとのコンテキストレビューを必要とします。 vc-update-process-agentは、潜在的に影響を受けるすべてのコンテキストファイルをファイルごとに具体的な理由でレビューするまでフェーズを終了できません。「更新不要」は許可されます——しかしレビューした各ファイルを名前を挙げて理由を説明しなければなりません。曖昧な理由は拒否されます。チェックポイントは二値：レビューを記録するか、フェーズは終了しないかです。

完了した機能ごとのフルフィードバックループ：

100番目の機能は最初の99で学んだすべてから恩恵を受けます——願望ではなく、機械的な保証として。

前進プレビュー：学びは後ろだけでなく前にも伝わる

すべてのフェーズレポートには、次のフェーズのエージェントのために書かれた## Forward Previewセクションがあります。グリーンを維持するための正確なコマンド、依存関係の変更、フェーズ途中に見つかったファイルスコープの変更を提供します。フェーズ3を引き継ぐエージェントはフェーズ2の出力を再読して何が重要かを推測する必要はありません。集中したブリーフが手渡されます。

これはコンテキストドキュメントとは異なります：コンテキストドキュメントは永続的なナレッジ（機能をまたいで真実であり続ける決定）を保持し；Forward Previewは一時的なハンドオフ状態（次の作業セッションが今すぐ知る必要があること）を保持します。

バリデータースイートが腐敗を防ぐ

永続的なナレッジは誰も確認しないと古くなります。キットはすべてのフェーズクローズアウトの一部として実行されるバリデーターを提供します：

自動チェックのように実行されます——古いまたは孤立したドキュメントは失敗します。システムは自身の健全性を監視します。

コンテキストグループは自己整理する

グループはトピックが3つ以上のドキュメントに達したとき、または単一のファイルが約800行を超えたときに自動的に作成されます。エージェントはルーターに従いパスをハードコードしません——新しいグループ（例：process/context/billing/all-billing.md）を追加するにはルーターの更新のみが必要で、billingに言及するすべてのエージェントへの変更は不要です。ルーターが安定した参照であり；その背後のファイルは自由に再整理できます。

キットは実際のコードベース（vc-setup経由）からコンテキストグループをシードします。グループは固定リストではありません——パターンです。認証エリア、インフラエリア、支払いエリアはそれぞれプロジェクトの成長に合わせてファーストクラスのルーティング可能なナレッジになります。

🤖 中身の紹介

15エージェント

33スキル（自動発見）

⚠️ 命名ルール： 独自のスキルやエージェントにvc-プレフィックスを使用しないでください——そのネームスペースはキット提供ファイル用に予約されており、古いファイル削除ガードが.claude/skills/と.claude/agents/下のあらゆるvc-*パスをキット所有として扱います。代わりにmy-、team-、またはproj-を使用してください。

🪝 10のフック

すべての配置場所：

your-project/
├── .claude/{agents,skills,hooks}/   # 🤖 15エージェント · ⚡ 33スキル · 🪝 10フック
├── .codex/agents/                   # 🔄 Codex用ミラー
├── .agents/skills -> .claude/skills # 🔗 Codex発見用シンボリックリンク
├── CLAUDE.md · AGENTS.md            # 📋 オーケストレーター設定＋クロスツールレジストリ
└── process/
    ├── context/                     # 🧠 自動ルーティングされるナレッジドメイン
    ├── general-plans/               # 📋 横断的なプラン＋タスクフォルダー
    ├── features/                    # 🏷️ フィーチャースコープのライフサイクルフォルダー
    └── development-protocols/       # 📜 22の共有ワークフロードキュメント

⚡ Quick Fix + Fast Mode

フルRIPER-5プロセスが仕事に対して過剰な場合の2つの軽量オプション：

🔄 キットライフサイクル：Install · Setup · Update · Publish

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    TRG["EXECUTE complete\nENTER UPDATE PROCESS MODE"]
    AGT["spawn vc-update-process-agent"]
    A["(a) Archive plan\nactive/ → completed/"]
    B["(b) Update process/context/\nsmallest relevant file\n+ all-context.md router"]
    C["(c) Tier-1 audits\n(change-type gated)"]
    AVC["vc-audit-vc\nharness/agent edits"]
    ACX["vc-audit-context\ncontext-doc edits"]
    APL["vc-audit-plans\nplan/program edits"]
    D["(d) Capture learnings\nto memory"]
    E["(e) Write closeout packet\nvc-generate-closeout"]
    F["(f) Conventional commit\nvc-git-manager"]

    TRG --> AGT --> A --> B --> C
    C --> AVC
    C --> ACX
    C --> APL
    AVC --> D
    ACX --> D
    APL --> D
    D --> E --> F

    style TRG fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style AGT fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style A fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style B fill:#00695C,stroke:#004D40,color:#FFFFFF
    style C fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style AVC fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style ACX fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style APL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style D fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style F fill:#37474F,stroke:#263238,color:#FFFFFF

💡 vc-updateはプレビュー差分を表示してOKを待ちます。process/ディレクトリとプロジェクト固有のコンテンツは決して黙って変更されません。インストールを再実行しても安全に2回実行できます。

💡 うまく動く理由

多くの小さくスマートなデフォルトが積み重なって、手間が減り、コストが下がります。

• 各ロールは必要なツールだけを持ちます。 プランニング中、エージェントは文字通りコードを編集できません——そのツールがオフになっています。これはエージェントがプランが承認される前に先走って変更するのを防ぎます。システムが単純にそれを許しません。

• プレミアムAIモデルを本当に重要な場所だけに使います。 コード作成には最高モデルを使用。プランニング、リサーチ、レビュー、チェックはすべてより安価で速いモデルを使用します。結果：すべてに最高モデルを使う場合と比べて約60〜70%のコスト削減——重要な作業の品質は失わずに。

• 構築前にリスクのある推測をテストします。 エージェントが何かが動作するか確信が持てない場合——特定のAPI動作、ライブラリの機能、インフラの前提——最初に小さな実際の実験を実行します。結果は明確です：動作する、動作しない、または不明。その判定と平易な英語のノートがプランに直接フィードバックされます。エージェントは間違った前提の上に何時間も費やしません。

• きれいで意味のあるセーブポイント。 変更は明確なメッセージを持つ論理的なクリーンなチャンクでコミットされます——自動的に。履歴は読みやすく、1つずつ取り消しやすいです。

• 役立つ自動リマインダー。 小さな組み込みヘルパーが、変更されたファイルに正しいチェックを実行すること、コードをシンプルに保つこと、適切なコミットメッセージを書くことなどを促します。あなたが監視しなくても品質が高く保たれます。

• 自己改善ループを単独で実行できます。 プランチェックとテスト修正を駆動する同じ「問題を見つけ、修正し、繰り返す」エンジンが、どんな雑然とした領域——スペック、ドキュメント、テスト、エラーリスト——にもスタンドアロンツールとして機能します。それを使うためにフルの機能ビルドは必要ありません。

• ワークフロールールが実際に動作することの組み込みの証明。 キットには独自のテストスイートが付属します：ワークフロールールが正しく動作することを証明する既知の良い例と悪い例のセット。システムが自分自身を確認します。ガードレールがオンになっていると信頼する必要はありません——チェックを実行して確認できます。

コントリビュート

コントリビューションを歓迎します！ガイドラインはCONTRIBUTING.mdをご覧ください。

クイックリンク：

• 🐛 バグを報告する
• 💡 機能をリクエストする
• ⚡ スキルを提出する
• 🌐 翻訳を追加する

🙏 クレジット

vibecode-pro-max-kitはスペック駆動の開発フレームワークと自己改善型コンテキスト整理に焦点を当て、80以上のスキルで肥大化させません。ツールは少なく、構造を重視。

⭐ Star History

📄 ライセンス

MIT