@pennixrv/trellis 0.7.0-beta.9 → 0.7.1-beta.1

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/multi-agent-teamwork.md

@@ -0,0 +1,32 @@
+# Teamwork Runtime
+
+`trellis teamwork` provides durable coordination sessions and teammate processes. Its session lifecycle is independent of the Trellis task lifecycle and phase route. A session may be associated with a task, but it never owns task status, phase state, or phase acceptance.
+
+## Local surfaces
+
+| Surface | Purpose |
+| --- | --- |
+| `~/.trellis/teamwork/<project>/<session>/events.jsonl` | Durable Teamwork Session event log. |
+| `.trellis/agents/teammate.md` | Generic behavior card loaded for a teammate. |
+| `.trellis/agents/teammate-profiles.json` | Provider and execution profiles. |
+| `.trellis/config.yaml` (`teamwork.*`) | Teammate concurrency and process guard settings. |
+| `packages/core/src/teamwork/` | Reusable Teamwork Session event and storage APIs. |
+| `packages/cli/src/commands/teamwork/` | CLI commands, provider adapters, and process supervision. |
+
+The storage root defaults to `~/.trellis/teamwork`; `TRELLIS_TEAMWORK_ROOT` overrides it. The project bucket defaults to a key derived from the current working directory; `TRELLIS_TEAMWORK_PROJECT` overrides that key.
+
+## Ownership
+
+- Trellis Core owns reusable Teamwork Session event, storage, and coordination contracts.
+- The Trellis CLI owns command handling, teammate process supervision, and task-bound batch artifacts.
+- The active Trellis task remains the source of truth for task and phase state. Teamwork dispatch and reports may bind to its current phase and revisions; Teamwork does not write phase acceptance.
+- Accepted reports remain task evidence. Temporary batch data may be removed when the batch settles. Teamwork Session event logs follow their own lifecycle.
+- Host capabilities must pass the configured capability check before batch execution. A provider contract or fixture alone does not establish that a host is available.
+
+## Configuration
+
+The project configuration supports `teamwork.teammate.max_concurrency` and `teamwork.teammate_guard.idle_timeout`, `max_live_teammates`, and `non_batch_reserved`. Defaults and CLI overrides are defined by the current Trellis CLI; read `packages/cli/src/commands/teamwork/teammate-config.ts` before changing them.
+
+## Related entry points
+
+Use the bundled `trellis-teamwork` Skill for command usage and teammate coordination. Use `trellis workflow` and the active task record for workflow behavior. Do not route task or phase transitions through a Teamwork Session.

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/spec-system.md

@@ -95,7 +95,7 @@ When the AI learns a new rule during implementation or debugging, it should upda
 | Change monorepo spec mapping | `packages` / `default_package` / `spec_scope` in `.trellis/config.yaml`. |
 | Change which specs AI reads before implementation | The task's `implement.jsonl`. |
 | Change which specs AI reads during checking | The task's `check.jsonl`. |
-| Change when specs should be updated | Phase 3.3 in `.trellis/workflow.md` and the `trellis-update-spec` skill. |
+| Change when specs should be updated | Solution Design and Convergence Phase guidance in `.trellis/workflow.md` and the `trellis-update-spec` skill. |
 
 ## Boundaries
 

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/task-system.md

@@ -1,130 +1,44 @@
 # Local Task System
 
-The Trellis task system is stored entirely under `.trellis/tasks/` in the user project. Each task is a directory containing requirements, context, research, state, and relationship information.
-
-## Task Directory Structure
-
-```text
-.trellis/tasks/
-├── 04-28-example-task/
-│   ├── task.json
-│   ├── prd.md
-│   ├── design.md
-│   ├── implement.md
-│   ├── implement.jsonl
-│   ├── check.jsonl
-│   └── research/
-└── archive/
-    └── 2026-04/
-```
-
-| File | Purpose |
-| --- | --- |
-| `task.json` | Task metadata: status, assignee, priority, branch, parent/child tasks, and similar fields. |
-| `prd.md` | Requirements, constraints, and acceptance criteria. Lightweight tasks may be PRD-only. |
-| `design.md` | Technical design for complex tasks: boundaries, contracts, data flow, compatibility, tradeoffs. |
-| `implement.md` | Execution plan for complex tasks: ordered checklist, validation commands, review gates, rollback points. |
-| `implement.jsonl` | List of spec/research files the implement agent must read first. |
-| `check.jsonl` | List of spec/research files the check agent must read first. |
-| `research/` | Research artifacts. Complex findings should not live only in chat. |
-
-## `task.json`
-
-`task.json` records task status and metadata. Common fields:
-
-| Field | Meaning |
-| --- | --- |
-| `id` / `name` / `title` | Task identity and title. |
-| `status` | Status such as `planning`, `in_progress`, `review`, or `completed`. |
-| `priority` | `P0`, `P1`, `P2`, `P3`. |
-| `creator` / `assignee` | Creator and assignee. |
-| `package` | Target package in a monorepo; may be empty. |
-| `branch` / `base_branch` | Working branch and PR target branch. |
-| `children` / `parent` | Parent/child task relationships. |
-| `commit` / `pr_url` | Commit and PR information after completion. |
-| `meta` | Extension fields. |
-
-## Parent / Child Task Trees
-
-Parent/child task relationships are for work structure. A parent task groups related deliverables under one source requirement set; it is not a dependency scheduler and does not replace the child task's own planning artifacts.
-
-Use a parent task when a request has multiple independently verifiable deliverables. The parent owns:
-
-- Source requirements and user-facing scope.
-- The map of child tasks and their responsibility boundaries.
-- Cross-child acceptance criteria and final integration review.
+Tasks live under .trellis/tasks/. A task record keeps its artifacts and history in place after completion or cancellation; Trellis does not move tasks into an archive.
 
