@boyingliu01/xp-gate 0.7.0 → 0.7.1

package/skills/delphi-review/references/qoder-multi-model.md

@@ -1,191 +0,0 @@
-# Qoder Multi-Model Review Guide for Delphi Review
-
-**Version:** v0.6.0  
-**Platform:** Qoder IDE  
-**Status:** Active
-
----
-
-## 1. Overview
-
-Delphi Review requires multi-expert anonymous consensus review using at least 2 different LLM providers. In Qoder, this is achieved through Agent subagent dispatch, leveraging Qoder's built-in multi-model capability.
-
----
-
-## 2. Expert Configuration
-
-### 2.1 Configuration File
-
-Create `.qoder/delphi-config.json` in project root:
-
-```json
-{
-  "experts": {
-    "A": {
-      "role": "architecture",
-      "focus": "System design, scalability, maintainability, SOLID principles",
-      "model_hint": "deepseek-v4-pro"
-    },
-    "B": {
-      "role": "implementation",
-      "focus": "Code quality, testing strategy, error handling, performance",
-      "model_hint": "kimi-k2.6"
-    },
-    "C": {
-      "role": "feasibility",
-      "focus": "Practical constraints, timeline, team capability, risk assessment",
-      "model_hint": "qwen3.6-plus"
-    }
-  },
-  "consensus_threshold": 0.95,
-  "max_rounds": 5,
-  "providers_required": 2
-}
-```
-
-### 2.2 Model Selection Rules
-
-- Experts MUST come from **at least 2 different providers**
-- **Forbidden**: Anthropic, OpenAI, Google (foreign models)
-- **Recommended domestic providers**: DeepSeek, Qwen (Alibaba), Kimi (Moonshot), GLM (Zhipu), MiniMax
-
----
-
-## 3. Execution Flow in Qoder
-
-### 3.1 Round 1: Independent Anonymous Review
-
-For each expert, dispatch an Agent subagent with the expert's specific prompt:
-
-**Expert A (Architecture) — plan-agent**:
-```
-Agent(subagent_type="plan-agent", prompt="""
-You are Expert A in a Delphi consensus review. Your role: Architecture Reviewer.
-Focus: System design, scalability, maintainability, SOLID principles.
-
-Review the following design/code and provide your assessment:
-[REVIEW MATERIAL]
-
-Output format:
-{
-  "expert_id": "A",
-  "verdict": "APPROVED|REQUEST_CHANGES|REJECTED",
-  "issues": [...],
-  "strengths": [...],
-  "suggestions": [...]
-}
-""")
-```
-
-**Expert B (Implementation) — CodeReview subagent**:
-```
-Agent(subagent_type="CodeReview", prompt="""
-You are Expert B in a Delphi consensus review. Your role: Implementation Reviewer.
-Focus: Code quality, testing strategy, error handling, performance.
-
-Review the following code changes:
-[CHANGED FILES]
-""")
-```
-
-**Expert C (Feasibility) — plan-agent**:
-```
-Agent(subagent_type="plan-agent", prompt="""
-You are Expert C in a Delphi consensus review. Your role: Feasibility Arbiter.
-Focus: Practical constraints, timeline, team capability, risk assessment.
-
-Review the following design/code and provide your assessment:
-[REVIEW MATERIAL]
-
-Output format:
-{
-  "expert_id": "C",
-  "verdict": "APPROVED|REQUEST_CHANGES|REJECTED",
-  ...
-}
-""")
-```
-
-### 3.2 Consensus Aggregation
-
-After all experts respond:
-1. Parse each expert's JSON output
-2. Compare verdicts:
-   - All APPROVED → **Consensus: APPROVED**
-   - All REQUEST_CHANGES → Merge issues, present to user
-   - Mixed verdicts → **No consensus**, proceed to Round 2
-3. Calculate issue consensus ratio: issues agreed by ≥95% of experts → resolved
-
-### 3.3 Round 2+: Controlled Feedback
-
-In subsequent rounds, each expert receives other experts' anonymized opinions:
-```
-Agent(subagent_type="plan-agent", prompt="""
-You are Expert A. In Round 1, your verdict was: REQUEST_CHANGES.
-Other experts' anonymized feedback:
-- Expert X: APPROVED, noted [strengths]
-- Expert Y: REQUEST_CHANGES, noted [issues]
-
-Review your assessment in light of others' feedback. Maintain your independence.
-[REVIEW MATERIAL]
-""")
-```
-
-### 3.4 Terminal States
-
-| Condition | Action |
-|-----------|--------|
-| All experts APPROVED + ≥95% issue consensus | **APPROVED** — write `.sprint-state/delphi-reviewed.json` |
-| Max rounds reached without consensus | **REJECTED** — present disagreement summary |
-| Any expert REJECTED with critical issues | **REQUEST_CHANGES** — user must fix and re-review |
-
----
-
-## 4. Degraded Mode
-
-When multi-model subagent dispatch is unavailable:
-
-### 4.1 Single-Model Multi-Role Mode
-
-The orchestrator plays all expert roles sequentially with different prompts:
-
-```
-⚠️ [DEGRADED] 单模型多角色模式
-失去跨 provider 匿名性保护，但保留多视角评审结构。
-建议：在条件允许时恢复多模型模式重新评审。
-```
-
-### 4.2 Degraded Output Format
-
-```json
-{
-  "mode": "design",
-  "verdict": "APPROVED",
-  "degraded": true,
-  "degradation_reason": "Multi-model subagent unavailable",
-  "experts": ["A", "B", "C"],
-  "model": "single"
-}
-```
-
----
-
-## 5. Integration with Sprint Flow
-
-### 5.1 Phase 1 (Design Review)
-
-- Default: 2 experts (A + B)
-- Complex designs: 3 experts (A + B + C)
-- Output: `.sprint-state/delphi-reviewed.json` + `specification.yaml`
-
-### 5.2 Phase 3 (Code Walkthrough)
-
-- Default: 2 experts (A + B)
-- Use `CodeReview` subagent for Expert B
-- Output: `.code-walkthrough-result.json`
-
-### 5.3 HARD-GATE Enforcement
-
-- Phase 2 BUILD cannot start until delphi-review verdict is APPROVED
-- In Qoder: Pre-Edit Gate checks `.sprint-state/delphi-reviewed.json`
-- See sprint-flow SKILL.md for Pre-Edit Gate details

package/skills/sprint-flow/references/qoder-adaptation.md

@@ -1,173 +0,0 @@
-# Qoder Platform Adaptation Guide for Sprint Flow
-
-**Version:** v0.6.0  
-**Platform:** Qoder IDE  
-**Status:** Active
-
----
-
-## 1. Platform Differences
-
-### 1.1 No File-System Event Hooks
-
-| Capability | Claude Code | OpenCode | Qoder |
-|-----------|------------|----------|-------|
-| PreToolUse Hook | ✅ `delphi-review-guard.sh` | ❌ | ❌ |
-| PostToolUse Hook | ✅ `xp-gate-check` | ❌ | ❌ |
-| Custom Tools | ❌ | ✅ `tool()` | ❌ (MCP instead) |
-
-**Adaptation**: Gates embedded in SKILL.md as `<MANDATORY>` instructions. Orchestrator MUST execute checks before each file edit.
-
-### 1.2 No `task()` Subagent API
-
-| Capability | OpenCode | Qoder |
-|-----------|----------|-------|
-| Subagent dispatch | `task(category, load_skills)` | Agent tool (Browser/CodeReview/plan-agent) |
-| Multi-model | Agent config with different models | Qoder multi-model capability |
-| Context isolation | Automatic per-task | Automatic per-Agent |
-
-**Adaptation**: Phase→Agent mapping table in sprint-flow SKILL.md.
-
-### 1.3 No superpowers/gstack Ecosystem
-
-Qoder does not have access to the superpowers or gstack skill ecosystems. All external skill calls are replaced by:
-- **Orchestrator inline execution** (for simple tasks)
-- **Qoder native capabilities** (Memory, CodeReview, browser-use)
-- **Agent subagents** (for complex analysis/planning)
-
----
-
-## 2. External Skill Replacement Matrix
-
-### 2.1 brainstorming (superpowers) → Orchestrator Inline
-
-**Original**: `task(category="deep", load_skills=["brainstorming"])`
-
-**Qoder Replacement**: Orchestrator conducts an interactive requirements exploration dialogue:
-1. Ask clarifying questions about the feature
-2. Analyze existing codebase for relevant modules
-3. Generate a structured design document
-4. Present to user for approval (HARD-GATE)
-
-### 2.2 autoplan (gstack) → plan-agent Subagent
-
-**Original**: `task(category="deep", load_skills=["autoplan"])`
-
-**Qoder Replacement**: Dispatch `plan-agent` subagent with:
-- Design document as input
-- Codebase structure analysis
-- Generate implementation plan with REQ/AC structure
-- Output: specification.yaml draft
-
-### 2.3 freeze/unfreeze (gstack) → Pre-Edit Gate
-
-**Original**: `freeze` locks test directories, `unfreeze` unlocks
-
-**Qoder Replacement**: Pre-Edit Gate in sprint-flow SKILL.md:
-- During Phase 2 freeze state, orchestrator MUST check target file path
-- If file is in test directory → BLOCK with message
-- This is a behavioral constraint, not a physical lock
-
-### 2.4 requesting-code-review (superpowers) → CodeReview Subagent
-
-**Original**: `task(category="unspecified-high", load_skills=["requesting-code-review"])`
-
-**Qoder Replacement**: Dispatch `CodeReview` subagent:
-- Input: changed files since last REQ commit
-- Blind review (no access to business intent, only code)
-- Output: review findings
-
-### 2.5 verification-before-completion (superpowers) → Orchestrator Inline
-
-**Original**: `task(load_skills=["verification-before-completion"])`
-
-**Qoder Replacement**: Orchestrator executes sequentially:
-1. `npm test` / `pytest` / `go test` (test runner)
-2. `npx eslint` / `ruff check` / `golangci-lint` (linter)
-3. `npx tsx src/principles/index.ts` (principles check)
-4. Coverage report check (≥80%)
-
-### 2.6 learn/retro (gstack) → Qoder Memory System
-
-**Original**: `task(load_skills=["learn", "retro"])`
-
-**Qoder Replacement**: 
-- **learn**: `UpdateMemory` with appropriate category
-  - Architecture decisions → `expert_experience`
-  - Coding patterns → `development_practice_specification`
-  - Project structure → `project_introduction`
-- **retro**: `plan-agent` subagent analyzes git log + code quality trends
-  - Output stored via `UpdateMemory` as `task_summary_experience`
-
-### 2.7 browse (gstack) → browser-use MCP
-
-**Original**: `browse` navigates to localhost, interacts with UI
-
-**Qoder Replacement**: Use `browser-use` MCP tools:
-- `navigate_page` → navigate to localhost:3000
-- `click` / `fill` → interact with UI elements
-- `take_screenshot` → capture visual verification
-- `take_snapshot` → get accessibility tree for validation
-
-### 2.8 ship/finishing-branch → Orchestrator Git/GH CLI
-
-**Original**: External skill calls
-
-**Qoder Replacement**: Orchestrator executes:
-- `git add` + `git commit` + `git push`
-- `gh pr create` + `gh pr merge`
-- Standard git workflow (platform-independent)
-
----
-
-## 3. genui Widget Integration
-
-### 3.1 Quality Report Widget
-
-**Trigger**: After Phase 3 REVIEW completes
-
-**Execution**:
-```
-show_widget(widget_path="plugins/qoder/widgets/quality-report.html", data={...quality-report.json contents...})
-```
-
-### 3.2 Sprint Dashboard Widget
-
-**Trigger**: User requests `/sprint-status` or Phase transition
-
-**Execution**:
-```
-show_widget(widget_path="plugins/qoder/widgets/sprint-dashboard.html", data={...sprint-state.json contents...})
-```
-
----
-
-## 4. Memory System Integration
-
-### 4.1 Learnings Categories
-
-| ralph-loop Category | Qoder Memory Category | Scope |
-|--------------------|-----------------------|-------|
-| permanent (architecture) | `expert_experience` | workspace |
-| permanent (convention) | `development_practice_specification` | workspace |
-| permanent (structure) | `project_introduction` | workspace |
-| contextual | Not persisted | session only |
-| sprint retro | `task_summary_experience` | workspace |
-
-### 4.2 Memory Lifecycle
-
-1. **REQ complete** → `UpdateMemory` for permanent learnings
-2. **Sprint Phase 5** → `UpdateMemory` for sprint-level retro
-3. **Next sprint** → `SearchMemory` to recall relevant learnings
-4. **Stale learnings** → User can request memory cleanup
-
----
-
-## 5. Known Limitations
-
-| Limitation | Impact | Mitigation |
-|-----------|--------|-----------|
-| Skill-embedded gates less reliable than hooks | Agent may ignore constraints | `<MANDATORY>` tags + Terminal State Checklist |
-| No physical file-system lock for freeze | Test files could be modified | Pre-Edit Gate + Terminal State verification |
-| Single model for all experts (degraded mode) | Loses cross-provider anonymity | Clearly label degraded reviews |
-| No `k6`/`locust` integration | Load testing limited | Future: MCP server for load testing |