@menghuan1918/dsh-apollo 0.0.0-stage → 0.3.0

package/presets/eng.patch.yml

@@ -0,0 +1,341 @@
+# dsh-apollo bundle patch: the `eng` (工程模式) agent preset, declared as
+# one `@deepseek-ai/dsh-agent-preset` insert row — the DSH 0.2.1 preset
+# mechanism (the `<dshHome>/.agent-presets` scan root is gone; third-party
+# presets ship as bundle-patch insert rows). Loaded after ./cordis.patch.yml
+# per the `dsh.bundle.patch` array in package.json.
+#
+# The `config.plugins` block below is the single source of truth for the
+# preset's row list; it supersedes the former presets/eng/agent.cordis.yml +
+# preset.yml pair (metadata folded into `config`). `config.id` MUST stay
+# `eng`: it is the preset identity historical sessions resume by.
+#
+# Preset-local plugin modules are referenced by bare package subpaths
+# (`@menghuan1918/dsh-apollo/presets/eng/plugins/...`): names inside `config.plugins`
+# resolve from the profile directory's node_modules (where this package is
+# installed or linked; `exports["./presets/*"]` maps the subpath), not from
+# the preset directory.
+
+- insert:
+    - id: preset-eng
+      name: '@deepseek-ai/dsh-agent-preset'
+      config:
+        id: eng
+        name: 工程模式
+        description: >-
+          面向编码与基础设施任务的工程 Agent：内置工程纪律、后台任务与子代理约定、由独立 goal 插件提供的长期目标续跑。
+        order: 10
+        plugins:
+          #
+          # This plugins block is an AGENT-PLANE composition. The roster mounts it ONCE under a
+          # standing scope; every session naming it joins by scope parentage, so the
+          # tools and prompt sections registered here cover each joined agent while a
+          # session's own state stays keyed per Session/Agent inside the plugins. The
+          # host composition (`base.cordis.yml` + `web.cordis.yml`) keeps everything a
+          # preset must not own: the registries themselves, the sandbox and approval
+          # stack, persistence, and the model route.
+          #
+          # A service row here MUST sit inside a group carrying an `isolate` realm.
+          # Without one it publishes into the root realm, where it is process-global —
+          # another preset publishing the same name collides, and a host reader would
+          # resolve one preset's instance for every session; `dsh-agent-preset` rejects
+          # that at mount. `true` means an entry-local realm: this standing mount's own
+          # private instance, apart from every other preset's. (A shared label does NOT
+          # pool instances — `provide()` throws on the second registration under the
+          # same realm symbol; labels join REALMS, and are not what this file needs.)
+
+          # ── identity ────────────────────────────────────────────────────────────────
+
+          # The preset's own persona, shadowing the deployment default for this agent.
+          # One row on purpose: the rich engineering rules live in the user-global
+          # instructions (~/.dsh/AGENTS.md) and the preset's `eng:mode-instructions`
+          # section, not in the persona. `eng:mode-instructions` owns the delegation
+          # policy; the tiers stay global because they track local route config.
+          # 0.2.1's upstream `standard` preset carries `prefix` only: the working-
+          # directory `suffix` line it used to set is gone, and eng follows suit.
+          - id: persona
+            name: '@deepseek-ai/dsh-persona'
+            config:
+              prefix: >-
+                You are a coding agent powered by the {{model}} model.
+
+          # Workspace instructions (repository AGENTS.md files) are injected from the
+          # first request, capped at 64 KiB.
+          - id: agent-instructions
+            name: '@deepseek-ai/dsh-agent-instructions'
+            config:
+              maxBytes: 65536
+
+          # 0.2.1 standard adds the per-step time context (sampled current time,
+          # browser time zone and elapsed time) so date/time reasoning does not depend
+          # on the model's own clock. It consumes host services and provides nothing,
+          # so it needs no realm.
+          - id: time-context
+            name: '@deepseek-ai/dsh-time-context'
+
+          # ── shell ───────────────────────────────────────────────────────────────────
+
+          # `shell-env` stays in the HOST composition: `apps/cli/src/web.ts` injects it to
+          # publish `DSH_WEB_URL`/`DSH_WEB_MODE`, and a host row that injects a service is
+          # the criterion for host-plane ownership — injection resolves before any session
+          # exists, so there is no agent to key by. Behind a preset realm those variables
+          # never reached the model's shell at all. Both shell tools consume the host
+          # registry from here; their executors (`bash-sandbox`/`pwsh-sandbox`) are
+          # host-plane too.
+          - id: tool-bash
+            name: '@deepseek-ai/dsh-tool-bash'
+            disabled: !!js process.platform === 'win32'
+
+          - id: tool-pwsh
+            name: '@deepseek-ai/dsh-tool-pwsh'
+            disabled: !!js process.platform !== 'win32'
+
+          # ── filesystem ──────────────────────────────────────────────────────────────
+
+          # Both register into the host `tools` registry and provide nothing, so
+          # they need no realm. The `fs` service and its policy stay in the host.
+          - id: tool-fs
+            name: '@deepseek-ai/dsh-tool-fs'
+
+          - id: tool-fs-search
+            name: '@deepseek-ai/dsh-tool-fs-search'
+            config:
+              sampleOverCapGlobResults: false
+
+          # ── background jobs ────────────────────────────────────────────────────────
+
+          # Only the model-facing controls. The task REGISTRY stays on the host plane:
+          # its producers sit outside any realm this file could put it in — `tool-bash`
+          # above resolves it with `ctx.get`, and an entry-local realm here is invisible
+          # to every sibling row, so `run_in_background` would answer "background jobs
+          # unavailable" while these controls sat in the catalog. The registry is keyed by
+          # owning agent anyway, so one host instance serves every session. What a preset
+          # chooses is whether its agent can collect and stop background work at all.
+          #
+          # LOCAL OVERRIDE (2026-09-22): `maxConsecutiveWakes` is 5000 instead of the
+          # bundled 3. The budget is spent by every completion that opens a turn on an
+          # idle owner and is restored ONLY by a user-authored message, so a long
+          # unattended chain of background jobs parks after its third wake — from the
+          # fourth completion on, the notice degrades to injection and waits for the
+          # user's next input. Keep this value identical in the eng-noask patch (the
+          # upstream-drift test compares same-id row configs); upstream `standard`
+          # ships no such key, and the drift test whitelists exactly this delta.
+          - id: tool-jobs
+            name: '@deepseek-ai/dsh-tool-jobs'
+            config:
+              maxConsecutiveWakes: 5000
+
+          # The automation-task tools (schedule_create/list/update/delete) are
+          # deliberately omitted from engineering mode: coding/infrastructure work
+          # does not need scheduled reminders. The host `schedule` service and the
+          # sidebar Automation page stay available to other presets.
+
+          # ── skills ──────────────────────────────────────────────────────────────────
+
+          # The skill REGISTRY lives in the host composition and is layered per scope:
+          # these rows register into THIS preset's layer of it, so they need no realm.
+          # `skill-filesystem` contributes local-root discovery for agents on this preset, and
+          # `tool-skill` gives them the catalog and loader; the merged catalog also
+          # carries whatever the deployment registered globally (repository plugins).
+          - id: skill-filesystem
+            name: '@deepseek-ai/dsh-skill-filesystem'
+
+          - id: tool-skill
+            name: '@deepseek-ai/dsh-tool-skill'
+
+          # ── goals ───────────────────────────────────────────────────────────────────
+
+          # Native command-goal/tool-goal rows are deliberately omitted. The goal
+          # domain is owned by the independent dsh-better-goal plugin row in the
+          # top-level patch: it registers one `goal` tool and one `/goal` command
+          # per Agent, hides any legacy goal tools a preset still carries, and has
+          # its own Plugins row for round limits and question timeouts. The two
+          # removed rows remain deliberate removals in tests/upstream-drift.test.mjs,
+          # which asserts they still exist upstream before filtering them out.
+
+          # ── plan mode ───────────────────────────────────────────────────────────────
+
+          # Plan state is per-agent by nature, so an entry-local realm is not a
+          # workaround here — it is the correct lifetime.
+          - id: planning
+            name: cordis:group
+            group: true
+            isolate:
+              planMode: true
+            config:
+              - id: plan-mode
+                name: '@deepseek-ai/dsh-plan-mode'
+                config:
+                  section: |
+                        You are in plan mode. Stay in plan mode until the user approves your plan through exit_plan_mode or switches the session mode. Imperative language to implement changes means plan the implementation, not execute it. A user's conversational agreement — including an answer confirming something you asked — approves nothing and does not end plan mode; fold the confirmed decision into the plan and submit it through exit_plan_mode.
+
+                        Explore first. Use non-mutating reads, searches, static analysis, and checks to ground the plan in the actual repository. Do not edit or write files, change configuration, run formatters or code generation that rewrites tracked files, commit, or otherwise carry out the plan. Prefer existing functions and patterns over new machinery.
+
+                        The tool catalog stays the same across modes for request-cache stability. These plan-mode rules override any later tool description or guidance that suggests using mutation tools; those tools remain listed to keep the tool catalog unchanged. Do not use todo_write to track this planning phase: it tracks implementation after an approved plan, while the plan itself belongs in exit_plan_mode.
+
+                        Resolve discoverable facts by inspection. Use ask_user_question only for user-owned choices or material ambiguity that inspection cannot answer. Do not ask the user where code lives or how current behavior works when you can find out.
+
+                        Make the plan decision-complete: state the goal and success criteria; group implementation changes by subsystem; identify public API, schema, and data-flow changes; cover edge cases, failure modes, tests, acceptance criteria, and explicit assumptions. Keep it concise enough to review but detailed enough that another engineer can implement it without making design decisions.
+
+                        When ready, call exit_plan_mode with the complete plan markdown, starting with a # title. Make exit_plan_mode the only and final tool call in that assistant response: it presents the plan for approval, and implementation begins only in a later step after approval. Do not paste the final plan as a plain reply or ask "should I proceed?" through prose or ask_user_question. If review rejects it, incorporate the feedback and present again. If the review channel is unavailable or aborted, stay in plan mode and ask the user to switch modes manually; do not proceed with implementation.
+
+          # ── compaction ──────────────────────────────────────────────────────────────
+
+          # `compaction-basic` reads `toolResultPrune` through `ctx.get`, so the pruner must
+          # share this realm rather than sit outside it.
+          #
+          # `tokenMeter` is deliberately NOT in this realm: the meter stays on the HOST
+          # plane, and the rows here resolve that one instance. It takes no configuration,
+          # keys every fold by Session, and owns the context-meter projection units the
+          # browser reads for every session — behind a realm those units would come and go
+          # with whichever presets happen to be mounted. What a preset chooses is whether
+          # its agent compacts at all, which is `compaction-basic` below.
+          - id: compaction
+            name: cordis:group
+            group: true
+            isolate:
+              compaction: true
+              toolResultPruner: true
+            config:
+              - id: compaction-basic
+                name: '@deepseek-ai/dsh-compaction-basic'
+
+              - id: command-compact
+                name: '@deepseek-ai/dsh-command-compact'
+
+              - id: tool-result-pruner
+                name: '@deepseek-ai/dsh-compaction-tool-result-pruner'
+                config:
+                  # Deliberately 2x the upstream `standard` preset (8192/4096/1024): eng
+                  # sessions emit large build/test/log tool results, and the extra
+                  # head/tail retention preserves the failure context the agent acts on.
+                  thresholdChars: 16384
+                  headChars: 8192
+                  tailChars: 2048
+
+          # ── delegation and workflows ────────────────────────────────────────────────
+
+          # The `subagents` registry and its spawn/fork backends live in the HOST
+          # composition: the registry is a process singleton whose cross-session queries
+          # the api-proxy serves to the browser, and a provider name may only be
+          # registered once. This preset contributes the delegation TOOLS, which resolve
+          # that host registry.
+          #
+          # `workflows` is different — nothing outside an agent reads it — so every row
+          # that reaches it shares one entry-local realm here, and a consumer left
+          # outside would resolve a host registry this preset does not populate.
+          #
+          # 0.1.2-alpha.4 note: the one-way child `report` tool is gone — parent/child
+          # messaging now rides the globally named `send_message` registered by
+          # `tool-subagent-control` below (children inherit it too), so this preset
+          # mounts no messaging row of its own.
+          - id: delegation
+            name: cordis:group
+            group: true
+            isolate:
+              workflowEngine: true
+            config:
+              - id: tool-subagent-control
+                name: '@deepseek-ai/dsh-tool-subagent-control'
+
+              - id: tool-subagent-list-agents
+                name: '@deepseek-ai/dsh-tool-subagent-control/list-agents'
+
+              - id: tool-subagent
+                name: '@deepseek-ai/dsh-tool-subagent'
+                config:
+                  provider: spawn
+                  toolName: subagent
+                  modelSelectionSettings: true
+
+              # Fork omits model selection so provider/model stay equal to the parent and
+              # the inherited history remains eligible for KV Cache reuse.
+              - id: tool-subagent-fork
+                name: '@deepseek-ai/dsh-tool-subagent'
+                config:
+                  provider: fork
+                  toolName: subagent_fork
+
+              # 0.1.6-alpha.2 renamed `dsh-workflow-worker-thread` to `dsh-workflow-ptc`
+              # (workflow orchestration in the shared sandboxed Node PTC runtime).
+              - id: workflow-ptc
+                name: '@deepseek-ai/dsh-workflow-ptc'
+                config:
+                  provider: spawn
+
+              - id: tool-workflow
+                name: '@deepseek-ai/dsh-tool-workflow'
+
+          # ── remaining model-facing rows ─────────────────────────────────────────────
+
+          - id: tool-ask-user
+            name: '@deepseek-ai/dsh-tool-ask-user'
+
+          - id: tool-todo
+            name: '@deepseek-ai/dsh-tool-todo'
+            config:
+              allowParallelInProgress: true
+
+          # The `web` service and its search/fetch providers stay in the host
+          # composition; only the model-facing tool is per-session. `fetch` reads the
+          # host-mounted SSRF-guarded `web-fetch-http` provider.
+          - id: tool-web
+            name: '@deepseek-ai/dsh-tool-web'
+            config:
+              fetch: true
+              searchTimeoutMs: 60000
+
+          # Declares deliverable files to the user (file-card surface). Upstream
+          # `standard` mounts it; eng is a fork-copy of that block, so this row has to be
+          # carried by hand — `tests/upstream-drift.test.mjs` fails when a shipped
+          # preset gains rows that eng never picked up.
+          - id: present
+            name: '@deepseek-ai/dsh-tool-present'
+
+          # 0.2.1 ships both plugin surfaces disabled by default; enable either only in a
+          # copy of this plugins block (edits saved from the Web editor override
+          # config.plugins by row id from the profile patch).
+          - id: tool-plugin-manager
+            name: '@deepseek-ai/dsh-plugin-manager/tools'
+            disabled: true
+
+          - id: tool-plugin-market
+            name: '@deepseek-ai/dsh-plugin-market/tools'
+            disabled: true
+
+          # ── subagent waiting ─────────────────────────────────────────────────────────
+
+          # Preset-local plugin: explicit wait for one continuable child to settle, so
+          # the agent can block on a specific subagent (pi-style await_task semantics)
+          # without giving up send_message continuations. The module specifier is a
+          # bare subpath of this package (@menghuan1918/dsh-apollo/presets/eng/plugins/...):
+          # config.plugins names resolve from the profile directory's node_modules,
+          # where this package is installed or linked; it has zero bare imports on
+          # purpose.
+          - id: tool-wait-subagent
+            name: '@menghuan1918/dsh-apollo/presets/eng/plugins/wait-subagent/index.js'
+
+          # ── exit guard ───────────────────────────────────────────────────────────────
+          #
+          # Preset-local plugin: pi-atlas 式退出守卫。回合结束（agent/turn-stopping）
+          # 时若有运行中的直接子代理或后台任务，注入 next-step 提醒（agent.steer）
+          # 强制回合继续，直到 wait_subagent / job_output / job_kill 处理完毕或用户
+          # 中断（被中断回合不触发）。开关为正式 Config.exitGuard，默认关闭，
+          # 每次事件读取当前值，设置保存后即时生效。监听器注册型
+          # 插件，无服务发布，无需 realm。
+          - id: eng-exit-guard
+            name: '@menghuan1918/dsh-apollo/presets/eng/plugins/exit-guard/index.js'
+
+          # ── mode instructions ────────────────────────────────────────────────────────
+
+          # Preset-local prompt section carrying the two eng-only rules: the exit guard
+          # contract and the delegation/orchestration policy (the latter moved out of the
+          # user-global ~/.dsh/AGENTS.md on 2026-09-11 — the model tiers stay there
+          # because they mirror this host's `subagent-model-selection` route list).
+          # Registered as a system-prompt section (order 1, right after the persona slot)
+          # so it is scoped to sessions mounted on this preset and nothing else; injected
+          # from the first request alongside the other sections.
+          # This plugins block (presets/eng.patch.yml) is the single source of truth;
+          # the 0.2.1 bundle-patch mechanism loads it straight from this file, with no
+          # boot-time copy in between.
+          - id: eng-mode-instructions
+            name: '@menghuan1918/dsh-apollo/presets/eng/plugins/mode-instructions/index.js'

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: brainstorming
+description: "把大型需求设计为多个协同 Spec。仅当用户显式调用 /brainstorming，或要求把大型任务拆分为可执行 Spec 时使用。"
+---
+
+# 大型任务头脑风暴
+
+把大型需求整理为一个获批的主 Spec 和至少两个可执行子 Spec。保持 KISS：只沿真实的职责、依赖或验证边界拆分。
+
+**终态是交接给 `/exec`。** 不得实现功能、创建 worktree 或调用开发技能。用户批准书面 Spec 后停止。
+
+## 流程
+
+1. **探索项目上下文** — 检查文件、文档和当前项目状态。事实自己查，不问用户。
+2. **逐一提问** — 每条消息只问一个决策问题，系统遍历设计树，每个问题以推荐答案开头。区分事实（自行查明）与决策（用户定夺）。详见下文提问规则。
+3. **给出 2-3 个方案** — 含权衡和推荐，以推荐方案开头。
+4. **分段展示设计** — 按复杂度决定每段长度，每段取得用户确认。需拆分时展示拆分方案（主 Spec + 子 Spec、依赖顺序、共享契约、集成验收）。
+5. **写入全部 Spec** — 写盘后自审（占位符、矛盾、歧义、过度细节），内联修复。详见下文自审。
+6. **派 spec-reviewer 审查** — 按 [`spec-document-reviewer-prompt.md`](spec-document-reviewer-prompt.md) 派一个全新只读 `subagent`（质量档 = 本会话最强模型）审查主 Spec 与全部子 Spec；修复阻塞项，必要时复派。
+7. **请用户审阅** — 按反馈修改直至批准。
+8. **交接给 `/exec`** — 告知用户用主 Spec 路径调用 `/exec`。
+
+完成标准：主 Spec + 全部子 Spec 已写入磁盘，用户已批准，已给出 `/exec` 调用方式。
+
+## 提问规则
+
+- **每条消息只问一个问题。** 等用户反馈再继续。一次问多个会导致混乱。
+- **给出推荐答案。** 附推理，用户可接受、拒绝或修改。
+- **事实 vs 决策。** 事实查代码库或文档获得，不问用户；决策展示给用户等待回答。
+- **优先多选题**，开放式问题也可以。
+- **聚焦理解：** 目标、约束、成功标准、架构、错误处理、测试。
+
+共识达成前不写 Spec。后续答案改变前提时，回头修正既有决定。
+
+## 设计粒度
+
+子 Spec 定义**做什么和为什么**，以及独立实现和验证所需的边界。不是实现食谱。（主 Spec 不在此列——它只是目标 + 索引，见拆分准则。）
+
+- 包含目标、范围、关键决策、组件职责、交互、外部可观察行为、错误语义、验收标准、测试范围。
+- 把局部编码选择留给实现。不含代码、伪代码、私有类型设计、逐文件修改清单、分步指令。
+- 精确的公共契约（API 路由、共享 schema、配置键）仅在兼容性或迁移依赖时写入。
+
+## 拆分准则
+
+主 Spec 只承载总目标 + 索引（见下文多 Spec 结构），不承载任何具体执行内容。**鼓励多写子 Spec**——任务有几个独立单元就拆几个，下限两个，但更细的拆分只要每个子 Spec 仍能独立实现、独立验证就值得。每个子 Spec 必须能独立实现、独立测试，适合独立的 Spec → 实现周期。
+
+**拆分有价值时：** 任务确实复杂，有多个独立子系统或可并行轨道；每个子 Spec 接口清晰；拆分提升清晰度而非仅为并行。
+
+**过度拆分信号：** 子 Spec 间循环依赖；无法独立验证；共享契约多处不一致；拆出无独立职责的子 Spec。
+
+质量优先于并行——为清晰而拆分，不仅为了并行执行。
+
+## 多 Spec 结构
+
+### 主 Spec
+
+**只做总目标 + 索引，不承载执行。** 内容限于：总目标、范围与非目标、子 Spec 索引（每个子 Spec 一行：职责 + 路径）、依赖 DAG 与并行分组、整体验收的指向。关键决策、共享契约、组件职责、交互、错误语义等具体内容一律下沉到子 Spec；主 Spec 只指明每个契约由哪个子 Spec 定义/拥有。不得在主 Spec 里实现任何东西。
+
+### 子 Spec
+
+独立实现、审查、测试和提交所需：边界明确的目标、范围内/外行为、依赖、输入输出和共享契约、错误语义、验收标准、聚焦验证范围、指向主 Spec 的链接。不复制主 Spec，只带入执行所需契约。
+
+## 文件布局
+
+落盘位置按工作区实际情况择一，不要两处都写：
+
+```text
+<工作区>/.workspace-docs/specs/MM-DD-<主题>-主设计/   # 工作区有 .workspace-docs/ 时用它
+<目标仓库>/docs/specs/MM-DD-<主题>-主设计/             # 否则用目标仓库自己的 specs 目录
+├── MM-DD-<主题>-主设计.md
+├── MM-DD-<主题>-<子任务A>-设计.md
+└── MM-DD-<主题>-<子任务B>-设计.md
+```
+
+- 主 Spec 与子 Spec 双向链接。
+- 目录内已有其它 Spec 时，沿用其文件名与头格式，不引入第二套约定。
+- 写入 `.workspace-docs/` 时每篇带 OKF 头部（`type: Design Spec`、`title`、`description`、`tags`、`status`、`repos`）；提交推送遵循该仓库自己的 `AGENTS.md`。目标仓库无此约定时用仓库现有文档格式，不新造 OKF。
+
+## 自审
+
+写入后用新鲜眼光检查：占位符（`TODO`/`TBD`）、内部一致性、范围聚焦、歧义、过度细节。内联修复全部问题。这是自己先过一遍；随后派 spec-reviewer 子代理做独立审查（流程第 6 步）。
+
+## 可视化辅助
+
+当展示优于讲述（mockup、布局、架构图、方案对比）时，写一个自包含 HTML 到系统临时目录（`$TMPDIR`，未设置时 `/tmp`），文件名 `brainstorm-<主题>-<序号>.html`：
+
+- 用 write 工具写完整文档：内联 CSS、无外部依赖、无脚本、无服务；每页 2-4 个选项或变体。
+- 文件名不复用；迭代就写新文件（`-2`、`-3`）。
+- 告知用户文件路径（DSH 界面可直接打开预览），并用一两句话概括页面内容；用户看后回到对话作答，不采集点击。
+- 每个问题独立判断是否需要可视化；概念性选择（A/B/C 方案、取舍清单）留在对话里。