-Use child tasks for deliverables that can move through planning, implementation, check, and archive independently. If one child depends on another, write that dependency in the child `prd.md` / `implement.md`; do not rely on tree position to imply ordering.
+## Task records
 
-Create new children with:
+Each task directory may contain task.json, prd.md, design.md, implement.md, research/, and context manifests. Use only the artifacts needed by the task.
 
-```bash
-python3 ./.trellis/scripts/task.py create "<child title>" --description "<one-line summary>" --slug <child-slug> --parent <parent-dir>
-```
+task.json records identity, lifecycle status, ownership, and parent/child relationships. The Trellis CLI task workflow record stores the ordered phase route, current phase, revisions, evidence, acceptance, and authorization. Do not edit lifecycle or phase status by hand.
 
-Link or unlink existing tasks with:
+## Parent and child tasks
 
-```bash
-python3 ./.trellis/scripts/task.py add-subtask <parent-dir> <child-dir>
-python3 ./.trellis/scripts/task.py remove-subtask <parent-dir> <child-dir>
-```
+A parent groups related deliverables and records cross-task acceptance. Each child has its own task record and lifecycle. Record dependencies explicitly in task artifacts; tree position does not imply execution order.
 
-`children` on the parent is a historical list. When a child is archived, Trellis keeps that child name in the parent so progress like `[2/3 done]` remains meaningful after completed children move to `archive/`.
+## Active task context
 
-The AI should not treat phase numbers as task status. Task progress is mainly determined by `status`, artifact presence (`prd.md`, optional `design.md` / `implement.md`), whether JSONL context is configured for sub-agent mode, and the phase descriptions in `workflow.md`.
+The active task pointer is scoped to an AI session under .trellis/.runtime/sessions/. Use task.py current to inspect it, task.py start to attach a task to the current session, and task.py finish to clear the current session pointer. Do not create a shared global pointer.
 
-## Active Task
+## Native task operations
 
-The user sees a "current task," but Trellis stores active task state per session.
+    python3 ./.trellis/scripts/task.py create "<title>" --description "<summary>" [--parent <task>]
+    python3 ./.trellis/scripts/task.py phase show <task>
+    python3 ./.trellis/scripts/task.py validate <task>
+    python3 ./.trellis/scripts/task.py start <task>
+    python3 ./.trellis/scripts/task.py complete <task>
+    python3 ./.trellis/scripts/task.py cancel <task> --reason "<reason>" --evidence-ref <reference>
 
-```text
-.trellis/.runtime/sessions/<context-key>.json
-```
+Use phase operations through task.py phase for artifact revisions, acceptance, evidence-backed skips, waits, blocks, resume, return, route, and authorization. Consult task.py help for current arguments. Completion and cancellation occur only after Delivery Review and On-Site Closeout Phase.
 
-`task.py start` writes the task path into the runtime session file for the current session. `task.py current --source` shows the current task and where it came from. Different AI windows can point to different tasks without overwriting each other.
+The read-only trellis task progress command summarizes planning, in_progress, and completed lifecycle records. It does not change task state.
 
-If the platform or shell environment has no stable session identity, `task.py start` may be unable to set the active task. The AI should read the error, inspect the platform hook/session environment, and not fall back to a shared global pointer.
+## Context manifests
 
-## JSONL Context
+implement.jsonl and check.jsonl identify relevant spec and research files for agents that consume those manifests. They do not replace the task's planning artifacts. Keep entries curated and remove placeholder rows rejected by task.py validate.
 
