@vibe-forge/workspace-assets 3.2.0 → 3.2.1

package/__tests__/__snapshots__/workspace-assets-rich.snapshot.json

@@ -467,7 +467,7 @@
       ]
     },
     "options": {
-      "systemPrompt": "<system-prompt>\nThe project system rules are:\n# review\n\n> 必须检查发布改动的回归风险。\n\n# demo/security\n\n> Use when: 插件安全规则\n> Rule file path: node_modules/@vibe-forge/plugin-demo/rules/security.md\n> Only read this rule file when the task matches the scenario above.\n</system-prompt>\n\n\n<system-prompt>\nThe following skill modules are loaded for the project:\n# research\n\n> Skill description: 检索资料\n> Skill file path: .ai/skills/research/SKILL.md\n> Resolve relative paths in the resource content relative to the directory containing this skill file.\n\n<skill-content>\n先阅读 README.md，再补充结论。\n</skill-content>\n</system-prompt>\n\n\n<system-prompt>\nThe project includes the following entities:\n  - architect: 负责拆解方案的实体\n\nWhen solving user problems, you may start child runtime sessions with `vf run --input-format stream-json --output-format stream-json` and a `session.start` protocol envelope as needed; use `session.status`, `session.events`, and `wait` to track progress.\nAgent runtime guide:\n- Use unified CLI protocol mode, `vf run --input-format stream-json --output-format stream-json`, to start a child runtime session when the work should run in a separate entity or continue independently from the current turn.\n- Send typed runtime protocol envelopes such as `session.start`, `session.message`, `session.status`, `session.events`, `session.submit`, and `session.stop`; do not treat dedicated `vf agent ...` subcommands as the standard integration surface.\n- Ordinary new sessions stay session-scoped. A room is created or discovered only when a unified CLI runtime protocol start command launches a child runtime session from a server-managed host session and the server projects runtime store metadata/events.\n- Do not use MCP task tools, `vf agent ...`, legacy StartTasks, hand-written DB edits, or ad-hoc TS scripts as the task consumer surface. Use CLI protocol mode and the runtime protocol/store for start, status, events, follow-up messages, input submission, and cancellation.\n- Server-managed host sessions inject the current adapter, model, effort, and permission mode as runtime protocol defaults. Omit these fields to inherit the host selection, or set them explicitly only when a child task must use a different runtime profile.\n- Copyable JSONL example; write one `session.start` line per child task, and use multiple lines for multiple subtasks:\n```bash\ncat <<'JSONL' | vf run --input-format stream-json --output-format stream-json\n{\"commandId\":\"start-planner\",\"type\":\"session.start\",\"payload\":{\"title\":\"Plan Agent Room UI fix\",\"message\":\"Plan the frontend changes and tests for the Agent Room UI fix.\",\"entity\":\"dev-planner\",\"background\":true},\"title\":\"Plan Agent Room UI fix\",\"message\":\"Plan the frontend changes and tests for the Agent Room UI fix.\",\"entity\":\"dev-planner\",\"background\":true}\n{\"commandId\":\"start-reviewer\",\"type\":\"session.start\",\"payload\":{\"title\":\"Review Agent Room UI fix\",\"message\":\"Review the implemented Agent Room UI fix for regressions and missing tests.\",\"entity\":\"dev-reviewer\",\"background\":true},\"title\":\"Review Agent Room UI fix\",\"message\":\"Review the implemented Agent Room UI fix for regressions and missing tests.\",\"entity\":\"dev-reviewer\",\"background\":true}\nJSONL\n```\n- Keep `payload.title`, `payload.message`, `payload.entity`, and `payload.background: true` explicit in each start envelope. The mirrored top-level fields make the JSONL executable by the current `vf run` protocol reader.\n- Include a short `title` when the task prompt is long; it becomes the child session title and room run label. Put any room or workspace context in the title and initial message.\n- Read the returned `sessionId` and use it for follow-up protocol commands. Read the latest runtime snapshot from the runtime store or a `session.status` protocol command, and read progress from runtime events or a `session.events` protocol command.\n- Use a follow/read-events workflow when you need to watch progress instead of repeatedly restarting work.\n- Use a `session.message` protocol command to give an existing session another instruction. Running sessions continue immediately; completed or failed sessions resume the same conversation when the runtime allows resume.\n- When the chat UI sends a `[ROOM_TASK_MESSAGE] ... [/ROOM_TASK_MESSAGE]` block, treat it as a runtime relay envelope instead of ordinary prose. Parse the `sessionId` or legacy `taskId`, `message`, and optional `mode` / `request` fields. If the envelope indicates `mode: interaction`, or runtime status shows `waiting_input` / pending input, use a `session.submit` protocol command. Otherwise use `session.message`. Do not reply inline instead of routing the relay.\n- Use `session.submit` only when a runtime session is waiting for an explicit input or approval request. Do not use it for ordinary follow-up instructions.\n- Use a `session.stop` protocol command for graceful cancellation and set `mode` to `force` only when stop cannot recover the session.\n- Compatibility aliases such as `vf agent start/status/events/send/submit/stop` may exist for debugging or legacy scripts, but they are not the primary guidance for new agent workflows.\n- When a session is still making progress, use `wait` between checks and inspect status/events instead of starting a replacement session.\n</system-prompt>\n\n\n<system-prompt>\nYou are a professional project execution manager who can skillfully direct other entities to work toward your goal. Expectations:\n\n- Never complete code development work alone\n- You must coordinate other developers to complete tasks\n- You must keep them aligned with the goal and verify that their completion reports meet the requirements\n\nChoose the appropriate workflow based on the user's needs and the actual development goal, and use the workflow identifier to locate and load the corresponding definition.\n- Pass the identifier based on the actual need. This is not a path; use the standard workflow loading capability to resolve it.\n- Decide how to pass parameters based on their descriptions and actual usage scenarios.\nThe project includes the following workflows:\n- Workflow name: release\n  - Description: 正式发布流程\n  - Identifier: release\n  - Parameters:\n    - None\n\n- Workflow name: demo/release\n  - Description: 插件发布流程\n  - Identifier: demo/release\n  - Parameters:\n    - None\n\n</system-prompt>\n\n\n执行正式发布，并整理变更摘要。",
+      "systemPrompt": "<system-prompt>\nThe project system rules are:\n# review\n\n> 必须检查发布改动的回归风险。\n\n# demo/security\n\n> Use when: 插件安全规则\n> Rule file path: node_modules/@vibe-forge/plugin-demo/rules/security.md\n> Only read this rule file when the task matches the scenario above.\n</system-prompt>\n\n\n<system-prompt>\nThe following skill modules are loaded for the project:\n# research\n\n> Skill description: 检索资料\n> Skill file path: .ai/skills/research/SKILL.md\n> Resolve relative paths in the resource content relative to the directory containing this skill file.\n\n<skill-content>\n先阅读 README.md，再补充结论。\n</skill-content>\n</system-prompt>\n\n\n<system-prompt>\nThe project includes the following entities:\n  - architect: 负责拆解方案的实体\n\nWhen solving user problems, you may start child runtime sessions with `vf run --input-format stream-json --output-format stream-json` and a `session.start` protocol envelope as needed; use `session.status`, `session.events`, and `wait` to track progress.\nAgent runtime guide:\n- Use unified CLI protocol mode, `vf run --input-format stream-json --output-format stream-json`, to start a child runtime session when the work should run in a separate entity or continue independently from the current turn.\n- Send typed runtime protocol envelopes such as `session.start`, `session.message`, `session.status`, `session.events`, `session.submit`, and `session.stop`; do not treat dedicated agent subcommands as the standard integration surface.\n- Ordinary new sessions stay session-scoped. A room is created or discovered only when a unified CLI runtime protocol start command launches a child runtime session from a server-managed host session and the server projects runtime store metadata/events.\n- Do not use MCP task tools, dedicated agent subcommands, legacy StartTasks, hand-written DB edits, or ad-hoc TS scripts as the task consumer surface. Use CLI protocol mode and the runtime protocol/store for start, status, events, follow-up messages, input submission, and cancellation.\n- Server-managed host sessions inject the current adapter, model, effort, and permission mode as runtime protocol defaults. Omit these fields to inherit the host selection, or set them explicitly only when a child task must use a different runtime profile.\n- Copyable JSONL example; write one `session.start` line per child task, and use multiple lines for multiple subtasks:\n```bash\ncat <<'JSONL' | vf run --input-format stream-json --output-format stream-json\n{\"commandId\":\"start-planner\",\"type\":\"session.start\",\"payload\":{\"title\":\"Plan Agent Room UI fix\",\"message\":\"Plan the frontend changes and tests for the Agent Room UI fix.\",\"entity\":\"dev-planner\",\"background\":true},\"title\":\"Plan Agent Room UI fix\",\"message\":\"Plan the frontend changes and tests for the Agent Room UI fix.\",\"entity\":\"dev-planner\",\"background\":true}\n{\"commandId\":\"start-reviewer\",\"type\":\"session.start\",\"payload\":{\"title\":\"Review Agent Room UI fix\",\"message\":\"Review the implemented Agent Room UI fix for regressions and missing tests.\",\"entity\":\"dev-reviewer\",\"background\":true},\"title\":\"Review Agent Room UI fix\",\"message\":\"Review the implemented Agent Room UI fix for regressions and missing tests.\",\"entity\":\"dev-reviewer\",\"background\":true}\nJSONL\n```\n- Keep `payload.title`, `payload.message`, `payload.entity`, and `payload.background: true` explicit in each start envelope. The mirrored top-level fields make the JSONL executable by the current runtime protocol reader.\n- Include a short `title` when the task prompt is long; it becomes the child session title and room run label. Put any room or workspace context in the title and initial message.\n- Read the returned `sessionId` and use it for follow-up protocol commands. Read the latest runtime snapshot from the runtime store or a `session.status` protocol command, and read progress from runtime events or a `session.events` protocol command.\n- Use a follow/read-events workflow when you need to watch progress instead of repeatedly restarting work.\n- Use a `session.message` protocol command to give an existing session another instruction. Running sessions continue immediately; completed or failed sessions resume the same conversation when the runtime allows resume.\n- When the chat UI sends a `[ROOM_TASK_MESSAGE] ... [/ROOM_TASK_MESSAGE]` block, treat it as a runtime relay envelope instead of ordinary prose. Parse the `sessionId` or legacy `taskId`, `message`, and optional `mode` / `request` fields. If the envelope indicates `mode: interaction`, or runtime status shows `waiting_input` / pending input, use a `session.submit` protocol command. Otherwise use `session.message`. Do not reply inline instead of routing the relay.\n- Use `session.submit` only when a runtime session is waiting for an explicit input or approval request. Do not use it for ordinary follow-up instructions.\n- Use a `session.stop` protocol command for graceful cancellation and set `mode` to `force` only when stop cannot recover the session.\n- Compatibility aliases such as dedicated agent start/status/events/send/submit/stop subcommands may exist for debugging or legacy scripts, but they are not the primary guidance for new agent workflows.\n- When a session is still making progress, use `wait` between checks and inspect status/events instead of starting a replacement session.\n</system-prompt>\n\n\n<system-prompt>\nYou are a professional project execution manager who can skillfully direct other entities to work toward your goal. Expectations:\n\n- Never complete code development work alone\n- You must coordinate other developers to complete tasks\n- You must keep them aligned with the goal and verify that their completion reports meet the requirements\n\nChoose the appropriate workflow based on the user's needs and the actual development goal, and use the workflow identifier to locate and load the corresponding definition.\n- Pass the identifier based on the actual need. This is not a path; use the standard workflow loading capability to resolve it.\n- Decide how to pass parameters based on their descriptions and actual usage scenarios.\nThe project includes the following workflows:\n- Workflow name: release\n  - Description: 正式发布流程\n  - Identifier: release\n  - Parameters:\n    - None\n\n- Workflow name: demo/release\n  - Description: 插件发布流程\n  - Identifier: demo/release\n  - Parameters:\n    - None\n\n</system-prompt>\n\n\n执行正式发布，并整理变更摘要。",
       "tools": {
         "include": [
           "Edit",

package/__tests__/prompt-builders.spec.ts

@@ -1,6 +1,7 @@
 import { join } from 'node:path'
+import process from 'node:process'
 
-import { describe, expect, it } from 'vitest'
+import { afterEach, describe, expect, it } from 'vitest'
 
 import {
   generateEntitiesRoutePrompt,
@@ -11,6 +12,16 @@ import {
 } from '#~/prompt-builders.js'
 import { generateWorkspaceRoutePrompt } from '#~/workspace-prompt.js'
 
+const originalCliResumeCommandPrefix = process.env.__VF_CLI_RESUME_COMMAND_PREFIX__
+
+afterEach(() => {
+  if (originalCliResumeCommandPrefix == null) {
+    delete process.env.__VF_CLI_RESUME_COMMAND_PREFIX__
+  } else {
+    process.env.__VF_CLI_RESUME_COMMAND_PREFIX__ = originalCliResumeCommandPrefix
+  }
+})
+
 describe('workspace asset prompt builders', () => {
   it('builds skill prompts with stable names, descriptions, and relative paths', () => {
     const cwd = '/tmp/project'
@@ -184,10 +195,10 @@ describe('workspace asset prompt builders', () => {
     expect(prompt).toContain('"background":true')
     expect(prompt).toContain('write one `session.start` line per child task')
     expect(prompt).toContain('typed runtime protocol envelopes')
-    expect(prompt).toContain('do not treat dedicated `vf agent ...` subcommands as the standard integration surface')
+    expect(prompt).toContain('do not treat dedicated agent subcommands as the standard integration surface')
     expect(prompt).toContain('Read the returned `sessionId`')
     expect(prompt).toContain('Ordinary new sessions stay session-scoped')
-    expect(prompt).toContain('Do not use MCP task tools, `vf agent ...`, legacy StartTasks')
+    expect(prompt).toContain('Do not use MCP task tools, dedicated agent subcommands, legacy StartTasks')
     expect(prompt).toContain('hand-written DB edits')
     expect(prompt).toContain('ad-hoc TS scripts')
     expect(prompt).toContain('server-managed host session')
@@ -237,6 +248,22 @@ describe('workspace asset prompt builders', () => {
     expect(prompt).not.toContain('VibeForge.StartTasks')
   })
 
+  it('uses forwarded cli names in managed task guidance', () => {
+    process.env.__VF_CLI_RESUME_COMMAND_PREFIX__ = 'dyai'
+
+    const prompt = generateEntitiesRoutePrompt([
+      {
+        path: '/tmp/project/.ai/entities/reviewer/README.md',
+        body: '负责代码审查',
+        attributes: {}
+      }
+    ])
+
+    expect(prompt).toContain('`dyai run --input-format stream-json --output-format stream-json`')
+    expect(prompt).toContain("cat <<'JSONL' | dyai run --input-format stream-json --output-format stream-json")
+    expect(prompt).not.toContain('`vf run --input-format stream-json --output-format stream-json`')
+  })
+
   it('builds skill route prompts without preloading content', () => {
     const cwd = '/tmp/project'
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibe-forge/workspace-assets",
-  "version": "3.2.0",
+  "version": "3.2.1",
   "description": "Workspace asset resolution and adapter asset planning for Vibe Forge",
   "imports": {
     "#~/*.js": {
@@ -29,10 +29,10 @@
     "fast-glob": "^3.3.3",
     "front-matter": "^4.0.2",
     "js-yaml": "^4.1.1",
-    "@vibe-forge/types": "3.2.0",
     "@vibe-forge/definition-core": "3.2.0",
-    "@vibe-forge/utils": "3.2.0",
-    "@vibe-forge/config": "3.2.0"
+    "@vibe-forge/config": "3.2.2",
+    "@vibe-forge/types": "3.2.2",
+    "@vibe-forge/utils": "3.2.2"
   },
   "devDependencies": {
     "@types/js-yaml": "^4.0.9"

package/src/bundle-internal.ts

@@ -10,7 +10,7 @@ import {
 } from '@vibe-forge/config'
 import type { Config, Definition, Entity, PluginConfig, WorkspaceAsset, WorkspaceAssetKind } from '@vibe-forge/types'
 import {
-  isLegacySkillsConfig,
+  isObjectSkillsConfig,
   resolveProjectAiBaseDir,
   resolveProjectAiEntitiesDir,
   resolveRelativePath
@@ -159,8 +159,8 @@ const warnInvalidHomeSkillRoot = (root: string) => {
 
 const resolveHomeBridgeConfig = (configs: [Config?, Config?]) => {
   const [config, userConfig] = configs
-  const projectHomeBridge = isLegacySkillsConfig(config?.skills) ? config.skills.homeBridge : undefined
-  const userHomeBridge = isLegacySkillsConfig(userConfig?.skills) ? userConfig.skills.homeBridge : undefined
+  const projectHomeBridge = isObjectSkillsConfig(config?.skills) ? config.skills.homeBridge : undefined
+  const userHomeBridge = isObjectSkillsConfig(userConfig?.skills) ? userConfig.skills.homeBridge : undefined
 
   return {
     enabled: userHomeBridge?.enabled ?? projectHomeBridge?.enabled ?? true,

package/src/configured-skills.ts

@@ -6,7 +6,8 @@ import {
   installProjectSkill,
   normalizeProjectSkillInstall,
   resolveConfiguredSkillInstalls as resolveDeclaredConfiguredSkillInstalls,
-  resolveProjectAiPath
+  resolveProjectAiPath,
+  resolveSkillsRegistry
 } from '@vibe-forge/utils'
 import type { NormalizedProjectSkillInstall } from '@vibe-forge/utils'
 
@@ -47,6 +48,8 @@ export const ensureConfiguredProjectSkills = async (params: {
   updateInstalledSkills?: boolean
   workspaceFolder: string
 }) => {
+  const defaultRegistry = resolveSkillsRegistry(params.configs[1]?.skills) ??
+    resolveSkillsRegistry(params.configs[0]?.skills)
   const installs = resolveConfiguredSkillInstalls(params.configs)
   if (installs.length === 0) {
     return []
@@ -75,6 +78,7 @@ export const ensureConfiguredProjectSkills = async (params: {
     ensured.push(
       await installProjectSkill({
         force: true,
+        registry: defaultRegistry,
         skill,
         workspaceFolder: params.workspaceFolder
       })

package/src/prompt-builders.ts

@@ -7,7 +7,7 @@ import {
 import type { Definition, Entity, Rule, Skill, Spec } from '@vibe-forge/types'
 import { resolvePromptPath } from '@vibe-forge/utils'
 
-import { buildManagedTaskToolGuidance } from './task-tool-guidance'
+import { buildManagedTaskToolGuidance, resolveRuntimeProtocolCliCommand } from './task-tool-guidance'
 
 const toMarkdownBlockquote = (content: string) => (
   content
@@ -168,6 +168,8 @@ export const generateSpecRoutePrompt = (
 
 export const generateEntitiesRoutePrompt = (entities: Definition<Entity>[]) => {
   const taskToolGuidance = buildManagedTaskToolGuidance()
+  const runtimeProtocolCommand =
+    `${resolveRuntimeProtocolCliCommand()} --input-format stream-json --output-format stream-json`
   return (
     '<system-prompt>\n' +
     'The project includes the following entities:\n' +
@@ -181,7 +183,7 @@ export const generateEntitiesRoutePrompt = (entities: Definition<Entity>[]) => {
         })
         .join('')
     }\n` +
-    'When solving user problems, you may start child runtime sessions with `vf run --input-format stream-json --output-format stream-json` and a `session.start` protocol envelope as needed; use `session.status`, `session.events`, and `wait` to track progress.\n' +
+    `When solving user problems, you may start child runtime sessions with \`${runtimeProtocolCommand}\` and a \`session.start\` protocol envelope as needed; use \`session.status\`, \`session.events\`, and \`wait\` to track progress.\n` +
     `${taskToolGuidance}\n` +
     '</system-prompt>\n'
   )

package/src/skills-cli-dependency.ts

@@ -3,6 +3,7 @@ import { resolve } from 'node:path'
 import process from 'node:process'
 
 import type { Config } from '@vibe-forge/types'
+import { isObjectSkillsConfig, resolveSkillsRegistry } from '@vibe-forge/utils'
 import { findSkillsCli, installSkillsCliRefToTemp, installSkillsCliSkillToTemp } from '@vibe-forge/utils/skills-cli'
 
 import type { NormalizedSkillDependency } from './skill-dependencies'
@@ -17,7 +18,11 @@ import {
 const resolveAutoDownloadDependenciesEnabled = (
   projectConfig: Config | undefined,
   userConfig: Config | undefined
-) => userConfig?.skills?.autoDownloadDependencies ?? projectConfig?.skills?.autoDownloadDependencies ?? true
+) => (
+  (isObjectSkillsConfig(userConfig?.skills) ? userConfig.skills.autoDownloadDependencies : undefined) ??
+    (isObjectSkillsConfig(projectConfig?.skills) ? projectConfig.skills.autoDownloadDependencies : undefined) ??
+    true
+)
 
 export const installSkillsCliDependency = async (params: {
   cwd: string
@@ -26,6 +31,9 @@ export const installSkillsCliDependency = async (params: {
 }) => {
   const [projectConfig, userConfig] = params.configs
   const autoDownloadDependenciesEnabled = resolveAutoDownloadDependenciesEnabled(projectConfig, userConfig)
+  const defaultRegistry = resolveSkillsRegistry(params.configs[1]?.skills) ??
+    resolveSkillsRegistry(params.configs[0]?.skills)
+  const registry = params.dependency.registry ?? defaultRegistry
   const resolvedTarget = await (async () => {
     if (params.dependency.source != null) {
       return {
@@ -42,7 +50,7 @@ export const installSkillsCliDependency = async (params: {
 
     return await (async () => {
       const searchResults = await findSkillsCli({
-        registry: params.dependency.registry,
+        registry,
         query: params.dependency.name
       })
       const selected = pickSearchResult(searchResults, params.dependency.name)
@@ -60,7 +68,7 @@ export const installSkillsCliDependency = async (params: {
 
   const installDir = buildInstallDir({
     cwd: params.cwd,
-    registry: params.dependency.registry,
+    registry,
     skill: resolvedTarget.skill,
     source: resolvedTarget.source,
     version: params.dependency.version
@@ -87,16 +95,16 @@ export const installSkillsCliDependency = async (params: {
       ? params.dependency.version == null
         ? await installSkillsCliRefToTemp({
           installRef: resolvedTarget.installRef,
-          registry: params.dependency.registry
+          registry
         })
         : await installSkillsCliSkillToTemp({
-          registry: params.dependency.registry,
+          registry,
           skill: resolvedTarget.skill,
           source: resolvedTarget.source,
           version: params.dependency.version
         })
       : await installSkillsCliSkillToTemp({
-        registry: params.dependency.registry,
+        registry,
         skill: resolvedTarget.skill,
         source: resolvedTarget.source,
         version: params.dependency.version

package/src/task-tool-guidance.ts

@@ -1,19 +1,32 @@
+import process from 'node:process'
+
+export const resolveRuntimeProtocolCliCommand = (env: NodeJS.ProcessEnv = process.env) => {
+  const prefix = env.__VF_CLI_RESUME_COMMAND_PREFIX__?.trim()
+  if (prefix == null || prefix === '') {
+    return 'vf run'
+  }
+  return prefix.split(/\s+/).at(-1) === 'run' ? prefix : `${prefix} run`
+}
+
 export const buildManagedTaskToolGuidance = () => {
+  const runtimeCliCommand = resolveRuntimeProtocolCliCommand()
+  const runtimeProtocolCommand = `${runtimeCliCommand} --input-format stream-json --output-format stream-json`
+
   return [
     'Agent runtime guide:',
-    '- Use unified CLI protocol mode, `vf run --input-format stream-json --output-format stream-json`, to start a child runtime session when the work should run in a separate entity or continue independently from the current turn.',
-    '- Send typed runtime protocol envelopes such as `session.start`, `session.message`, `session.status`, `session.events`, `session.submit`, and `session.stop`; do not treat dedicated `vf agent ...` subcommands as the standard integration surface.',
+    `- Use unified CLI protocol mode, \`${runtimeProtocolCommand}\`, to start a child runtime session when the work should run in a separate entity or continue independently from the current turn.`,
+    '- Send typed runtime protocol envelopes such as `session.start`, `session.message`, `session.status`, `session.events`, `session.submit`, and `session.stop`; do not treat dedicated agent subcommands as the standard integration surface.',
     '- Ordinary new sessions stay session-scoped. A room is created or discovered only when a unified CLI runtime protocol start command launches a child runtime session from a server-managed host session and the server projects runtime store metadata/events.',
-    '- Do not use MCP task tools, `vf agent ...`, legacy StartTasks, hand-written DB edits, or ad-hoc TS scripts as the task consumer surface. Use CLI protocol mode and the runtime protocol/store for start, status, events, follow-up messages, input submission, and cancellation.',
+    '- Do not use MCP task tools, dedicated agent subcommands, legacy StartTasks, hand-written DB edits, or ad-hoc TS scripts as the task consumer surface. Use CLI protocol mode and the runtime protocol/store for start, status, events, follow-up messages, input submission, and cancellation.',
     '- Server-managed host sessions inject the current adapter, model, effort, and permission mode as runtime protocol defaults. Omit these fields to inherit the host selection, or set them explicitly only when a child task must use a different runtime profile.',
     '- Copyable JSONL example; write one `session.start` line per child task, and use multiple lines for multiple subtasks:',
     '```bash',
-    "cat <<'JSONL' | vf run --input-format stream-json --output-format stream-json",
+    `cat <<'JSONL' | ${runtimeProtocolCommand}`,
     '{"commandId":"start-planner","type":"session.start","payload":{"title":"Plan Agent Room UI fix","message":"Plan the frontend changes and tests for the Agent Room UI fix.","entity":"dev-planner","background":true},"title":"Plan Agent Room UI fix","message":"Plan the frontend changes and tests for the Agent Room UI fix.","entity":"dev-planner","background":true}',
     '{"commandId":"start-reviewer","type":"session.start","payload":{"title":"Review Agent Room UI fix","message":"Review the implemented Agent Room UI fix for regressions and missing tests.","entity":"dev-reviewer","background":true},"title":"Review Agent Room UI fix","message":"Review the implemented Agent Room UI fix for regressions and missing tests.","entity":"dev-reviewer","background":true}',
     'JSONL',
     '```',
-    '- Keep `payload.title`, `payload.message`, `payload.entity`, and `payload.background: true` explicit in each start envelope. The mirrored top-level fields make the JSONL executable by the current `vf run` protocol reader.',
+    '- Keep `payload.title`, `payload.message`, `payload.entity`, and `payload.background: true` explicit in each start envelope. The mirrored top-level fields make the JSONL executable by the current runtime protocol reader.',
     '- Include a short `title` when the task prompt is long; it becomes the child session title and room run label. Put any room or workspace context in the title and initial message.',
     '- Read the returned `sessionId` and use it for follow-up protocol commands. Read the latest runtime snapshot from the runtime store or a `session.status` protocol command, and read progress from runtime events or a `session.events` protocol command.',
     '- Use a follow/read-events workflow when you need to watch progress instead of repeatedly restarting work.',
@@ -21,7 +34,7 @@ export const buildManagedTaskToolGuidance = () => {
     '- When the chat UI sends a `[ROOM_TASK_MESSAGE] ... [/ROOM_TASK_MESSAGE]` block, treat it as a runtime relay envelope instead of ordinary prose. Parse the `sessionId` or legacy `taskId`, `message`, and optional `mode` / `request` fields. If the envelope indicates `mode: interaction`, or runtime status shows `waiting_input` / pending input, use a `session.submit` protocol command. Otherwise use `session.message`. Do not reply inline instead of routing the relay.',
     '- Use `session.submit` only when a runtime session is waiting for an explicit input or approval request. Do not use it for ordinary follow-up instructions.',
     '- Use a `session.stop` protocol command for graceful cancellation and set `mode` to `force` only when stop cannot recover the session.',
-    '- Compatibility aliases such as `vf agent start/status/events/send/submit/stop` may exist for debugging or legacy scripts, but they are not the primary guidance for new agent workflows.',
+    '- Compatibility aliases such as dedicated agent start/status/events/send/submit/stop subcommands may exist for debugging or legacy scripts, but they are not the primary guidance for new agent workflows.',
     '- When a session is still making progress, use `wait` between checks and inspect status/events instead of starting a replacement session.'
   ].join('\n')
 }

package/src/workspace-prompt.ts

@@ -1,7 +1,7 @@
 import type { WorkspaceDefinitionPayload } from '@vibe-forge/types'
 import { resolvePromptPath } from '@vibe-forge/utils'
 
-import { buildManagedTaskToolGuidance } from './task-tool-guidance'
+import { buildManagedTaskToolGuidance, resolveRuntimeProtocolCliCommand } from './task-tool-guidance'
 
 export const generateWorkspaceRoutePrompt = (
   cwd: string,
@@ -9,6 +9,8 @@ export const generateWorkspaceRoutePrompt = (
 ) => {
   if (workspaces.length === 0) return ''
   const taskToolGuidance = buildManagedTaskToolGuidance()
+  const runtimeProtocolCommand =
+    `${resolveRuntimeProtocolCliCommand()} --input-format stream-json --output-format stream-json`
 
   const workspaceList = workspaces
     .map((workspace) => {
@@ -25,7 +27,7 @@ export const generateWorkspaceRoutePrompt = (
     '<system-prompt>\n' +
     'The project includes the following registered workspaces:\n' +
     `${workspaceList}\n` +
-    'When a user request targets one of these workspaces, start a child runtime session with `vf run --input-format stream-json --output-format stream-json` and a `session.start` envelope; include the workspace identifier and path in the title and message. ' +
+    `When a user request targets one of these workspaces, start a child runtime session with \`${runtimeProtocolCommand}\` and a \`session.start\` envelope; include the workspace identifier and path in the title and message. ` +
     'Do not directly edit files inside a registered workspace from the current session unless the user explicitly asks this session to work in that directory.\n' +
     `${taskToolGuidance}\n` +
     '</system-prompt>\n'