메뉴
VP の Conductor × Performer × Memory orchestration による開発フロー — hearing → 議論 → spec memory → performer handoff → 並列追跡 → merge の 6 phase。 「並列開発」 「conductor performer」 「handoff」 「並列 performer」 「control surrender」 「dev flow」 等のキーワードで invoke
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | dev-flow |
| description | VP の Conductor × Performer × Memory orchestration による開発フロー — hearing → 議論 → spec memory → performer handoff → 並列追跡 → merge の 6 phase。 「並列開発」 「conductor performer」 「handoff」 「並列 performer」 「control surrender」 「dev flow」 等のキーワードで invoke |
| version | 0.3.3 |
| tags | ["dev-flow","orchestration","conductor-performer","memory-first","parallel-dev","handoff","control-surrender"] |
AI ネイティブ開発フロー — VP の lane (= conductor + performer) + wiremsg + creo memory が揃ったことで物理的に成立した「conductor で idea / 議論を練り、 performer に handoff、 conductor が orchestrate」 手法。 chronista-style と統合した formalization。
伝統的 dev = code 書く / PR / merge、 spec は markdown / 議論は Slack / trail は git log で分散。 VP × creo は memory を背骨に、 lane を実行体に、 wire を transport にして 1 つの orchestrated stream に統合する。
詳細仕様: creo memory mem_1CbUUzvguCptQPU4eWTKHx (= 本 skill の canonical reference)
用語注: VP は performer を 1 用語に統一する。 「worker」 / 「wing」 は旧称 — VP の文脈には存在しない。 役割 / 動的主体としても performer そのものが立つ (= 「performer が question を投げる」 「performer が completed を報告する」)。 performer = lane-cloned worktree + echoes claude session を含む環境 + 動的主体の合成体。 orchestration 側は conductor (= 旧 lead)。
address 注 (VP v0.40+):
- wire address (=
wire_send宛先):agent@<project>(conductor) /agent@<project>/<performer-name>(performer)- lane address (=
lane_nudge/switch_lane):<project>/conductor/<project>/performer/<name>
hearing で要件抽出 (= chronista-style:hearing)council で多角検証 (= 4 voice)mode field で自己認識kind field) ┌─ idle (= echoes 起動済、 task 未受領)
│
▼ conductor 「task」 wire
working (= performer 作業中、 conductor 介入なし) ← control 手放してる
│
├─→ hitl_pending (= performer 「question」 wire 送信、 conductor reply 待ち) ← control 手放してない
│ │ conductor 「approve/modify/clarify」 wire
│ ▼
│ working (= 自走再開) ← control 再 surrender
│
├─→ awaiting_user (= performer 「needs_user」 wire、 **ユーザ本人**の回答待ち) ← sidebar needs-you (magenta diamond)
│ │ user 回答 → conductor reply
│ ▼
│ working (= 自走再開)
│
└─→ completed (= performer 「complete」 wire、 conductor review 待ち) ← conductor に control 戻る
│
▼ merge
merged / closed
│
stuck (= dirty_count あり + last_commit なし、 詰まってる可能性) ← conductor 介入候補
awaiting_userは 2026-07-11 追加 (=hitl_pendingが conductor 待ちなのに対し、 conductor では代答できないユーザ本人待ちの別軸)。Act II HITL rail (VP v0.45): HITL 4 面 (= ①質問 ②中断 ③permission ④plan 承認、 doc 35) が完成し、 performer の echoes (Act II chat GUI) では native
AskUserQuestion/ permission prompt /ExitPlanModeが GUI の PromptCard / PermissionCard / PlanCard として直接ユーザに届く (sidebar needs-you も点灯)。 wireneeds_userrail (= conductor 経由、 上図) と並存する GUI 直通 rail — ユーザが lane を開いていれば GUI で即答でき、 開いていなくても sidebar 点灯で気付ける。
VP v0.40+ では flow_progress (= MCP mcp__vantage-point__flow_progress / CLI vp flow progress) が server 側で derive し、 各 performer に flow_state / control_surrender / state_reason / performer_status / unread_wire_count を返す。 下記は概念 model (= wire pattern からの derive 規則) であり、 手動で組み立てる場合の reference:
fn flow_state(performer: &PerformerState, thread: &[WireMsg]) -> FlowState {
let last_msg = thread.last();
match (last_msg, performer.dirty_count > 0, performer.last_commit) {
(None, _, _) => FlowState::Idle,
(Some(m), _, _) if m.from == conductor && m.kind == "task" => FlowState::Working,
(Some(m), _, _) if m.from == performer && m.kind == "question" => FlowState::HitlPending,
// 未 ack の needs_user が存在 → ユーザ本人待ち (conductor 待ちの HitlPending とは別軸)
(Some(m), _, _) if m.from == performer && m.kind == "needs_user" => FlowState::AwaitingUser,
(Some(m), _, _) if m.from == performer && m.kind == "complete" => FlowState::Completed,
(Some(m), true, None) if m.from == conductor => FlowState::Stuck,
_ => FlowState::Working,
}
}
// control_surrender = true iff state ∈ {Working, Completed} && (last_msg.from == performer || last_msg is None)
kind taxonomy (= state derivation の入力)| kind | from | 意味 |
|---|---|---|
task | conductor → performer | 初手 handoff spec |
question | performer → conductor | 質問 / decision 依頼 |
needs_user | performer → conductor | ユーザ本人の判断/回答が要る (conductor では代答不可)。 未 ack で awaiting_user が立つ |
ack | performer → conductor | 受領 / progress |
decision | performer → conductor | 自己判断 表明 |
approve / modify / clarify | conductor → performer | reply |
complete | performer → conductor | 完了報告 |
request | performer → conductor | action 依頼 (= dogfood 等) |
Phase 1: idea / hearing → spark memory (status:spark)
↓
Phase 2: 議論 / refinement → status:in-progress + annotate trail (= voice)
↓
Phase 3: spec 確定 → status:done memory (= derivedFrom / extends で lineage)
↓
Phase 4: 分解 + performer handoff → flow_handoff (= 推奨) or lane new + wire_send + lane_nudge
↓
Phase 5: 並列追跡 → flow_progress (+ wire_recv / wire_inbox で詳細)
↓ ↑
│ │ HITL escalation (= performer question wire)
↓
Phase 6: 統合 + merge → PR review (moody-blues / santa-method) → merge → retrospect memory
│
└→ learnings → Phase 1 へ feedback loop
各 phase が memory に stream で trail、 後 session が context-engine 経由で auto-load。
| mode | 条件 | 例 |
|---|---|---|
| auto (= control 手放す) | spec 明確 / ambiguity 少 / test-driven / 既知 pattern | fmt fix、 単純 refactor、 docs update、 schema migration boilerplate |
| HITL (= control 握る) | 設計判断含む / spec 内 ambiguity / dogfood feedback 要 | 新 architecture、 schema 設計、 UX 判断、 API 変更 |
動的 shift trigger:
| tool | layer | 用途 |
|---|---|---|
mcp__vantage-point__flow_handoff / vp flow handoff | handoff | performer 作成 + wire_send + lane_nudge を atomic (= 失敗時 rollback)。 二重 dispatch は creation reservation で防止 (v0.45) |
mcp__vantage-point__flow_progress / vp flow progress | state | 全 performer の git status + unread wire + flow_state / control_surrender 集約 view |
mcp__vantage-point__add_performer / vp lane new | performer 作成 | lane clone + echoes spawn (handoff 使わない場合の低レベル操作) |
mcp__vantage-point__wire_send / vp wire send | message | thread 化 inter-agent msg (= reply_to で chain、body.category で delivery policy) |
mcp__vantage-point__wire_recv / vp wire recv | message | inbox から msg 取得 (= read cursor 進む) |
mcp__vantage-point__wire_inbox / vp wire inbox | message | 未読数だけ確認 (= cursor 不触り、 P5 の軽量ポーリング向け) |
mcp__vantage-point__wire_ack / vp wire ack | message | category: command msg の受領確認 (= delivery loop 再掲示を止める) |
vp lane nudge (CLI のみ、 MCP tool は無い) | nudge | performer / conductor に text + Enter 注入 (旧 tmux send-keys) |
mcp__vantage-point__list_lanes / vp lane ls --detail | routing | Lane 一覧 + performer_status / mailbox_addresses (wire 宛先解決) |
mcp__vantage-point__show | view | PP (Paisley Park) に構想 visualize (= HTML / markdown / image) |
mcp__creo-memories__remember | persist | memory trail (= atlas + tags + supersedes) |
gh pr merge --auto --squash | ship | CI 通過後自動 merge |
補助 primitive (単発委譲向け、 wire handoff と併用可):
delegate / complete / respond — async future 型の task 委譲 (= doer が complete で報告、 requester は spin-wait 不要)| skill | dev flow phase |
|---|---|
hearing | P1 (= 要件抽出) |
codeflow | P1-4 orchestrate (= ヒアリング → SDG → 実装) |
spec-design-guide | P3 (= Why/What/How を memory に) |
council | P2 (= 4 voice 合議) |
sex-pistols | P4 (= 並列 performer dispatch、 6 unit coordinate) |
santa-method | P6 (= 2 reviewer 独立検証) |
route | P3-4 (= goal までの path 探索) |
agent-introspection | P5 (= performer failure self-debug) |
size-stepper | P4-5 (= $variables 演奏、 spec interaction = music) |
flow_handoff (1 call)vp flow handoff <slug> --task-spec <file-or->
# or mcp__vantage-point__flow_handoff
# name: "<slug>"
# task_spec: "<markdown 仕様>"
# mode: "auto" | "hitl" # default: hitl
# branch: "<user>/<slug>" # 省略可 (auto-derive)
# nudge: true # false = 完全 async (CLI flag は --no-nudge)
→ add_performer + wire_send + lane_nudge を atomic 実行。 失敗時は performer rollback。
vp lane new <slug> <user>/<slug>
→ performer dir 作成 + echoes auto spawn
→ zero-config で .mcp.json / CLAUDE.local.md / .env auto-symlink
mcp__vantage-point__wire_send
to: ["agent@<project>/<slug>"]
body: {
kind: "task",
category: "command", // default: command (= wire_ack まで再掲示)
title: "...",
task_spec: "<markdown 仕様>",
mode: "auto" | "hitl",
priority: "high",
scope_outs: ["..."]
}
vp lane nudge <project>/performer/<slug> \
"conductor から task が届いています。 mcp__vantage-point__wire_recv で確認して着手。"
mcp__vantage-point__flow_progress → flow_state / control_surrender / performer_status / unread_wire_count
mcp__vantage-point__wire_inbox → 未読数だけ軽量確認 (cursor 不触り)
mcp__vantage-point__wire_recv → performer question / 完了報告の本文取得
mcp__vantage-point__wire_ack → command msg 処理後に ack
mcp__vantage-point__wire_send
to: ["agent@<project>/<slug>"]
reply_to: "<performer msg id>"
body: { kind: "approve" | "modify" | "clarify", category: "command", ... }
→ control 再 surrender (= performer 自走に戻る)
6 phase + control surrender awareness のフル一周実演:
| phase | 出来事 |
|---|---|
| P1 | dogfood 摩擦: VP repo で vp lane new が .claude/wing-files.kdl 不在で hard fail |
| P2 | ヒアリング: principle 8 個確定 (= visible-first / blocklist / toggle / search 全 file 等) → ultrathink で paradigm shift 議論 (= KDL Ruby × creo Schema Registry × Projection Engine) |
| P3 | spec 確定: 4 段 pivot を decision memory mem_1CbUPuphWcEQq39MGX8k7z で記録 |
| P4 | 4 performer handoff: nexus-server (= VP federation hub server scaffold) / pp-content-persist (= PP state SurrealDB 永続化) / mcp-cli-audit (= mcp ↔ cli pair gap 埋め) / flow-tools (= dev-flow primitives 実装) |
| P5 | 並列追跡: list_lanes で performer_status 確認、 wire_recv で question 受信、 thread reply で approve。 各 performer の control 状態を 6 state FSM で識別 |
| P6 | merge pending: PR #460 (XDG) + PR #461 (zero-config) auto-merge 仕掛け中、 nexus-server PR #466 merge 済 (= autonomous 完結) |
特徴:
memory は dev flow の 背骨:
従来: spec は markdown / 議論は Slack / trail は git log で分散。 新: idea → 議論 → spec → 実装 → review → learn が 全部 memory で trail、 conductor / performer / cross-project が同 memory graph に access、 AI agent が一級市民として参加。
3 つ揃って「人 + AI が pair で開発する environment」 が物理的に成立。
conductor の orchestration = 「どの performer から control を手放し、 どこで握り直すか」 の判断連鎖。 6 state FSM で wire pattern から derive、 conductor は performer 群の control 状態を一望し、 必要な performer にだけ介入する。 これは 「複数 performer を同時並走させながら conductor の認知 cost を一定に保つ」 構造で、 並列 dev の規模拡張を可能化。
mem_1CbUUzvguCptQPU4eWTKHx (= 本 skill の dev-flow overview)mem_1CbUPuphWcEQq39MGX8k7z (= creo × KDL Ruby × Projection Engine 構想、 本 flow の future state)hearing / codeflow / council / sex-pistols / santa-method / route / agent-introspection / size-stepperscope 拡大時に hybrid 分割: