dsh-gate-agent 0.1.3 → 0.1.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-gate-agent",
-  "version": "0.1.3",
+  "version": "0.1.5",
   "type": "module",
   "description": "Phase/node workflow gate with built-in commands, tools, and skills.",
   "exports": {

package/skills/gate-handoff/SKILL.md

@@ -5,7 +5,7 @@ argument-hint: "What will the next session be used for?"
 disable-model-invocation: true
 ---
 
-Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save under `.scratch/handoff/` in the workspace. Use `gate_artifact_write({ kind: 'handoff', path: '.scratch/handoff/<name>.md', content })`; do not use generic `write`.
 
 Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
 

package/skills/gate-plan-review/SKILL.md

@@ -56,11 +56,10 @@ user-invocable: false
 - 产品范围、行为与验收问题报告给工作项；
 - 本次规划的技术设计问题报告给 Agent Note；引用输入的问题按项目配置反馈其属主；
 - 状态、评审与批准证据报告给工作项；
-- 领域术语问题报告给 技能`gate-domain-modeling` 的属主，技术决定报告给相关 Agent Note。
 
 由 planning worker 决定并执行修正；本 worker 不更新工作项、Note 或就绪状态。
 
-仅当提议为架构决定单独建档时，使用 技能`adr`  的准入条件检查反悔成本与真实权衡。其他 Agent Note 按项目部署后的 README 判断是否有长期设计价值。纯行为规则归产品合同；普通实现细节不因“重要”就自动生成 Note。
+纯行为规则归产品合同；普通实现细节不因“重要”就自动生成 Note。
 
 设计仍依赖临时产品假设时保持非权威。修订产品合同后，检查所有承接同一产品合同的设计，不只修改最先暴露问题的那一份。
 

package/skills/gate-planning/SKILL.md

@@ -64,8 +64,6 @@ user-invocable: false
 
 设计定稿遵循 技术设计规则（[rfc.md](./rfc.md) ） 的合同稳定性与评审条件。Note 的 proposed/implemented 表示交付生命周期，不代替评审和批准证据。
 
-使用项目既有领域语言和适用架构约束。领域术语与模型变化使用 `gate-domain-modeling`；需要为架构决定单独建档时，使用 `adr` 的准入条件判断，在相关 Agent Note 中记录决定。
-
 ### 决定权限
 
 在已同意的产品合同、既有架构和项目约束内，自主解决普通技术选择。

package/skills/gate-planning/rfc.md

@@ -54,8 +54,6 @@
 
 需要产品、业务、兼容性、成本、风险、持久架构方向或其他价值判断时，交给相应决定权限，不把问题伪装成纯技术选择。
 
-接受的决定形成或改变领域语言时，使用 `gate-domain-modeling` SKILL 维护领域资料。需要为架构决定单独建档时，使用 `adr` SKILL 的准入条件判断；决定属于本设计时在同一 Note 中维护，可独立判断的新决定按项目 Note 规则记录。
-
 ## 定稿与评审条件
 
 技术设计可以进入 Plan Review，需要满足：

package/skills/gate-playwright-e2e/SKILL.md

@@ -6,6 +6,10 @@ argument-hint: "项目路径，或要覆盖的功能 / bug"
 
 # Playwright E2E 配置
 
+在 gate 中：模型启用本技能时走 implement；用户在 discuss 调用时只讨论方案，写 config/spec/AGENTS 与安装依赖在 implement 进行。
+
+
+
 分工是固定的：**Agent 写 spec，Playwright runner 跑 spec。** 提需求的这一轮里，Agent 不打开浏览器一格格点页面——那是它最贵、最慢、最不可回归的用法；它只写 Node.js + Playwright 脚本，然后跑命令。脚本一旦落盘，「这个功能对不对」就从一轮轮截图变成一条几秒钟、几乎不花 token、随时可重跑的断言。
 
 这个 skill 一次跑完，产出三样**落盘**的东西：可跑的 `playwright.config.ts`、项目里长期生效的测试规则、覆盖目标行为的 spec。之后日常由项目里的规则接管，换项目、换技术栈、或规则要改的时候再调它。

package/skills/gate-prd/SKILL.md

@@ -10,7 +10,7 @@ disable-model-invocation: true
 
 ## 位置与复用
 
-遵循项目文档分层和既有 PRD 格式。优先更新同一产品主题已有的 PRD；没有已配置的存放位置时，先在对话中起草并请用户决定位置，不自行发布到外部系统。
+遵循项目文档分层和既有 PRD 格式。写入使用 `gate_artifact_write({ kind: 'prd', path, content })`，不要使用通用 `write`。优先更新同一产品主题已有的 PRD；没有已配置的存放位置时，先在对话中起草并请用户决定位置，不自行发布到外部系统。
 
 ## 内容
 

package/skills/gate-research/SKILL.md

@@ -4,14 +4,11 @@ description: Investigate a question against high-trust primary sources and captu
 user-invocable: false
 ---
 
-Spin up a **background agent** to do the research, so you keep working while it reads.
+调用 `gate_research_dispatch({ question, purpose })` 派 research worker，并等待结果。
 
-Its job:
+worker 的职责：
 
 1. Investigate the question against **primary sources** — official docs, source code, specs, first-party APIs — not a secondary write-up of them. Follow every claim back to the source that owns it.
 2. Write the findings to a single Markdown file, citing each claim's source.
-3. Save it where the repo already keeps such notes; match the existing convention, and if there is none, put it somewhere sensible and say where.
-
-
-
+3. Save it with `gate_artifact_write({ kind: 'research', path, content })`；优先项目文档位置，否则 `.scratch/research/`。不要使用通用 `write`。
 

package/skills/gate-writing-for-agents/SKILL.md

@@ -3,6 +3,8 @@ name: gate-writing-for-agents
 description: Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.
 ---
 
+在 gate 中：修改 skill、AGENTS.md 或 agent 文档属于 implement 工作；discuss/plan 只讨论写法，不落盘。
+
 Reference for writing any document an agent consumes — a skill, an `AGENTS.md`, a doc reached by a pointer. The packaging differs; the writing does not: the same levers make each one predictable — the agent taking the same _process_ every run, not producing the same output.
 
 When the document you're writing is a skill, read [`SKILL-MECHANICS.md`](SKILL-MECHANICS.md) for frontmatter, invocation choice, and router skills.

package/skills/gate-domain-modeling/CONTEXT-FORMAT.md

@@ -1,64 +0,0 @@
-# CONTEXT.md Format
-
-## Structure
-
-```md
-# {Context Name}
-
-{One or two sentence description of what this context is and why it exists.}
-
-## Language
-
-**Order**:
-{A one or two sentence description of the term}
-_Avoid_: Purchase, transaction
-
-**Invoice**:
-A request for payment sent to a customer after delivery.
-_Avoid_: Bill, payment request
-
-**Customer**:
-A person or organization that places orders.
-_Avoid_: Client, buyer, account
-```
-
-## Rules
-
-- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
-- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
-- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
-- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
-
-## Single vs multi-context repos
-
-**Single context (most repos):** One `CONTEXT.md` at the repo root.
-
-**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
-
-```md
-# Context Map
-
-## Contexts
-
-- [Ordering](./src/ordering/CONTEXT.md): receives and tracks customer orders
-- [Billing](./src/billing/CONTEXT.md): generates invoices and processes payments
-- [Fulfillment](./src/fulfillment/CONTEXT.md): manages warehouse picking and shipping
-
-## Relationships
-
-- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
-- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
-- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
-```
-
-The skill infers which structure applies:
-
-Resolve the root from project instructions before these checks; the current working directory may be a subproject. Use the project documentation hierarchy for ownership; the context map does not create separate record categories. Paths shown in the map are Markdown links relative to the map file.
-
-- If `CONTEXT-MAP.md` exists, read it to find contexts
-- If only a root `CONTEXT.md` exists, single context
-- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
-
-When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.
-
-

package/skills/gate-domain-modeling/GLOSSARY-FORMAT.md

@@ -1,64 +0,0 @@
-# GLOSSARY.md Format
-
-## Structure
-
-```md
-# {Context Name}
-
-{One or two sentence description of what this context is and why it exists.}
-
-## Language
-
-**Order**:
-{A one or two sentence description of the term}
-_Avoid_: Purchase, transaction
-
-**Invoice**:
-A request for payment sent to a customer after delivery.
-_Avoid_: Bill, payment request
-
-**Customer**:
-A person or organization that places orders.
-_Avoid_: Client, buyer, account
-```
-
-## Rules
-
-- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
-- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
-- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
-- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
-
-## Single vs multi-context repos
-
-**Single context (most repos):** One `GLOSSARY.md` at the repo root.
-
-**Multiple contexts:** A `GLOSSARY-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
-
-```md
-# Glossary Map
-
-## Contexts
-
-- [Ordering](./src/ordering/GLOSSARY.md): receives and tracks customer orders
-- [Billing](./src/billing/GLOSSARY.md): generates invoices and processes payments
-- [Fulfillment](./src/fulfillment/GLOSSARY.md): manages warehouse picking and shipping
-
-## Relationships
-
-- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
-- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
-- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
-```
-
-The skill infers which structure applies:
-
-Resolve the root from project instructions before these checks; the current working directory may be a subproject. Use the project documentation hierarchy for ownership; the context map does not create separate record categories. Paths shown in the map are Markdown links relative to the map file.
-
-- If `GLOSSARY-MAP.md` exists, read it to find contexts
-- If only a root `GLOSSARY.md` exists, single context
-- If neither exists, create a root `GLOSSARY.md` lazily when the first term is resolved
-
-When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.
-
-

package/skills/gate-domain-modeling/SKILL.md

@@ -1,47 +0,0 @@
----
-name: gate-domain-modeling
-description: Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording a durable decision in its selected owner.
-user-invocable: false
----
-
-# Domain Modeling
-
-Actively build and sharpen the project's domain model as you design. This is the *active* discipline: challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `GLOSSARY.md` for vocabulary is not this skill: that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
-
-## File structure
-
-Follow the document ownership entry referenced by project instructions for glossary paths and decisions applicable to the model being discussed. If a required input's owner or scope is unclear, report the configuration gap.
-
-Resolve the repository management root from project instructions, using the Git top-level only as a fallback. Working inside a subproject does not change it. A root `GLOSSARY-MAP.md` selects domain documents when the repository has multiple contexts. Do not create a separate record system per context or derive record categories automatically from contexts.
-
-A single-context project may use a root `GLOSSARY.md`. A root `GLOSSARY-MAP.md`, when present, points to the selected contexts' glossaries; context paths need not be under `src/`. Resolve decision paths separately from the document ownership entry and, for Agent Notes, its configured record roots. Create a glossary or decision record only when there is content for its selected owner. Use the `adr` skill when a separate architecture decision record is warranted.
-
-## During the session
-
-### Challenge against the glossary
-
-When the user uses a term that conflicts with the existing language in `GLOSSARY.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y. Which is it?"
-
-### Sharpen fuzzy language
-
-When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account': do you mean the Customer or the User? Those are different things."
-
-### Discuss concrete scenarios
-
-When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
-
-### Cross-reference with code
-
-When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible. Which is right?"
-
-### Update GLOSSARY.md inline
-
-When a term is resolved, update `GLOSSARY.md` right there. Don't batch these up: capture them as they happen. Use the format in [GLOSSARY-FORMAT.md](./GLOSSARY-FORMAT.md).
-
-`GLOSSARY.md` should be totally devoid of implementation details. Do not treat `GLOSSARY.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
-
-
-
-
-
-