-`implement.jsonl` and `check.jsonl` are context manifests for sub-agents to read first. They do not replace `implement.md`; `implement.md` is the human-readable execution plan.
-
-Format:
-
-```jsonl
-{"file": ".trellis/spec/cli/backend/index.md", "reason": "Backend conventions"}
-{"file": ".trellis/tasks/04-28-example/research/api.md", "reason": "API research"}
-```
-
-Rules:
-
-- Include spec and research files.
-- Do not include code files that are about to be modified.
-- Do not treat temporary conclusions in chat as the only context.
-- Rows without a `file` field are skipped by readers. Legacy `{"_example": ...}` placeholder rows are rejected by `task.py validate` — delete them.
-
-## Common Commands
-
-```bash
-python3 ./.trellis/scripts/task.py create "<title>" --description "<one-line summary>" --slug <slug>
-python3 ./.trellis/scripts/task.py start <task>
-python3 ./.trellis/scripts/task.py current --source
-python3 ./.trellis/scripts/task.py add-context <task> implement <file> <reason>
-python3 ./.trellis/scripts/task.py validate <task>
-python3 ./.trellis/scripts/task.py finish
-python3 ./.trellis/scripts/task.py archive <task>
-```
-
-When modifying the task system, the AI should prefer script commands to maintain structure. Edit JSON/Markdown directly only when scripts do not cover the need.
-
-## Local Customization Points
+## Local customization points
 
 | Need | Edit location |
 | --- | --- |
-| Change the default task template | `.trellis/scripts/common/task_store.py` and task creation instructions. |
-| Change status semantics | `.trellis/workflow.md`, workflow-state hook logic, and task usage conventions. |
-| Add task lifecycle actions | `hooks.after_*` in `.trellis/config.yaml`. |
-| Change context rules | Planning artifact guidance in `.trellis/workflow.md` and related platform agent/hook instructions. |
-| Change archive policy | `.trellis/scripts/common/task_store.py` / `task_utils.py`. |
-
-These are local files in the user project. Do not default to editing Trellis CLI source code unless the user wants to contribute upstream.
+| Change task fields or creation | .trellis/scripts/common/task_store.py |
+| Change task lookup or parsing | .trellis/scripts/common/task_utils.py |
+| Change lifecycle and phase contracts | .trellis/scripts/common/task_workflow.py and Core task model |
+| Change active session task behavior | .trellis/scripts/common/active_task.py and host integration |
+| Change task guidance | .trellis/workflow.md and the applicable phase Skill |

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/workflow.md

@@ -1,75 +1,34 @@
 # Local Workflow System
 
-`.trellis/workflow.md` is the Trellis workflow source of truth inside the user project. An AI does not need Trellis source code to understand how the current project should move tasks forward; this file is enough.
+The installed project's .trellis/workflow.md is the local workflow source. Read it before changing task guidance or platform entry points.
 
-## File Responsibilities
+## Business phases
 
-`.trellis/workflow.md` has three responsibilities:
+The workflow keeps its business phases distinct, with separate activities, outputs, and transition conditions:
 
-1. **Explain workflow phases**: Plan, Execute, Finish.
-2. **Define skill routing**: which skill or agent the AI should use when the user expresses a certain intent.
-3. **Provide workflow-state prompt blocks**: hooks can inject the prompt block for the current state into the conversation.
+- Goal Exploration and Requirements Confirmation Phase
+- Decision Space Construction and Consolidation Phase
+- Solution Design and Convergence Phase
+- Task Implementation and Test Verification Phase
+- Delivery Review and On-Site Closeout Phase
 
-## Current Phase Model
+The task route may skip a phase when evidence shows it adds no value. The Goal Exploration and Requirements Confirmation Phase requires explicit user confirmation of the current requirements revision before the route enters Decision Space Construction and Consolidation Phase or Solution Design and Convergence Phase. Acceptance in Solution Design and Convergence Phase does not grant implementation authorization. During Delivery Review and On-Site Closeout Phase, review the current delivery and handle task completion or cancellation.
 
-```text
-Phase 1: Plan    -> clarify what to build, produce prd.md and required research
-Phase 2: Execute -> implement against the PRD and specs, then check
-Phase 3: Finish  -> final verification, preserve lessons, and wrap up
-```
+Phase identifiers, route revisions, accepted artifact revisions, and authorization are stored and changed through Trellis CLI. Skills and Hooks guide or surface the active phase; they do not create another state source. Formal session handoff is independent of the task and its phases.
 
-Each phase contains numbered steps, such as `1.3 Configure context`. These numbers are not runtime fields in `task.json`; they are workflow structure for AI and humans to read.
+## Skill routing and state prompts
 
-## Skill Routing
+Each phase Skill owns its procedure and diagram. The workflow entry routes to the Skill matching the current phase identifier. Component Skills are selected by the work required, not by a fixed phase checklist.
 
-`workflow.md` separates routing by platform capability:
+Workflow-state blocks provide per-turn breadcrumbs. Keep their phase identifiers aligned with Core and update host parsers when headings or state tags change. Do not derive a phase from task status or artifact presence when Trellis CLI provides the current route.
 
