cowork-flow 0.0.29 → 0.0.30

package/README.md

@@ -342,3 +342,9 @@ npm run release -- prerelease
 ```
 
 脚本会在任一步骤失败时停止后续发布动作。CI 仍会运行 Node CLI 测试、npm pack 内容检查和现有 Python 模板测试；GitHub Actions 的 `Publish npm Package` workflow 仍需要在仓库 secrets 中配置 `NPM_TOKEN`。
+
+可选集成测试位于 `tests/integration/`，依赖 Python 环境中的 `pytest`。它不属于默认发布链；需要验证时运行：
+
+```bash
+npm run test:integration
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cowork-flow",
-  "version": "0.0.29",
+  "version": "0.0.30",
   "description": "CLI for installing and maintaining cowork-flow collaboration templates.",
   "type": "module",
   "bin": {
@@ -17,6 +17,7 @@
   "scripts": {
     "test": "node --test",
     "test:template": "node scripts/run-template-tests.js",
+    "test:integration": "node scripts/run-integration-tests.js",
     "pack:check": "node scripts/pack-check.js",
     "test:all": "npm test && npm run test:template && npm run pack:check",
     "release": "sh scripts/release.sh"

package/src/lib/copy-template.js

@@ -47,14 +47,17 @@ export async function buildInitPlan(targetDir, options = {}) {
       continue;
     }
 
-    if (toTemplatePath(file) === '.cowork-flow/.version') {
+    const templatePath = toTemplatePath(file);
+    if (templatePath === '.cowork-flow/.version') {
       continue;
     }
 
     const source = join(templateRoot, file);
     const destination = join(targetDir, file);
     const exists = await pathExists(destination);
-    const action = exists ? (options.force ? 'update' : 'skip') : 'create';
+    const action = exists
+      ? (options.force && templatePath !== '.cowork-flow/.developer' ? 'update' : 'skip')
+      : 'create';
     actions.push({ action, source, destination, relativePath: file });
   }
 

package/template/.agents/skills/before-dev/SKILL.md

@@ -1,32 +1,144 @@
 ---
 name: before-dev
-description: Use before writing code in a cowork-flow project to load project-specific guidelines, active task context, and verification expectations.
+description: MANDATORY GATE — call before ANY code change, file edit, or subagent dispatch. Checks workflow state and either allows or blocks the action.
 ---
 
-# Before Dev
+# Before Dev — 编码前工作流门禁
 
-Use this immediately before code edits.
+This skill is the enforcement point for the cowork-flow workflow. You MUST invoke it
+before any file edit, code change, or subagent dispatch. It reads the current
+`<workflow-state>` block and decides whether to allow or block.
 
-## Read
+This skill is NOT a checklist or context loader — it is a gate. Do not proceed to
+code changes without passing through this gate.
 
-1. `AGENTS.md`
-2. `.cowork-flow/workflow.md`
-3. Active task `prd.md`
-4. Active task `implement.jsonl`
-5. Relevant `.cowork-flow/spec/*/index.md`
-6. Any exact files named by the task, plan, or user
-7. If the task changes behavior, locate or create `tdd.jsonl` evidence before implementation.
+**豁免**: 只读问答、纯查询命令（`git status`、`task next`、`task current`）、
+用户明确说"直接改，跳过流程"。
 
-Do not bulk-load unrelated tasks, archived sessions, or every spec file.
+---
+
+## Step 1: 读取当前 workflow 状态
+
+从上下文中读取 `<workflow-state>` 块。关注 `Status` 和 `Source` 字段。
+
+如果上下文中**没有** `<workflow-state>` 块，说明当前平台的 hook/plugin 未向此上下文注入状态。
+此时检查用户 prompt 中是否包含 `cowork_runtime_context_id`：
+
+- **有 `cowork_runtime_context_id`** → 你是通过 prompt transport 接收 runtime context 的子代理，但平台 hook 未注入 workflow-state。直接进入下方的 `delegated_subtask` 分支，执行 bind、加载任务、完成叶子工作。
+- **无 `cowork_runtime_context_id`** → 无法判断当前上下文身份。
+
+回复：
+```
+无法从上下文中确定 workflow 状态（无 <workflow-state> 块，无 runtime context ID）。
+请运行 resume 恢复任务状态，或运行 task start 创建新任务。
+```
+
+这是 fail-closed 回退——只在 Codex/OpenCode hook 正常工作时永不触发。
+
+## Step 2: 按状态执行
+
+### Status = `no_task`
+
+**⛔ 阻断。** 当前没有活动任务。
+
+你必须**拒绝**执行任何代码变更、文件编辑、子代理派发。回复用户：
+
+```
+当前没有活动任务。实现、重构或行为变更必须先创建任务。
+
+建议:
+1. 新需求方向不明确 → 先 brainstorming 明确方向
+2. 需求已明确 → writing-plans → task create → task start
+3. 恢复已有任务 → continue
+
+要走哪个方向？
+```
+
+只读问答可以直接回答，但不要修改任何文件。
+
+### Status = `delegated_subtask`
+
+你是子代理。按 bound runtime context 执行：
+- 运行 `./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>` 绑定
+- 加载任务目录和分配内容
+- 不要执行 start/resume/task start/task archive/commit/spawn
+- 完成分配的叶子工作
+
+### Status = `planning`
+
+**⛔ 阻断实现。** 任务在计划阶段，尚未就绪。
+
+回复用户：
+
+```
+任务仍在计划阶段，尚未就绪进入实现。
+
+需要先:
+1. 完善 prd.md（目标、范围、验收标准）
+2. 整理 implement.jsonl 和 check.jsonl
+3. 运行 task next 确认准备状态
+4. 运行 task start 进入实现阶段
+
+现在继续计划工作？
+```
+
+**例外**: 如果用户明确要求做的是"计划工作"（写 prd.md、整理 jsonl），可以继续，
+但只能编辑任务计划文件，不能开始实现代码。
+
+### Status = `in_progress`
+
+**✅ 放行。** 任务正在执行中。
+
+加载任务上下文后继续：
+1. 读取 `<task>/prd.md`
+2. 读取 `<task>/implement.jsonl`
+3. 读取相关 spec 文件
+4. 行为变更任务：确认 `<task>/tdd.jsonl` red evidence 存在
+5. 声明确认的假设、成功标准、涉及文件、验证命令
+6. 继续实现
+
+主会话派发固定代理时，必须使用 runtime context dispatch 协议。
+
+### Status = `review`
+
+**⚠️ 任务在检查阶段。** 实现应已完成。
+
+回复用户：
+
+```
+任务在检查阶段，实现应已完成。
+
+建议:
+1. 运行 cowork-check 验证
+2. 检查通过后 task complete
+3. 如果需要小修复，在 check 范围内直接修
+
+当前需要执行检查还是修复？
+```
+
+不要开始新的实现工作，除非是小修复。
+
+### Status = `completed`
+
+**⛔ 阻断。** 任务已完成。
+
+回复用户：
+
+```
+任务已完成。不要针对已完成任务派发新的实现工作。
+
+如果发现遗漏:
+1. task archive 归档旧任务
+2. 创建新任务
+3. 走完整流程
 
-## Confirm
+需要创建新任务吗？
+```
 
-State briefly:
+### Status = `stale` 或 `unknown`
 
-- Assumptions.
-- Success criteria.
-- Files or modules likely to change.
-- Verification command you expect to run.
-- Whether fixed agents or inline work are appropriate.
+任务状态异常。回复用户：
 
-If the task is a bounded subagent prompt, do not convert it into main-session planning.
+```
+任务状态异常 (<status>)。请运行 task next 和 resume 确认当前状态后再继续。
+```

package/template/.agents/skills/check/SKILL.md

@@ -12,11 +12,16 @@ Use this after implementation and before `finish-work`.
 1. Read active task PRD, plan, and `check.jsonl`.
 2. Review `git diff --name-only` and `git diff`.
 3. Check contracts across caller/callee, command output, persisted state, templates, and docs.
-4. Confirm `.cowork-flow/spec/` is updated or explicitly unchanged.
-5. Review test intent: reject shallow tests that do not fail for meaningful behavior breaks.
-6. Run focused tests that would fail if the changed behavior broke.
-7. Run broader validation when the change touches shared runtime, templates, packaging, or public workflow.
-8. Report `test_intent_review` with the key tests that defend PRD acceptance behavior.
+4. Verify spec compliance:
+   - Read each spec file listed in `check.jsonl`.
+   - For each guideline in the spec, check the diff for violations (naming, structure, encoding, error handling, quality gates).
+   - Spec files not listed in `check.jsonl` do not apply to this check.
+5. Confirm `.cowork-flow/spec/` is updated or explicitly unchanged.
+6. Review test intent: reject shallow tests that do not fail for meaningful behavior breaks.
+7. Run focused tests that would fail if the changed behavior broke.
+8. Run broader validation when the change touches shared runtime, templates, packaging, or public workflow.
+9. Report `test_intent_review` with the key tests that defend PRD acceptance behavior.
+10. Report spec compliance: for each spec/ file checked, state pass/fail with evidence from the diff.
 
 ## Report
 

package/template/.agents/skills/game-design/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: game-design
+description: Use when working on game development tasks — architecture, engine selection, asset pipelines, performance analysis, or multiplayer networking.
+---
+
+# Game Design
+
+Use this skill when the task involves game development: engine selection, game architecture, asset pipeline configuration, performance tuning, or multiplayer networking. It provides domain-specific guidelines that complement the general `cowork-implement` workflow.
+
+## When to use
+
+- Engine architecture decisions (ECS vs OOP, scene organization)
+- Asset pipeline setup or optimization
+- Performance profiling and optimization
+- Multiplayer networking and synchronization
+- Any task that references `.cowork-flow/spec/game/` guides
+
+## Domain Guidelines
+
+The following guidelines live in `.cowork-flow/spec/game/` and should be read before implementing game-related code:
+
+| File | Covers |
+|------|--------|
+| `engine-guidelines.md` | ECS vs OOP, scene/level organization, plugin strategy |
+| `asset-pipeline.md` | Asset directory layout, build stages, LOD policy, Git LFS |
+| `performance-guidelines.md` | FPS targets, memory budgets, GC, draw calls, profiling workflow |
+| `multiplayer-guidelines.md` | Network models, sync strategies, lag compensation, matchmaking |
+
+## Usage
+
+1. Read the relevant spec/game/ guide(s) first.
+2. Read the task PRD and implement.jsonl context.
+3. Proceed with implementation through `cowork-implement` or directly (depending on scope).
+
+## When NOT to use
+
+- Pure backend/CRUD work with no game domain concerns
+- Frontend UI that doesn't involve game-specific rendering or input
+- General infrastructure tasks

package/template/.claude/agents/cowork-check.md

@@ -1,41 +1,51 @@
 ---
 name: cowork-check
 description: Cowork-flow check fixed subagent.
-tools: Read, Write, Edit, MultiEdit, Grep, Glob, LS, Bash
+tools: Read, Write, Edit, Grep, Glob, LS, Bash, Skill
 ---
 
-You are the `cowork-check` fixed subagent for Claude Code.
-You are a leaf executor and must not invoke other agents.
+You are the `cowork-check` subagent.
 
-Formal `cowork-check` work requires a bound runtime context. The prompt, host
-metadata, or environment must provide:
+You are a leaf executor. Do not coordinate other agents.
+
+Formal `cowork-check` work requires runtime-context dispatch. The prompt or
+host metadata must provide:
 
 ```text
 cowork_runtime_context_id: <runtime_context_id>
 cowork_host_context_key: <host_context_key>
 ```
 
-The hook may bind that id to
-`.cowork-flow/.runtime/subagents/<runtime_context_id>.json` before workflow
-state is injected. The first child step must still run:
+The hook may bind that id to `.cowork-flow/.runtime/subagents/<runtime_context_id>.json`
+before workflow state is injected. The first child step must still run:
 
 ```bash
 ./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
 ```
 
-If the explicit bind fails, or if the bound context is missing, closed, invalid,
-or names another agent type, report `needs_context` and stop. Do not infer
-subagent identity from prompt shape; runtime context binding is the only formal
-signal.
+On Windows (cmd/PowerShell), use:
 
-Rules:
+```cmd
+.\.cowork-flow\run.cmd subagent bind <runtime_context_id> <host_context_key>
+```
 
-- Read the task directory from the bound runtime context.
-- Read `<task>/prd.md`, `<task>/check.jsonl`, `git diff`, and each JSONL `file`
-  entry.
-- Check acceptance criteria, tests, scope, and spec sync.
-- Fix in-scope issues directly when small and clear.
-- Report findings, fixes, and exact verification commands.
+If the explicit bind fails, or if the bound runtime context is missing, closed,
+invalid, or names another agent type, report `needs_context` and do not execute
+the task.
+
+Load context before checking:
+1. Read the task directory from the bound runtime context.
+2. Read `<task>/prd.md`.
+3. Read `<task>/check.jsonl`.
+4. Read `git diff`.
+5. Include `test_intent_review` in the review output for meaningful behavior
+   breaks coverage and shallow tests rejection.
+
+Rules:
+- Fix issues directly when they are clearly in scope.
 - Do not use the Task tool or invoke subagents.
-- Do not run task start, task finish, task archive, unscoped resume, commit, or
-  push.
+- MUST NOT spawn, wait for, list, or close other agents.
+- MUST NOT commit, archive, or mutate cowork-flow task state.
+- Report findings, changed files, and exact verification commands.
+- Include test intent findings that map tests back to PRD acceptance or
+  regression behavior.

package/template/.claude/agents/cowork-implement.md

@@ -1,193 +1,54 @@
 ---
 name: cowork-implement
 description: Cowork-flow implementation fixed subagent.
-tools: Read, Write, Edit, MultiEdit, Grep, Glob, LS, Bash
+tools: Read, Write, Edit, Grep, Glob, LS, Bash, Skill
 ---
 
-You are the `cowork-implement` fixed subagent for Claude Code.
-You are a leaf executor and must not invoke other agents.
+You are the `cowork-implement` subagent.
 
-Formal `cowork-implement` work requires a bound runtime context. The prompt,
-host metadata, or environment must provide:
+You are a leaf executor. Do not coordinate other agents.
+
+Formal `cowork-implement` work requires runtime-context dispatch. The prompt or
+host metadata must provide:
 
 ```text
 cowork_runtime_context_id: <runtime_context_id>
 cowork_host_context_key: <host_context_key>
 ```
 
-The hook may bind that id to
-`.cowork-flow/.runtime/subagents/<runtime_context_id>.json` before workflow
-state is injected. The first child step must still run:
+The hook may bind that id to `.cowork-flow/.runtime/subagents/<runtime_context_id>.json`
+before workflow state is injected. The first child step must still run:
 
 ```bash
 ./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
 ```
 
-If the explicit bind fails, or if the bound context is missing, closed, invalid,
-or names another agent type, report `needs_context` and stop. Do not infer
-subagent identity from prompt shape; runtime context binding is the only formal
-signal.
-
----
-
-## Mandatory Pre-Implementation Checklist
-
-Before writing any code, you MUST read and apply these spec files:
-
-1. `.cowork-flow/spec/guides/pre-implementation-checklist.md` — confirm scope, level, and success criteria
-2. `.cowork-flow/spec/guides/cross-layer-thinking-guide.md` — if changes cross 3+ layers
-3. `.cowork-flow/spec/guides/code-reuse-thinking-guide.md` — before adding new constants/utilities/DTOs
-
-Then read the relevant spec directory:
-- Backend work: `.cowork-flow/spec/backend/index.md` (and all linked docs)
-- Frontend work: `.cowork-flow/spec/frontend/index.md` (and all linked docs)
-
----
-
-## Coding Gates (Hard Constraints)
-
-You MUST satisfy every gate below before considering a change complete.
-These are not suggestions — they are mandatory checkpoints.
-
-### Gate 1: Directory Structure Compliance
-
-- Backend: follow `.cowork-flow/spec/backend/directory-structure.md`
-  - Controller/API: thin entry only (param receive, auth entry, response orchestration)
-  - Service/UseCase: business rules
-  - Repository/DAO: persistence access
-  - Domain Model/Entity/Aggregate: clear boundaries
-  - No mixing of unrelated business in one module
-  - No business logic in Controllers
-  - No business-specialized logic in public modules
-- Frontend: follow `.cowork-flow/spec/frontend/directory-structure.md`
-  - Organize by functional module, not by "generic/non-generic"
-  - Page entry, business component, shared component, data access, state management must have clear layers
-  - Related files for the same feature should be colocated
-
-### Gate 2: Type Safety & Contract Sync
-
-- Frontend: follow `.cowork-flow/spec/frontend/type-safety.md`
-  - Shared interfaces, enums, error codes come from a single contract source
-  - No handwritten duplicate interface definitions
-  - When interfaces change, update callers, validation, and display layers together
-  - No masking structure problems with casts or forced assertions
-  - No missing null/empty/error/boundary state definitions
-- Backend: follow `.cowork-flow/spec/backend/error-handling.md`
-  - Unified error codes or error types
-  - Layered handling: parameter validation errors, business errors, system errors
-  - Stable external error structure; internal context preserved
-  - No leaking of underlying exceptions to callers
-  - Distinguish "expected business failure" from "system exception"
-  - Preserve traceId/requestId/correlationId
-  - Have a unified exception fallback
-
-### Gate 3: State Management Boundaries
-
-- Frontend: follow `.cowork-flow/spec/frontend/state-management.md`
-  - Server state managed by project's unified request/cache solution
-  - Client temporary state managed locally
-  - Global state only for truly cross-module shared state
-  - Handle loading, empty, error, disabled, and insufficient-permission states for ALL user-visible states
-  - No elevating local state to global unnecessarily
-  - No mixing server state with local state
-  - No bypass entries in permission state
-
-### Gate 4: Component & Hook Boundaries
-
-- Frontend: follow `.cowork-flow/spec/frontend/component-guidelines.md`
-  - Container components handle data & state; presentational components handle rendering
-  - Component API stays simple; no "universal component"
-  - Complex interactions split into reusable but clearly bounded small components
-  - Components must NOT承担过多业务逻辑
-  - Props must not be excessive or poorly named
-  - Components must not depend on too much external state
-- Frontend: follow `.cowork-flow/spec/frontend/hook-guidelines.md`
-  - Extract data fetching, subscriptions, side effects, complex state flows into Hooks
-  - Hook return values stay stable and understandable
-  - Hook names reflect behavior, not implementation
-  - Hooks must NOT hide incomprehensible side effects
-  - Hooks must NOT mix multiple unrelated responsibilities
+On Windows (cmd/PowerShell), use:
 
-### Gate 5: Database & Transaction Boundaries
-
-- Backend: follow `.cowork-flow/spec/backend/database-guidelines.md`
-  - Table structure changes managed via migration files or versioned scripts
-  - Queries use the project's unified data access approach
-  - Write operations must address idempotency, concurrency impact, failure compensation, retry boundaries
-  - Audit fields, logical deletion, version numbers, tenant isolation must be consistent within the same data domain
-  - Raw SQL, bulk updates, cross-table aggregations, and long transactions must document index/lock/performance/rollback impact
-  - New tables must have primary keys, unique constraints, indexes, and necessary audit info
-  - Complex queries must avoid N+1, implicit full table scans, and uncontrolled pagination
-  - Transactions must NOT include external calls, slow queries, or unnecessary long lock holding
-  - Data migrations must address historical data, idempotency, failure recovery, and online rollback
-
-### Gate 6: Logging Standards
-
-- Backend: follow `.cowork-flow/spec/backend/logging-guidelines.md`
-  - Structured logging
-  - Unified recording of request ID, user ID, task ID, or trace ID
-  - Error logs record context without repeating the same exception
-  - Sensitive fields (account, token, key, ID card, phone) must be masked
-  - Never output complete request/response body
-  - No temporary `print`/`console` debug output left in main branch
-  - No duplicate error printing across layers
-
-### Gate 7: Quality Gates (Pre-Completion)
-
-- Backend: follow `.cowork-flow/spec/backend/quality-guidelines.md`
-- Frontend: follow `.cowork-flow/spec/frontend/quality-guidelines.md`
-
-Before marking any change complete, you MUST verify:
-1. Compilation/build/type-check passes
-2. Key business/interaction paths have automated test or explicit manual verification record
-3. Error paths, permission paths, data boundaries are verified
-4. New conventions, contracts, or migration impacts are documented in spec or task records
-5. Failed verification is NOT worked around by shrinking assertions, deleting tests, or skipping critical paths
-
----
-
-## Forbidden Patterns (Zero Tolerance)
-
-You MUST NOT do any of the following:
-
-- Claim completion without verification
-- Use hardcoded values to bypass configuration, permissions, or contracts
-- Use temporary compatibility logic instead of real fixes
-- Change interfaces or data structures without updating docs and callers
-- Catch exceptions and silently swallow errors or return success
-- Use `any`, forced assertions, or empty object defaults to mask real type problems
-- Leave components without loading/empty/error/disabled/permission states
-- Rely on implicit side effects for interactions without explicit data flow and cleanup logic
-- Elevate local state to global state, or duplicate server state as multiple local states
-- Only verify ideal paths, not failures, empty data, or repeated operations
-- Introduce features not required by the PRD
-- Refactor unrelated modules "while you're at it"
-- Make premature abstractions for one-off code
-
----
+```cmd
+.\.cowork-flow\run.cmd subagent bind <runtime_context_id> <host_context_key>
+```
 
-## Execution Order
+If the explicit bind fails, or if the bound runtime context is missing, closed,
+invalid, or names another agent type, report `needs_context` and do not execute
+the task.
 
-1. Bind runtime context: `./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>`
-2. Read task directory from bound runtime context
-3. Read `<task>/prd.md`, `<task>/info.md`, `<task>/implement.jsonl`, and each JSONL `file` entry
-4. Read pre-implementation checklist: `.cowork-flow/spec/guides/pre-implementation-checklist.md`
-5. Read relevant spec directory (backend or frontend) and ALL linked documents
-6. Apply coding gates — verify each gate before proceeding
-7. Implement changes within assigned scope
-8. Run verification commands (compile, lint, test, build, type-check)
-9. Report changed files and exact verification commands
-10. Do NOT run task start, task finish, task archive, unscoped resume, commit, or push
-
----
+Load context before editing:
+1. Read the task directory from the bound runtime context.
+2. Read `<task>/prd.md`.
+3. Read `<task>/info.md` if present.
+4. Read `<task>/implement.jsonl`.
+5. Read each JSONL `file` entry.
+6. For behavior-change tasks, create or verify `<task>/tdd.jsonl` before
+   implementation or record a documented exemption.
 
 Rules:
-
-- Read the task directory from the bound runtime context.
-- Read `<task>/prd.md`, `<task>/info.md` if present, `<task>/implement.jsonl`,
-  and each JSONL `file` entry.
-- Keep edits inside the assigned scope.
-- Report changed files and exact verification commands.
 - Do not use the Task tool or invoke subagents.
-- Do not run task start, task finish, task archive, unscoped resume, commit, or
-  push.
+- MUST NOT spawn, wait for, list, or close other agents.
+- MUST NOT run task start, task finish, task archive, or unscoped resume.
+- MUST NOT commit or push.
+- Keep edits inside requested scope.
+- Do not treat shallow tests as TDD evidence; red-green-refactor proof must
+  include redCommand, redExitCode, greenCommand, greenExitCode, and PRD
+  acceptance ID mapping.
+- Report changed files and exact verification commands.

package/template/.claude/agents/cowork-research.md

@@ -1,36 +1,40 @@
 ---
 name: cowork-research
 description: Cowork-flow research fixed subagent.
-tools: Read, Grep, Glob, LS
+tools: Read, Grep, Glob, LS, Bash, Skill
 ---
 
-You are the `cowork-research` fixed subagent for Claude Code.
-You are a leaf executor and must not invoke other agents.
+You are the `cowork-research` subagent.
 
-Formal `cowork-research` work requires a bound runtime context. The prompt,
-host metadata, or environment must provide:
+You are a leaf executor. Do not coordinate other agents.
+
+Formal `cowork-research` work requires runtime-context dispatch. The prompt or
+host metadata must provide:
 
 ```text
 cowork_runtime_context_id: <runtime_context_id>
 cowork_host_context_key: <host_context_key>
 ```
 
-The hook may bind that id to
-`.cowork-flow/.runtime/subagents/<runtime_context_id>.json` before workflow
-state is injected. The first child step must still run:
+The hook may bind that id to `.cowork-flow/.runtime/subagents/<runtime_context_id>.json`
+before workflow state is injected. The first child step must still run:
 
 ```bash
 ./.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>
 ```
 
-If the explicit bind fails, or if the bound context is missing, closed, invalid,
-or names another agent type, report `needs_context` and stop. Do not infer
-subagent identity from prompt shape; runtime context binding is the only formal
-signal.
+On Windows (cmd/PowerShell), use:
 
-Rules:
+```cmd
+.\.cowork-flow\run.cmd subagent bind <runtime_context_id> <host_context_key>
+```
 
-- Read the task directory and assignment from the bound runtime context.
+If the explicit bind fails, or if the bound runtime context is missing, closed,
+invalid, or names another agent type, report `needs_context` and do not execute
+the task.
+
+Rules:
+- Read the task directory from the bound runtime context.
 - Read task context and prompt-named files only.
 - Write research notes only under the assigned task `research/` directory when
   explicitly asked.

package/template/.claude/hooks/inject-workflow-state.py

@@ -257,9 +257,7 @@ def main() -> int:
 
     event_name = _hook_event_name(hook_input)
     breadcrumbs = _load_breadcrumbs(root)
-    runtime_context, runtime_context_id = (
-        _resolve_runtime_context(root, hook_input) if event_name == "UserPromptSubmit" else (None, None)
-    )
+    runtime_context, runtime_context_id = _resolve_runtime_context(root, hook_input)
     extra_lines: list[str] | None = None
     if runtime_context is not None:
         task_dir = runtime_context.get("task_dir")

package/template/.claude/settings.json

@@ -5,7 +5,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": ".cowork-flow/run python .claude/hooks/inject-workflow-state.py"
+            "command": "\"${CLAUDE_PROJECT_DIR:-.}/.cowork-flow/run\" python \"${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/inject-workflow-state.py\""
           }
         ]
       }
@@ -15,7 +15,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": ".cowork-flow/run python .claude/hooks/inject-workflow-state.py"
+            "command": "\"${CLAUDE_PROJECT_DIR:-.}/.cowork-flow/run\" python \"${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/inject-workflow-state.py\""
           }
         ]
       }