package/skills/brainstorming/spec-document-reviewer-prompt.md

@@ -0,0 +1,50 @@
+# Spec Document Reviewer Prompt Template
+
+Use this template when dispatching a spec document reviewer via the `subagent` tool (fresh read-only child, quality tier = the strongest model this session offers; omit provider/model to inherit the parent route).
+
+**Purpose:** Verify a main decomposition spec or child spec is complete, consistent, and ready for implementation.
+
+**Dispatch after:** Spec document is written to the workspace's spec directory (`.workspace-docs/specs/` where that convention exists, otherwise the target repo's own specs directory).
+
+```
+subagent(
+  prompt="You are a spec document reviewer. Verify this spec is complete and ready for implementation.
+
+    **Spec to review:** [SPEC_FILE_PATH]
+    **Spec type:** [main decomposition | child]
+    **Main spec, if this is a child spec:** [MAIN_SPEC_FILE_PATH or N/A]
+
+    ## What to Check
+
+    | Category | What to Look For |
+    |----------|------------------|
+    | Frontmatter | Where the workspace uses OKF: parseable YAML frontmatter with `type: Design Spec`, `title`, `description`, `tags`, `status`, and `repos` (plural `tags`, never a singular `tag`). Where it does not: the header matches the surrounding specs instead |
+    | Completeness | TODOs, placeholders, "TBD", incomplete sections |
+    | Consistency | Internal contradictions, conflicting requirements |
+    | Clarity | Requirements ambiguous enough to cause someone to build the wrong thing |
+    | Scope | Main specs decompose large work into child specs; child specs are independently implementable and do not try to implement the whole main spec |
+    | YAGNI | Unrequested features, over-engineering |
+
+    ## Calibration
+
+    **Only flag issues that would cause real problems during implementation.**
+    A missing section, a contradiction, or a requirement so ambiguous it could be
+    interpreted two different ways — those are issues. Minor wording improvements,
+    stylistic preferences, and "sections less detailed than others" are not.
+
+    Approve unless there are serious gaps that would lead to a flawed implementation. Do not reject a main decomposition spec merely because it covers multiple subsystems; reject it only if it lacks clear child specs, ordering, boundaries, or shared contracts. Do not reject a child spec merely because it does not implement the whole main spec.
+
+    ## Output Format
+
+    ## Spec Review
+
+    **Status:** Approved | Issues Found
+
+    **Issues (if any):**
+    - [Section X]: [specific issue] - [why it matters for implementation]
+
+    **Recommendations (advisory, do not block approval):**
+    - [suggestions for improvement]
+```
+
+**Reviewer returns:** Status, Issues (if any), Recommendations