-- Platforms with sub-agent support: dispatch `trellis-implement` by default for implementation and `trellis-check` for checking.
-- Platforms without sub-agent support: the main session reads skills such as `trellis-before-dev`, then executes directly.
-
-When changing local AI behavior, update the routing descriptions in `workflow.md` first, then check whether the corresponding platform skill, command, or agent files need to stay in sync.
-
-## Workflow-State Prompt Blocks
-
-The bottom of `workflow.md` can contain state blocks like this:
-
-```text
-[workflow-state:no_task]
-...
-[/workflow-state:no_task]
-```
-
-Hooks choose the right block based on current task status and inject it into the conversation. Common states include:
-
-| State | Meaning |
-| --- | --- |
-| `no_task` | The current session has no active task. |
-| `planning` | The task is still in requirements, research, or context configuration. |
-| `in_progress` | The task has entered implementation and checking. |
-| `completed` | The task is complete and waiting for wrap-up or archive. |
-
-If the user wants to change policies such as "whether to create a task when there is no task," "when task creation may be skipped," or "whether sub-agents are required," edit these state blocks and the routing table above them.
-
-## Local Modification Patterns
-
-Common changes:
+## Local modification patterns
 
 | Goal | Edit point |
 | --- | --- |
-| Add a phase | Update the Phase Index, phase body, routing, and state blocks. |
-| Change task creation policy | Update the `no_task` state block and Phase 1 description. |
-| Change the default implementation/check path | Update Phase 2 and skill routing. |
-| Change the wrap-up flow | Update Phase 3 and `finish-work` related descriptions. Note the current split: Phase 3.4 = AI-driven code commits (batched, user-confirmed), Phase 3.5 = `/finish-work` (archive + record session). `/finish-work` refuses to run if the working tree is dirty. |
-| Change platform differences | Update routing descriptions grouped by platform. |
-
-After editing, make the AI reread `.trellis/workflow.md`; do not assume the flow from the old conversation is still valid.
-
-## Relationship To Platform Files
-
-`workflow.md` is the semantic center of the local workflow, but each platform can also have its own entry files:
-
-- skills, such as `trellis-brainstorm` and `trellis-check`.
-- commands/prompts/workflows, such as continue and finish-work.
-- hooks, such as session-start or workflow-state injection.
+| Change phase activities or transitions | .trellis/workflow.md and the matching phase Skill |
+| Change component routing | .trellis/workflow.md and pennix-workflow-routing where applicable |
+| Change lifecycle or phase state | Trellis CLI task workflow implementation and its contract |
+| Change platform context injection | Relevant Hook or plugin, keeping the Trellis task record authoritative |
 
-If only `workflow.md` changes, platform entry files may still contain old language. When the user wants to change "what the AI actually does," also inspect the relevant platform directory.
+After a shared workflow change, inspect relevant platform entry files for stale behavior. Keep phase-specific workflows distinct.

package/dist/templates/common/bundled-skills/trellis-meta/references/platform-files/skills-and-commands.md

@@ -11,7 +11,7 @@ Skills and commands are textual entry points for user interaction with Trellis.
 | prompt | Explicit user invocation or platform selection | Similar to command, but in a platform prompt format. |
 | workflow | Explicit user selection or platform auto-match | Guides the main session when no sub-agent/hook exists. |
 
-Trellis workflow skills usually share one semantic set: brainstorm, before-dev, check, update-spec, break-loop. Multi-file built-in skills such as `trellis-meta` use layered references.
+Trellis skills can cover reusable capabilities or dedicated workflow areas. Multi-file bundled skills such as `trellis-meta` keep supporting material in layered references.
 
 ## Common Paths
 

package/dist/templates/common/bundled-skills/trellis-session-insight/SKILL.md

