@boyingliu01/xp-gate 0.19.2 → 0.20.0

package/plugins/qoder/skills/delphi-review/references/round-templates.md

@@ -0,0 +1,134 @@
+# Delphi Round Templates
+
+## Round 1: 匿名独立评审
+
+### 为什么必须匿名
+
+匿名防止 anchoring bias（锚定偏差）—— 知道其他专家意见后倾向于同意"权威"，不敢提出相反观点。
+
+### 执行方式
+
+每位专家独立收到：原始文档 + 评审模板 + "独立评审，不知道其他专家意见"。
+
+### 输出格式
+
+```markdown
+## 独立评审 - Expert [A/B/C]
+### 优点
+1. [具体优点 + 文档位置]
+### 问题清单
+#### Critical Issues (必须修复才能批准)
+1. [问题] - 位置: [...] - 修复建议: [...]
+#### Major Concerns (必须处理)
+1. [...]
+#### Minor Concerns (需要说明)
+1. [...]
+### 裁决: [APPROVED / REQUEST_CHANGES / REJECTED]
+### 置信度: [X/10]
+### 关键理由
+1. [...]
+```
+
+## Round 2: 交换意见
+
+### 执行方式
+
+每位专家看到：原始文档 + 其他专家的评审 + "响应其他专家的关切，是否调整立场？"
+
+### 输出格式
+
+```markdown
+## Round 2 Response - Expert [A/B/C]
+### 响应其他专家关切
+**Expert [X] 提到: [问题]**
+- 我的立场: [同意/部分同意/不同意] - 理由: [...]
+### 更新后问题清单 / 裁决 / 置信度 / 立场变化说明
+```
+
+## Round 3: 最终立场（如需要）
+
+触发条件：Round 2 后仍无共识。所有专家提交最终绑定立场。必须基于三份成功结果聚合达到 ≥90% 共识，不能以多数票或单个专家结果替代全局批准。
+
+### 输出格式
+
+```markdown
+## Round 3 Final Position - Expert [A/B/C]
+### 最终裁决: [APPROVED / REQUEST_CHANGES / REJECTED]
+### 最终置信度: [X/10]
+### 关键理由 + 与其他专家的差异
+```
+
+## 修复报告格式
+
+```markdown
+## 修复报告
+### Critical Issues 修复 | ### Major Concerns 处理 | ### Minor Concerns 说明
+### 请求重新评审
+```
+
+---
+
+## Requirements Mode: Round 1（匿名独立需求评审）
+
+### 执行方式
+
+architecture、technical、feasibility 三位专家分别独立收到：需求陈述 + CONTEXT.md + grill session 摘要 + "独立评审需求完整性，不知道其他专家意见"。三次执行必须全部成功，且每份结果都记录 `result_type=delphi_expert_result` 和实际请求的 `requested_model`；模型 ID、provider、vendor、gateway 和国籍不受限制。
+
+### 输出格式
+
+```markdown
+## Requirements Review - Expert [A(architecture)/B(technical)/C(feasibility)]
+
+### 需求摘要
+[被评审需求的简短概括]
+
+### 评审焦点
+- 需求完整性: [评估]
+- 需求→AC 映射: [评估]
+- 场景覆盖: [评估]
+- AC 可测试性: [评估]
+- 用户画像清晰度: [评估]
+- 范围边界: [评估]
+
+### 缺口清单 (Gaps)
+#### Critical Gaps (必须解决才能进入设计)
+1. [缺口描述] - 影响: [...] - 补充建议: [...]
+#### Minor Gaps (建议补充但不阻塞)
+1. [...]
+
+### 裁决: [APPROVED / GAPS_FOUND]
+### 置信度: [X/10]
+### 关键理由
+1. [...]
+```
+
+## Requirements Mode: Round 2（带上下文的补充评审，如需要）
+
+### 触发条件
+
+前一轮裁决为 GAPS_FOUND，grill-with-docs 补充访谈后重新评审。最多执行 5 轮。
+
+### 执行方式
+
+三位专家分别收到：更新后的需求陈述 + CONTEXT.md + **前一轮 gaps 列表** + "评估已有缺口是否已修复，是否有新缺口"。每轮仍需三份成功、可验证的独立结果，不得减少专家数。
+
+### 输出格式
+
+```markdown
+## Requirements Review Round [2-5] - Expert [A(architecture)/B(technical)/C(feasibility)]
+
+### Round 1 缺口修复验证
+| Round 1 Gap | 状态 | 说明 |
+|-------------|------|------|
+| [gap 描述] | ✅ 已修复 / ❌ 仍存在 | [验证说明] |
+
+### 新发现缺口（如有）
+1. [新缺口描述]
+
+### 裁决: [APPROVED / GAPS_FOUND]
+### 置信度: [X/10]
+### 立场变化说明
+[与 Round 1 相比的立场变化]
+```
+
+> ⚠️ Round 5 后仍 GAPS_FOUND → `escalation_needed: true`，升级给用户决策。任何较早轮次都不能以两位专家、多数票或单个结果产生 APPROVED 证据。