package/skills/code-review/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: code-review
+description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews as parallel `subagent` delegations and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
+---
+
+# Code Review
+
+Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
+
+- **Standards** — does the code conform to this repo's documented coding standards?
+- **Spec** — does the code faithfully implement the originating issue / PRD / spec?
+
+Both axes run as parallel `subagent` delegations so they don't pollute each other's context, then this skill aggregates their findings.
+
+## Process
+
+### 1. Pin the fixed point
+
+Whatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. If they didn't specify one, ask for it.
+
+Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
+
+Before going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff should fail here — not inside two parallel agents.
+
+### 2. Identify the spec source
+
+Look for the originating spec, in this order:
+
+1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.)
+2. A path the user passed as an argument.
+3. A spec/PRD file under `docs/`, `specs/`, `.workspace-docs/`, or `.scratch/` matching the branch name or feature.
+4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** agent will skip and report "no spec available".
+
+### 3. Identify the standards sources
+
+Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md`, `CONTRIBUTING.md`, `CLAUDE.md`, or `AGENTS.md`.
+
+On top of whatever the repo documents, the Standards axis always carries the **smell baseline** below — a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:
+
+- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.
+- **Always a judgement call.** Each smell is a labelled heuristic ("possible Feature Envy"), never a hard violation — and, like any standard here, skip anything tooling already enforces.
+
+Each smell reads *what it is* → *how to fix*; match it against the diff:
+
+- **Mysterious Name** — a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.
+- **Duplicated Code** — the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.
+- **Feature Envy** — a method that reaches into another object's data more than its own. → move the method onto the data it envies.
+- **Data Clumps** — the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.
+- **Primitive Obsession** — a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.
+- **Repeated Switches** — the same `switch`/`if`-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.
+- **Shotgun Surgery** — one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.
+- **Divergent Change** — one file or module is edited for several unrelated reasons. → split so each module changes for one reason.
+- **Speculative Generality** — abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.
+- **Message Chains** — long `a.b().c().d()` navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.
+- **Middle Man** — a class or function that mostly just delegates onward. → cut it, call the real target direct.
+- **Refused Bequest** — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
+
+### 4. Spawn both sub-agents in parallel
+
+Send both `subagent` calls in a single message — each a fresh child (quality tier = the strongest model this session offers; omit provider/model to inherit the parent route) with a fully self-contained prompt; children see none of this conversation.
+
+**Standards sub-agent prompt** — include:
+
+- The full diff command and commit list.
+- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full — the sub-agent has no other access to it.
+- The brief: "Report — per file/hunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
+
+**Spec sub-agent prompt** — include:
+
+- The diff command and commit list.
+- The path or fetched contents of the spec.
+- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
+
+If the spec is missing, skip the Spec agent and note this in the final report.
+
+### 5. Aggregate
+
+Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings — the two axes are deliberately separate.
+
+End with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any).
+
+## Handling review feedback
+
+When you receive feedback from a review:
+
+1. **Verify before implementing.** Check each finding against the codebase — does it break existing functionality? Is the reviewer missing context? Is the current implementation intentional?
+2. **Push back with reasoning** when a finding is wrong — reference working code, tests, or architectural decisions.
+3. **No performative agreement.** State the fix, not "Great point!" or "You're absolutely right!" — just fix it and show the result.
+4. **YAGNI check.** When a reviewer suggests "implementing properly", grep for actual usage. If unused, propose removal instead.
+5. **Fix in order:** blocking issues → simple fixes → complex fixes. Test each fix individually.

package/skills/dev/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: dev
+description: "DSH 执行后端的节点契约：实现节点与审查节点的 prompt 要求、报告 schema 与失败语义。"
+---
+
+# 内置开发后端（节点契约）
+
+本技能定义执行后端的两类节点。波次编排（worktree、合并、清理、CR 循环调度）归 `/exec`；本技能不得创建、合并或删除 worktree。子代理没有独立工作目录，也看不到编排会话：节点的一切输入靠 prompt 自带（worktree 绝对路径、Spec 路径、共享契约、验证命令），bash 一律 `workdir`、文件工具一律绝对路径。
+
+「质量档」指本会话可用的最强模型；不指定路由时子代理继承父会话的 provider/model，具体档位由调用方的会话配置决定，本技能不写死供应商。
+
+## 实现节点（develop）
+
+一个全新子代理（质量档）处理恰好一个子 Spec，以预建 worktree 模式遵循 `main-agent-driven-development`（在 `/exec` 的 workflow 波次中跳过其内部 CR 步骤——CR 循环由编排脚本承担，节点不自行派 reviewer）。
+
+报告 schema（结构化输出）：
+
+```js
+{
+  status: 'complete' | 'blocked',
+  commit: '<最终 commit SHA>',
+  verification: '<本轮已跑的验证命令与结果>',
+  summary: '<实现摘要，供 reviewer 与编排器使用>',
+  blocker: '<status=blocked 时必填>'
+}
+```
+
+## 审查节点（review-only）
+
+全新只读子代理（质量档）。prompt 自带：worktree 绝对路径、diff 范围、Spec 路径、实现摘要、已跑验证。四态判定 schema：
+
+```js
+{
+  status: 'APPROVED' | 'APPROVED_WITH_NOTES' | 'CHANGES_REQUIRED' | 'BLOCKED',
+  findings: ['<问题，附文件与行号>']
+}
+```
+
+严重正确性错误、Spec 缺口、集成风险、安全问题或缺失验证必须 `CHANGES_REQUIRED`。不得编辑、提交、合并。
+
+## 失败语义
+
+子代理失败（error / 空返回）= `node-failed`；`blocked`、超时、部分回复或未提交的结果均不得视为完成。调用方决定重派，或仅在对同一子 Spec 解除阻塞时用 `send_message` 续谈。不得复用节点处理其他子 Spec。