@@ -68,7 +68,7 @@ trellis mem list --cwd <project-path>
 trellis mem projects   # → list active project cwds, then narrow
 ```
 
-Phase slicing (`--phase brainstorm|implement|all`) cuts the session at `task.py create`/`replan` and `task.py start` boundaries. For a finish-work review of the current task, `--phase brainstorm` recovers the planning discussion and `--phase implement` recovers the execution loop. Default is `all`.
+Phase slicing (`--phase brainstorm|implement|all`) cuts the session at `task.py create` and `task.py start` boundaries. For a finish-work review of the current task, `--phase brainstorm` recovers the planning discussion and `--phase implement` recovers the execution loop. Default is `all`.
 
 ## Triggering patterns
 

package/dist/templates/common/bundled-skills/trellis-session-insight/references/cli-quick-reference.md

@@ -23,7 +23,7 @@ Full flag reference for the five subcommands. Pin this as the authoritative sour
 | `--cwd <path>`                                | list / search     | Force a specific project cwd instead of inferring from where you are.                                                                                      |
 | `--limit N`                                   | list / search     | Cap output rows. Default `50`.                                                                                                                             |
 | `--grep KW`                                   | extract / context | Filter turns by keyword. Multi-token AND when whitespace-separated.                                                                                        |
-| `--phase brainstorm\|implement\|all`          | extract           | Slice session by Trellis task boundaries. `brainstorm` = `[task.py create/replan, task.py start)`. `implement` = turns outside brainstorm windows. Default `all`. |
+| `--phase brainstorm\|implement\|all`          | extract           | Slice session by Trellis task boundaries. `brainstorm` = `[task.py create, task.py start)`. `implement` = turns outside brainstorm windows. Default `all`. |
 | `--turns N`                                   | context           | Number of hit turns to return. Default `3`.                                                                                                                |
 | `--around N`                                  | context           | Surrounding turns to include per hit. Default `1`.                                                                                                         |
 | `--max-chars N`                               | context           | Total character budget. Default `6000` (~1500 tokens).                                                                                                     |

package/dist/templates/common/bundled-skills/trellis-solution-design-and-convergence/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: trellis-solution-design-and-convergence
+description: 当前任务处于解决方案设计与收敛阶段时，处理用户决定、方案完整性、外部先例和实施合同。
+---
+
+# 解决方案设计与收敛阶段
+
+当 `current_phase_id` 为 `solution_design_and_convergence` 时使用。阅读本 Skill 同目录的 `workflow.md`，核对当前有效的需求基线和决策空间构造与归并阶段结果或跳过记录。
+
+本阶段锁定当前路线所依据的决定和方案，不代表实施已获授权。需用户决定时，使用 `pennix-decision-grill` 同步询问并留在解决方案设计与收敛阶段；实施路线须形成 `implementation_contract`，再单独取得实施批准后才能进入任务实施与测试验证阶段。触发 prior-art review 的方案须在阶段结果接受前完成该审查。

package/dist/templates/common/bundled-skills/trellis-solution-design-and-convergence/workflow.md

@@ -0,0 +1,36 @@
+# 解决方案设计与收敛阶段流程
+
+核对有效的目标基线、决策空间构造与归并阶段结果或跳过记录及其 revision。按依赖筛选影响目标、范围、成功条件、用户偏好、风险承受或重要取舍的保留决定；使用 `pennix-decision-grill` 同步提问。答复到达后，核对其权限、当前 revision 和影响范围：影响目标或范围时回到目标探索与需求核对阶段，影响候选、标准或依赖时回到决策空间构造与归并阶段，仅改变当前候选中的方案时继续本阶段评估。待决定事项使解决方案设计与收敛阶段保持待决。
+
+比较适用方案，说明选择依据、重要后果、行为边界、责任、必要依赖、验证方式、停止与恢复条件及实质风险。对新颖核心机制、重大重构、跨组件边界变化或关键不确定性缺少可信本地先例的方案，在结果接受前完成有界 `prior-art review`，记录适用性、采纳或排除理由，或说明没有适用先例。外部材料改变候选、标准或依赖时回到决策空间构造与归并阶段。
+
+判断当前结果：分析交付形成 `analysis_conclusion`；不继续形成 `no_go`；延期形成带责任方、触发条件和恢复位置的 `deferred`，留在解决方案设计与收敛阶段；实施路线形成 `implementation_contract`，明确目标、范围和接受条件，并按路线需要补足实施与核验信息。只有交付物具有独立实施或集成边界时才拆分工作包，并说明推进和协作所需的依赖、顺序、责任或集成信息；单一交付不人为拆分工作包。解决方案设计与收敛阶段的结果接受与实施授权分开记录；只有合同及明确批准均有效时，Trellis CLI 才允许进入任务实施与测试验证阶段。
+
+```mermaid
+flowchart TD
+  input["核对需求基线与已接受的 DecisionSpace"] --> decisions{"存在尚待用户决定的实质取舍？"}
+  decisions -->|"是"| grill["pennix-decision-grill 同步询问；留在解决方案设计与收敛阶段"]
+  grill --> impact{"答复影响哪个范围？"}
+  impact -->|"目标或范围"| goal_exploration_and_requirements["回到目标探索与需求核对阶段"]
+  impact -->|"候选、标准或依赖"| decision_space_construction_and_merging["回到决策空间构造与归并阶段"]
+  impact -->|"当前候选中的选择"| compare["比较方案和重要后果"]
+  decisions -->|"否"| compare
+  compare --> prior{"触发 prior-art review？"}
+  prior -->|"是"| review["核验相关开源实现或公开提案并记录适用性"]
+  review --> changed{"外部证据改变候选、标准或依赖？"}
+  changed -->|"是"| decision_space_construction_and_merging
+  changed -->|"否"| assess["核对完整性、风险、验证和恢复条件"]
+  prior -->|"否"| assess
+  assess -->|"有实质缺口"| compare
+  assess -->|"analysis_conclusion 或 no_go"| reviewResult["Trellis CLI 接受解决方案设计与收敛阶段结果"]
+  assess -->|"deferred"| defer["记录恢复条件并留在解决方案设计与收敛阶段"]
+  assess -->|"implementation_contract"| contract["冻结必要实施合同"]
+  contract --> approval{"合同获接受且实施批准有效？"}
+  approval -->|"否"| wait["等待决定或授权；不进入实施"]
+  approval -->|"是"| task_implementation["Trellis CLI 核验并进入任务实施与测试验证阶段"]
+  reviewResult --> delivery_review_and_closeout["交付审查与现场收尾阶段"]
+```
+
+### 方案是否足以收敛
+
+实施者应能从当前方案判断要做什么、由谁负责、依赖什么、如何验证，以及何时停止或恢复；影响选择、接受、安全、权限、成本或不可逆影响的取舍应有依据和处理方式。未知事项可以补证、接受剩余风险、延期或不继续。此判断不要求固定篇幅、备选数量、字段或图表。

package/dist/templates/common/bundled-skills/trellis-task-implementation/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: trellis-task-implementation
+description: 当前任务处于任务实施与测试验证阶段时，按已授权实施合同推进工作包、验证、集成与阻塞处置。
+---
+
+# 任务实施与测试验证阶段
+
+当 `current_phase_id` 为 `task_implementation` 时使用。先阅读本 Skill 同目录的 `workflow.md`，再加载目标仓库适用的 `AGENTS.md`、Trellis spec 和实现合同。
+
+按合同依赖和优先级逐项实施；主工作树主代理负责阶段接受和集成。只在执行路线获准时使用 Paseo 委派写入；Trellis Teamwork teammate 只提供只读证据。默认在当前阶段修复和验证，只有合同、授权、依赖、基线或接受条件实质失效且无法安全恢复时，才回到最早受影响的阶段。

package/dist/templates/common/bundled-skills/trellis-task-implementation/workflow.md

@@ -0,0 +1,29 @@
+# 任务实施与测试验证阶段流程
+
+开始前核验当前 `implementation_contract`、实施授权、路线 revision、必要依赖和执行基线。使用 `trellis-before-dev` 读取目标仓库实际适用的规范；按组件 owner 合同选择主工作树或已批准的独立写入路线。调用项目任务 `start` 只在实施授权有效时将任务置为 `in_progress`。
+
+按合同的依赖和优先级选取当前工作包，实施满足目标的最小变更，并运行与风险和影响相称的局部验证。主工作树主代理核对来源、revision、Git 基线、差异和结果后接受工作包。多包任务按合同集成；单一交付不人为拆分。Trellis Teamwork 仅用于冻结计划下的只读比较或评议，不能改写任务状态或接受实施结果。实际写入委派依父任务规定使用 Trellis 受控入口与 Paseo；各组件源码仍在 owner 仓库内修改。
+
+局部失败、暂时不可用或当前状态已满足接受条件时，先在任务实施与测试验证阶段中处理。依赖或资源暂不可用且现场安全时记录恢复条件；未授权不产生外部副作用；未知现场先停止并核验。合同允许未运行验证且风险可接受时，记录原因、影响和替代证据。替代路线若改变授权、成本、隐私或接受条件，回到解决方案设计与收敛阶段；目标、范围变化按影响回到目标探索与需求核对阶段或决策空间构造与归并阶段。只有合同范围内工作包均已接受、适用必需验证完成或有有效未运行处置、按范围和风险需要的集成验证通过，才将交付候选交由交付审查与现场收尾阶段；仅当路线实际创建或委派资源时，才核验其处置事实。
+
+```mermaid
+flowchart TD
+  contract["核验 implementation_contract、授权、revision 和依赖"] --> ready{"准入与实施授权有效？"}
+  ready -->|"否，待用户决定或依赖"| wait["等待或记录阻断；不启动副作用"]
+  wait -->|"恢复后重新核验"| contract
+  ready -->|"是"| work["按合同依赖和优先级选取当前工作包"]
+  work --> implement["读取适用规范并实施最小变更"]
+  implement --> verify["执行与风险相称的局部验证"]
+  verify --> inspect["主工作树主代理核对 revision、基线、差异和结果"]
+  inspect -->|"局部缺陷或可处理冲突"| implement
+  inspect -->|"合同仍有效，当前 attempt 受阻"| stop["停止受影响范围并记录恢复条件"]
+  stop -->|"可安全恢复"| contract
+  inspect -->|"路线或合同实质失效"| replan["回最早受影响阶段并明确理由"]
+  inspect -->|"当前工作包接受"| more{"还有合同内工作包或必需验证？"}
+  more -->|"是"| work
+  more -->|"否；适用集成已核验，委派资源（如有）已安全处置"| candidate["形成交付候选并进入交付审查与现场收尾阶段"]
+```
+
+### 委派、回退与收敛
+
+回退使用当前 owner 的 Git 和资源合同，不覆盖无关改动，也不删除仍需核验的现场。只有当前合同无法安全覆盖目标、授权、依赖、基线、接受条件或停止条件的变化时，才回退到最早受影响阶段。结束任务实施与测试验证阶段前，记录适用验证结果、未运行处置、合同差异和未结发现；仅当路线实际创建或委派资源时，记录其处置状态。

package/dist/templates/common/bundled-skills/trellis-teamwork/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: trellis-teamwork
+description: Use Trellis Teamwork for live multi-agent collaboration, Teamwork Sessions, teammate assignments, coordination modes, and runtime diagnostics.
+---
+
+# trellis-teamwork
+
+`trellis teamwork` is the local multi-agent collaboration runtime. A
+Teamwork Session is the persistent chat or forum object used by the runtime;
+it is independent from the Trellis task lifecycle and does not own business-phase progress.
+Use Teamwork when agents need a durable event log, a bounded teammate
+assignment, a one-shot consultation, or a forum discussion.
+
+Typical user signals: “和 codex/claude 讨论”, “brainstorm with another agent”, “派一个 teammate 做 review”, “open a Teamwork forum”, “look at this thread”, “Teamwork 卡住了 / 没输出”, “progress was truncated”, “how do I use trellis teamwork”.
+
+This skill is an index. Load only the reference file for the current job — do not preload all of them.
+
+## First Commands
+
+```bash
+trellis --version
+trellis teamwork --help
+trellis teamwork list --all
+trellis teamwork list --scope global --all
+```
+
+If the user names a Teamwork Session or thread, inspect it before asking for
+background:
+
+```bash
+trellis teamwork forum <session> --scope global
+trellis teamwork thread <session> <thread> --scope global
+trellis teamwork context list <session> --scope global --thread <thread>
+```
+
+## Route By User Intent
+
+| User intent | Read |
+|---|---|
+| “和 codex/claude 讨论一下”, “brainstorm with another agent” | `references/teamwork-plan-construction.md`, then `references/coordination-modes.md` |
+| “派一个 implement/check agent”, “让 agent review”, “spawn a worker” | `references/teamwork-plan-construction.md`, then `references/teammate-processes.md` |
+| “开 issue 区 / topic 群 / changelog / board”, “make a forum” | `references/teamwork-plan-construction.md` |
+| “看看这个 thread”, “inspect a thread” | `references/teamwork-plan-construction.md` |
+| “Teamwork 卡住了 / 没输出 / progress 被截断”, “teammate stalled” | `references/teammate-processes.md` |
+| “具体命令怎么写”, “what flags does X take” | `references/teamwork-plan-construction.md` |
+
+## Core Rules
+
+- New forum Teamwork Sessions use `--type forum`. A `thread` is one item inside a forum Teamwork Session.
+- Use `--context-file` / `--context-raw` and `trellis teamwork context add/delete/list`.
+- Use `--stdin` or `--text-file` for long messages. Do not put long mixed Chinese/English text in the positional shell argument.
+- Pretty `messages` output is an operator dashboard and may truncate progress. Use `--raw` for audit.
+- `--as` is the speaker or worker handle, depending on the command. Use explicit, stable names when multiple agents or sessions are involved.
+- `--scope project` (default) operates on the current cwd's project bucket; `--scope global` operates on the shared `__global__` bucket. Pick scope deliberately — a global board is invisible from project listings unless `--scope global` is passed.
+- For brainstorm, do multiple pressure-test rounds. One answer plus one confirmation is review, not brainstorm.
+- **Dispatcher wait pattern**: use `--kind done` / `--kind turn_finished` (Trellis-emitted system events), not a user `--tag` as the completion signal. Tags are labels, not runtime completion events.
+- Teamwork Sessions are event-sourced. Do not parse `events.jsonl` first; use `forum`, `thread`, `messages --thread`, and `context list`.
+- `@pennixrv/trellis-core` owns reusable Teamwork Session/thread state, event append, sequence allocation, context/title projection, reducers, and task helpers. The CLI owns flags, terminal rendering, prompts, teammate lifecycle, and process exits.
+- Teamwork plan construction belongs to the current phase coordinator. Teamwork validates and executes a frozen plan; it does not select the task phase, change task status, or create a second task state machine.
+- The native host-created `subagent` remains separate from a Teamwork teammate.
+
+## Reference Files
+
+- `references/teamwork-plan-construction.md` — plan binding, task integration, Teamwork Session and forum commands, reports, and cleanup.
+- `references/teammate-configuration-matrix.md` — candidate profiles, frozen execution configuration, provider capabilities, and role boundaries.
+- `references/coordination-modes.md` — `general`, `advisor`, and `committee` semantics and selection.
+- `references/teammate-processes.md` — dispatch, context injection, waiting, interruption, retry, reconciliation, and diagnostics.
+
+## Not For
+
+- One static review where a markdown file and prompt are enough.
+- Replacing normal tool calls with self-logging.
+- Long-term memory retrieval. Use durable forum Teamwork Sessions for actionable issues, and `trellis mem` (the `trellis-session-insight` skill) for session/history search.

package/dist/templates/common/bundled-skills/trellis-teamwork/references/coordination-modes.md

@@ -0,0 +1,29 @@
+# Coordination modes
+
+The plan's `coordination_mode` selects the call shape. It is independent from
+the teammate role, execution profile, and Teamwork Session type.
+
+## `general`
+
+Use general coordination for one or more independent assignments. Each
+assignment has its own objective, scope, lens, evidence, and acceptance
+criteria. The coordinator may fill available slots in plan order and settle
+each assignment independently.
+
+## `advisor`
+
+Use advisor coordination for one bounded consultation. The plan contains
+exactly one assignment and its result is advice for the current coordinator.
+The result still carries a source digest and acceptance evidence and does not
+change the task or phase by itself.
+
+## `committee`
+
+Use committee coordination when one question benefits from parallel distinct
+lenses. The plan contains two or three assignments in one evaluation group.
+All members share the assignment contract and use distinct lenses. They return
+independent evidence; the coordinator compares the reports after they finish.
+
+Committee members do not debate with one another, run a consensus loop, or use
+a directional counter relationship. If a question does not need independent
+lenses, use general coordination or advisor coordination instead.

package/dist/templates/common/bundled-skills/trellis-teamwork/references/teammate-configuration-matrix.md

@@ -0,0 +1,31 @@
+# Teammate configuration matrix
+
+The candidate source for teammate execution settings is the teammate
+configuration matrix. It is a selection input, not a new role system. A
+profile may provide a default provider and model plus provider-specific
+options. The frozen plan stores the selected execution values in the
+`Teammate Execution Configuration` snapshot so a running batch is unaffected
+by later matrix changes.
+
+The tuple is:
+
+```text
+role + provider + optional profile + model + reasoning effort + options
+```
+
+The role remains `teammate`. Coordination mode is separate from role and
+profile. Supported provider adapters are Codex app-server, DSH ACP, Copilot
+ACP, and Claude Code CLI when their host contracts are available. A provider
+name alone does not prove that its host is installed or verified.
+
+The host capability proof covers only the boundaries required by the selected
+plan: foreground waiting, protected artifact writes, read-only protected
+targets and Git state, disabled native or recursive delegation, isolated
+context, supported transport, and a positive capacity. The CLI refuses a
+dispatch when the selected host cannot prove those properties. It does not
+invent an execution profile or silently change the frozen values.
+
+The bundled role card is `.trellis/agents/teammate.md`. It is provider-neutral
+and limits a teammate to the frozen context and current attempt artifacts. A
+Teamwork teammate is not the native host-created `subagent`; the two have
+different creation paths and contracts.

package/dist/templates/common/bundled-skills/trellis-teamwork/references/teammate-processes.md

@@ -0,0 +1,37 @@
+# Teammate processes
+
+The coordinator creates a queue fact and an immutable claim for each
+assignment, dispatches the selected provider, waits for a terminal host fact,
+and validates the report against the assignment identity, source digest,
+evidence, path, secret, and symlink rules. The teammate writes only its
+current attempt artifacts. It does not modify product source, Git state, task
+status, or another teammate's artifacts.
+
+After a timeout, the same attempt may receive a continuation. A confirmed
+execution or acceptance failure may consume that assignment's explicit retry
+budget and create a new attempt identity. An uncertain command, changed host
+identity, or unconfirmed cancellation enters reconciliation and is not
+automatically duplicated. Reconciliation is a runtime outcome; the task
+coordinator decides whether a later task phase needs a return.
+
+Use the ordinary Teamwork Session commands for a deliberate one-shot or
+interactive discussion:
+
+```bash
+trellis teamwork run [name]
+trellis teamwork spawn <name> --agent <agent> --provider <provider>
+trellis teamwork send <name> --as <agent> --stdin
+trellis teamwork wait <name> --as <agent> --kind done,turn_finished
+trellis teamwork interrupt <name> --as <agent> --to <teammate> --stdin
+trellis teamwork kill <name> --as <teammate>
+```
+
+These commands operate a Teamwork Session and do not replace a frozen plan or
+create a second scheduler. Do not use them to bypass a rejected batch or to
+steer an active managed assignment manually.
+
+For a stalled process, inspect `teamwork list`, `teamwork messages --raw`, the
+provider log, and the host process state in that order. Use `kill` only when
+the process owner and current state are known. The runtime event log is the
+source of truth for coordination state; sidecar process files are diagnostic
+evidence.