package/plugins/qoder/skills/delphi-review/scripts/verify-consensus.sh

@@ -0,0 +1,43 @@
+#!/usr/bin/env bash
+# delphi-review: Verify consensus report integrity
+# Checks that delphi-reviewed.json is valid JSON and contains expected verdict field.
+#
+# Usage: bash verify-consensus.sh [state-dir]
+
+set -euo pipefail
+
+STATE_DIR="${1:-.sprint-state}"
+STATE_FILE="$STATE_DIR/delphi-reviewed.json"
+
+if [ ! -f "$STATE_FILE" ]; then
+    echo "SKIP: No delphi-reviewed.json found at $STATE_FILE"
+    exit 0
+fi
+
+# Validate JSON
+if ! command -v node &>/dev/null; then
+    echo "WARN: node not available, skipping JSON validation"
+    exit 0
+fi
+
+node -e "
+const fs = require('fs');
+try {
+    const data = JSON.parse(fs.readFileSync('$STATE_FILE', 'utf8'));
+    const requiredKeys = ['mode', 'timestamp', 'verdict', 'consensus_ratio'];
+    const missing = requiredKeys.filter(k => !(k in data));
+    if (missing.length > 0) {
+        console.error('ERROR: Missing required keys in delphi-reviewed.json:', missing.join(', '));
+        process.exit(1);
+    }
+    const validVerdicts = ['APPROVED', 'PASS_WITH_CAVEATS', 'REQUEST_CHANGES', 'BLOCKED'];
+    if (!validVerdicts.includes(data.verdict)) {
+        console.error('ERROR: Invalid verdict:', data.verdict, '(expected one of:', validVerdicts.join(', '), ')');
+        process.exit(1);
+    }
+    console.log('OK: delphi-reviewed.json is valid with verdict:', data.verdict);
+} catch (e) {
+    console.error('ERROR: delphi-reviewed.json is not valid JSON:', e.message);
+    process.exit(1);
+}
+"

package/plugins/qoder/skills/delphi-review/tools.md

