dsh-gate-agent 0.1.2 → 0.1.4

package/locale/en.json

@@ -1,6 +1,6 @@
-{
-  "meta": {
-    "title": "Gate",
-    "description": "Phase gate and write policy for agent workflows."
-  }
-}
+{
+  "meta": {
+    "title": "Gate Agent",
+    "description": "Phase/node gate for discuss, planning, implementation, review, verification, and Note lifecycle, with gate commands, tools, and skills."
+  }
+}

package/locale/zh.json

@@ -1,6 +1,6 @@
-{
-  "meta": {
-    "title": "Gate 门禁",
-    "description": "按阶段控制 agent 的写入与评审流程。"
-  }
-}
+{
+  "meta": {
+    "title": "Gate Agent",
+    "description": "用 phase/node 门禁编排讨论、规划、实施、评审、验收与 Note 生命周期，并提供 gate 命令、工具和专项技能。"
+  }
+}

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "dsh-gate-agent",
-  "version": "0.1.2",
+  "version": "0.1.4",
   "type": "module",
-  "description": "Full write gate and phase orchestrator with plugin-local skills.",
+  "description": "Phase/node workflow gate with built-in commands, tools, and skills.",
   "exports": {
     ".": "./lib/index.js",
     "./locale/*.json": "./locale/*.json",

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-research/SKILL.md

@@ -12,6 +12,3 @@ Its job:
 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.
 
-
-
-

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.
-
-
-
-
-
-