@@ -0,0 +1,29 @@
+# Tools Whitelist — Delphi Review
+
+Delphi Review is a **read-only review skill** that dispatches expert subagents
+and synthesizes their verdicts. It does NOT implement code changes.
+
+## Allowed Tools
+
+| Tool | Usage | Rationale |
+|------|-------|-----------|
+| `Read` | Read design docs, code, configs, specification.yaml | Required for review input analysis |
+| `Glob` | Find files by pattern | Required for context discovery |
+| `Grep` | Search code content | Required for codebase understanding |
+| `Bash` | Read-only: git diff, git log, file stats | Required for change analysis |
+| `Task(subagent_type=oracle)` | Dispatch oracle for deep analysis | Required for complex review questions |
+| `Task(subagent_type=delphi-reviewer-architecture)` | Dispatch architecture expert | Core Delphi expert dispatch |
+| `Task(subagent_type=delphi-reviewer-technical)` | Dispatch technical expert | Core Delphi expert dispatch |
+| `Task(subagent_type=delphi-reviewer-feasibility)` | Dispatch feasibility expert | Core Delphi expert dispatch |
+| `Write(specification.yaml, .code-walkthrough-result.json, delphi-reviewed.json)` | Write output artifacts only | Required for review output persistence |
+| `Skill` | Invoke related skills for context | Required for cross-skill integration |
+| `Question` | Ask user at decision points | Required for user interaction |
+
+## Denied Tools
+
+| Tool | Rationale |
+|------|-----------|
+| `Edit(source code)` | Delphi review NEVER edits implementation code during review |
+| `Write(source code)` | Delphi review NEVER writes implementation code |
+| `Bash(git commit, git push)` | Delphi review NEVER commits or pushes during review |
+| `Task(category=*, subagent_type=build)` | Delphi review NEVER delegates build/implementation tasks |

package/plugins/qoder/skills/domain-modeling/ADR-FORMAT.md

@@ -0,0 +1,64 @@
+# ADR Format
+
+## Filename convention
+
+`docs/adr/{NNNN}-{kebab-case-title}.md`
+
+Where `{NNNN}` is a zero-padded incrementing number (e.g., `0001`, `0002`).
+
+## Structure
+
+```md
+# {NNNN}. {Title}
+
+## Status
+
+Proposed | Accepted | Deprecated | Superseded by ADR-XXXX
+
+## Context
+
+{The issue(s) or situation(s) motivating this decision. What forces are at play? What is the problem?}
+
+## Decision
+
+{The decision made. Stated in full sentences, in the present tense. What did we decide to do?}
+
+## Consequences
+
+### Positive
+- {Benefit 1}
+- {Benefit 2}
+
+### Negative
+- {Trade-off 1}
+- {Trade-off 2}
+
+### Neutral
+- {Neutral observation 1}
+
+## Alternatives Considered
+
+### {Alternative 1 title}
+{Brief description and why it was rejected.}
+
+### {Alternative 2 title}
+{Brief description and why it was rejected.}
+```
+
+## Rules
+
+- **Write for future readers, not present participants.** Future readers won't have the conversation context.
+- **Be honest about trade-offs.** Every decision has costs. Name them.
+- **One decision per ADR.** If you're writing "we decided X AND Y", split them.
+- **Keep the decision short.** 1-3 sentences. The context section is where the complexity lives.
+- **Superseded decisions are not deleted.** When a decision is overturned, create a new ADR that supersedes it. Update the old one's status to "Superseded by ADR-XXXX". This preserves history.
+- **Don't document trivial choices.** If the answer is obvious or easily reversible, skip the ADR.
+
+## When NOT to write an ADR
+
+- The decision is easily reversible.
+- The decision is a personal preference with no team impact.
+- The decision is well-documented elsewhere (e.g., in the project's CONTRIBUTING.md).
+- The decision follows an obvious path with no real alternatives.
+
+When in doubt, skip it. An ADR that shouldn't exist creates more noise than value.

package/plugins/qoder/skills/domain-modeling/CONTEXT-FORMAT.md

@@ -0,0 +1,60 @@
+# 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:
+
+- 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/plugins/qoder/skills/domain-modeling/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: domain-modeling
+description: Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
+---
+
+# 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* `CONTEXT.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
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── docs/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── docs/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.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 CONTEXT.md inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).

package/plugins/qoder/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: grill-with-docs
+description: A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.
+disable-model-invocation: true
+---
+
+Run a `/grilling` session, using the `/domain-modeling` skill.

package/plugins/qoder/skills/grilling/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: grilling
+description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
+---
+
+Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
+
+If a *fact* can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.
+
+Do not act on it until I confirm we have reached a shared understanding.