ssd-ql-workflow 0.1.0

package/templates/opencode/commands/opsx-verify.md

@@ -0,0 +1,161 @@
+---
+description: Verify implementation matches change artifacts before archiving
+---
+
+Verify that an implementation matches the change artifacts (specs, tasks, design).
+
+**Input**: Optionally specify a change name after `/opsx-verify` (e.g., `/opsx-verify add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have implementation tasks (tasks artifact exists).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifacts exist for this change
+
+3. **Get the change directory and load artifacts**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
+
+4. **Initialize verification report structure**
+
+   Create a report structure with three dimensions:
+   - **Completeness**: Track tasks and spec coverage
+   - **Correctness**: Track requirement implementation and scenario coverage
+   - **Coherence**: Track design adherence and pattern consistency
+
+   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
+
+5. **Verify Completeness**
+
+   **Task Completion**:
+   - If tasks.md exists in contextFiles, read it
+   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
+   - Count complete vs total tasks
+   - If incomplete tasks exist:
+     - Add CRITICAL issue for each incomplete task
+     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
+
+   **Spec Coverage**:
+   - If delta specs exist in `openspec/changes/<name>/specs/`:
+     - Extract all requirements (marked with "### Requirement:")
+     - For each requirement:
+       - Search codebase for keywords related to the requirement
+       - Assess if implementation likely exists
+     - If requirements appear unimplemented:
+       - Add CRITICAL issue: "Requirement not found: <requirement name>"
+       - Recommendation: "Implement requirement X: <description>"
+
+6. **Verify Correctness**
+
+   **Requirement Implementation Mapping**:
+   - For each requirement from delta specs:
+     - Search codebase for implementation evidence
+     - If found, note file paths and line ranges
+     - Assess if implementation matches requirement intent
+     - If divergence detected:
+       - Add WARNING: "Implementation may diverge from spec: <details>"
+       - Recommendation: "Review <file>:<lines> against requirement X"
+
+   **Scenario Coverage**:
+   - For each scenario in delta specs (marked with "#### Scenario:"):
+     - Check if conditions are handled in code
+     - Check if tests exist covering the scenario
+     - If scenario appears uncovered:
+       - Add WARNING: "Scenario not covered: <scenario name>"
+       - Recommendation: "Add test or implementation for scenario: <description>"
+
+7. **Verify Coherence**
+
+   **Design Adherence**:
+   - If design.md exists in contextFiles:
+     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
+     - Verify implementation follows those decisions
+     - If contradiction detected:
+       - Add WARNING: "Design decision not followed: <decision>"
+       - Recommendation: "Update implementation or revise design.md to match reality"
+   - If no design.md: Skip design adherence check, note "No design.md to verify against"
+
+   **Code Pattern Consistency**:
+   - Review new code for consistency with project patterns
+   - Check file naming, directory structure, coding style
+   - If significant deviations found:
+     - Add SUGGESTION: "Code pattern deviation: <details>"
+     - Recommendation: "Consider following project pattern: <example>"
+
+8. **Generate Verification Report**
+
+   **Summary Scorecard**:
+   ```
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   ```
+
+   **Issues by Priority**:
+
+   1. **CRITICAL** (Must fix before archive):
+      - Incomplete tasks
+      - Missing requirement implementations
+      - Each with specific, actionable recommendation
+
+   2. **WARNING** (Should fix):
+      - Spec/design divergences
+      - Missing scenario coverage
+      - Each with specific recommendation
+
+   3. **SUGGESTION** (Nice to fix):
+      - Pattern inconsistencies
+      - Minor improvements
+      - Each with specific recommendation
+
+   **Final Assessment**:
+   - If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
+   - If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
+   - If all clear: "All checks passed. Ready for archive."
+
+**Verification Heuristics**
+
+- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
+- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
+- **Coherence**: Look for glaring inconsistencies, don't nitpick style
+- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
+- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
+
+**Graceful Degradation**
+
+- If only tasks.md exists: verify task completion only, skip spec/design checks
+- If tasks + specs exist: verify completeness and correctness, skip design
+- If full artifacts: verify all three dimensions
+- Always note which checks were skipped and why
+
+**Output Format**
+
+Use clear markdown with:
+- Table for summary scorecard
+- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
+- Code references in format: `file.ts:123`
+- Specific, actionable recommendations
+- No vague suggestions like "consider reviewing"

package/templates/opencode/commands/sdd-apply.md

@@ -0,0 +1,11 @@
+---
+description: Execute SDD workflow tasks
+---
+
+Execute tasks from the SDD workflow.
+
+This command delegates to the openspec-apply-change skill.
+
+**Input**: Optional change name or batch number.
+
+**Note**: This is an alias for `/opsx-apply`

package/templates/opencode/commands/sdd-continue.md

@@ -0,0 +1,11 @@
+---
+description: Continue SDD workflow - create next artifact
+---
+
+Continue the SDD workflow by creating the next artifact.
+
+This command delegates to the openspec-continue-change skill.
+
+**Input**: Optional change name.
+
+**Note**: This is an alias for `/opsx-continue`

package/templates/opencode/commands/sdd-new.md

@@ -0,0 +1,24 @@
+---
+description: Start a new SDD (Skill-Driven Development) workflow
+---
+
+Start a new Skill-Driven Development workflow using trinity-workflow schema.
+
+**Input**: Change name (kebab-case) or description.
+
+**Steps**
+
+1. If no input, ask what to build using AskUserQuestion
+
+2. Create change with trinity-workflow schema:
+   ```bash
+   openspec new change "<name>" --schema trinity-workflow
+   ```
+
+3. Show status and first artifact instructions
+
+**Output**
+- Change created with trinity-workflow schema
+- Ready for proposal creation
+
+**Note**: This is an alias for `/opsx-new` with `--schema trinity-workflow`

package/templates/opencode/commands/sdd-status.md

@@ -0,0 +1,21 @@
+---
+description: Show SDD workflow status
+---
+
+Show current SDD workflow status and tracking layer progress.
+
+**Input**: Optional change name.
+
+**Steps**
+
+1. Get openspec status:
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+2. If tracking files exist, show:
+   - Current phase (from task_plan.md)
+   - Progress percentage
+   - Recent activity (from progress.md)
+
+**Note**: This is an alias for `/opsx-status` with tracking layer info

package/templates/openspec/config.yaml

@@ -0,0 +1,97 @@
+# ================================================
+# OpenSpec 项目配置
+# Schema: trinity-workflow（三位一体架构工作流）
+# ================================================
+schema: trinity-workflow
+
+# ================================================
+# 项目上下文（注入所有产出物）
+# ================================================
+context: |
+  语言：中文（简体）
+  所有产出物必须用简体中文撰写。
+
+  # 项目技术栈
+  Tech stack: TypeScript, React, Node.js
+
+  # ═══════════════════════════════════════════════
+  # 三位一体架构（Trinity Architecture）
+  # ═══════════════════════════════════════════════
+
+  本项目使用 trinity-workflow schema，它整合了：
+
+  ## 1. 追踪层：Planning-with-Files
+  - task_plan.md: 阶段、目标、决策、错误日志
+  - findings.md: 技术发现、架构决策
+  - progress.md: 会话进度日志
+
+  ## 2. 方法层：阶段式产出
+  - proposal.md: 需求探索（@brainstorming）
+  - design.md: 技术设计（@writing-plans）
+  - specs/: 功能规格（Gherkin 格式）
+  - tasks.md: 任务分解（@executing-plans）
+
+  ## 3. 执行层：3-Strike 协议
+  - Attempt 1: 诊断并修复
+  - Attempt 2: 尝试替代方案
+  - Attempt 3: 重新思考问题
+  - 3次失败后: 升级给用户
+
+  [MUST] 执行任何工作流前，调用 planning-with-files 技能初始化追踪。
+
+# ================================================
+# 产出物规则（按 artifact 类型）
+# ================================================
+rules:
+  proposal:
+    - 字数控制在 500 字以内
+    - 必须包含 Non-goals 章节
+    - 必须提供 2-3 个方案选项
+    - 必须定义成功指标
+  design:
+    - 必须包含架构图
+    - 必须列出风险与缓解措施
+    - 必须说明 Breaking Changes
+  specs:
+    - 使用 Given/When/Then 格式
+    - 覆盖 Happy Path、Edge Cases、Error Cases
+  tasks:
+    - 每个任务 2-5 分钟可完成
+    - 每个任务有明确的验证步骤
+    - 任务按批次（Batch）组织
+
+# ================================================
+# 三位一体架构 - Superpowers 技能映射
+# ================================================
+superpowers:
+  enabled: true
+
+  skillMapping:
+    brainstorming:
+      triggers: ["@brainstorming", "/brainstorming"]
+      generates: "proposal.md"
+      instruction: |
+        Use the Skill tool with skill: "planning-with-files" 初始化追踪
+        然后进行需求探索和方案设计
+    writing-plans:
+      triggers: ["@writing-plans", "/writing-plans"]
+      generates: ["design.md", "tasks.md"]
+      instruction: |
+        Use the Skill tool with skill: "excalidraw-diagram" 生成架构图（可选）
+        创建技术设计文档和任务清单
+    executing-plans:
+      triggers: ["@executing-plans", "/executing-plans"]
+      generates: "tasks.md"
+      instruction: |
+        Use the Skill tool with skill: "openspec-apply-change" 执行任务
+        按批次完成 tasks.md 中的任务
+
+  skillOutputs:
+    brainstorming:
+      pattern: "docs/plans/*-design.md"
+      target: "proposal.md"
+    writing-plans:
+      pattern: "docs/plans/*-plan.md"
+      target: "design.md"
+    executing-plans:
+      target: "tasks.md"

package/templates/openspec/schemas/trinity-workflow/schema.yaml

@@ -0,0 +1,184 @@
+name: trinity-workflow
+version: 1
+description: |
+  三位一体架构工作流 - 集成追踪层、方法层、执行层
+
+  核心特性：
+  - 追踪层：Planning-with-Files 自动追踪进度
+  - 方法层：按阶段生成产出物
+  - 执行层：3-Strike 错误处理协议
+
+# ================================================
+# Workflow Artifacts 定义
+# ================================================
+artifacts:
+  # ----------------------------------------------
+  # Phase 1: 需求探索
+  # ----------------------------------------------
+  - id: proposal
+    generates: proposal.md
+    description: 需求探索与方案设计
+    template: proposal.md
+    instruction: |
+      ## Skill 调用
+      触发词: @brainstorming 或 /brainstorming
+      [MUST] 执行前调用：Use the Skill tool with skill: "planning-with-files"
+
+      创建需求提案文档，聚焦于 WHY 和 WHAT。
+
+      [MUST] 创建前先初始化追踪文件：
+      - task_plan.md: 阶段、目标、决策、错误日志
+      - findings.md: 技术发现、架构决策
+      - progress.md: 会话进度日志
+
+      关键点：
+      1. 明确问题陈述（Problem Statement）
+      2. 提出多个方案选项（Options A/B/C）
+      3. 定义成功指标（Success Metrics）
+      4. 列出非目标（Non-goals）
+      5. 评估影响范围（Impact Assessment）
+
+      完成后更新 task_plan.md：
+      - Phase: proposal
+      - Status: complete
+      - Progress: 20%
+    requires: []
+
+  # ----------------------------------------------
+  # Phase 2: 技术设计
+  # ----------------------------------------------
+  - id: design
+    generates: design.md
+    description: 技术架构设计
+    template: design.md
+    instruction: |
+      ## Skill 调用
+      触发词: @writing-plans 或 /writing-plans
+      [OPTIONAL] 架构图：Use the Skill tool with skill: "excalidraw-diagram"
+
+      创建技术设计文档，聚焦于 HOW。
+
+      关键点：
+      1. 架构概述（Architecture Overview）
+      2. 数据模型（Data Models）
+      3. API 设计（API Design）
+      4. 组件设计（Component Design）
+      5. 风险与缓解（Risks & Mitigations）
+
+      完成后更新 task_plan.md：
+      - Phase: design
+      - Status: complete
+      - Progress: 40%
+
+      在 findings.md 记录架构决策（ADR）。
+    requires:
+      - proposal
+
+  # ----------------------------------------------
+  # Phase 3: 规格说明
+  # ----------------------------------------------
+  - id: specs
+    generates: specs/**/*.md
+    description: 功能规格说明（Gherkin 格式）
+    template: spec.md
+    instruction: |
+      创建功能规格说明文档。
+
+      使用 Gherkin 格式（Given/When/Then）：
+      - Feature: 功能名称
+      - Scenario: 场景描述
+      - Given: 前置条件
+      - When: 触发动作
+      - Then: 期望结果
+
+      覆盖三种场景：
+      - Happy Path: 成功路径
+      - Edge Cases: 边界情况
+      - Error Cases: 错误处理
+
+      完成后更新 task_plan.md：
+      - Phase: specs
+      - Status: complete
+      - Progress: 60%
+    requires:
+      - design
+
+  # ----------------------------------------------
+  # Phase 4: 任务分解
+  # ----------------------------------------------
+  - id: tasks
+    generates: tasks.md
+    description: 实现任务清单
+    template: tasks.md
+    instruction: |
+      ## Skill 调用
+      触发词: @executing-plans 或 /executing-plans
+
+      创建任务分解清单。
+
+      任务粒度要求：
+      - 每个任务 2-5 分钟可完成
+      - 每个任务有明确的验证步骤
+      - 任务按批次（Batch）组织
+      - 使用 `- [ ] X.Y Task description` 格式
+
+      任务格式：
+      ```markdown
+      ## Batch 1: 基础设施
+      - [ ] 1.1 创建数据模型
+        - 验证：类型检查通过
+      - [ ] 1.2 实现 Repository
+        - 验证：单元测试通过
+      ```
+
+      完成后更新 task_plan.md：
+      - Phase: tasks
+      - Status: complete
+      - Progress: 80%
+
+      准备进入 apply 阶段。
+    requires:
+      - specs
+
+# ================================================
+# Apply 阶段配置
+# ================================================
+apply:
+  requires:
+    - tasks
+  tracks: tasks.md
+  instruction: |
+    ## 执行流程
+
+    1. 读取 tasks.md 获取任务列表
+    2. 读取 task_plan.md 获取执行状态
+    3. 按批次执行任务
+    4. 完成任务后：
+       - 更新 tasks.md 的 checkbox: `- [ ]` → `- [x]`
+       - 更新 task_plan.md 的 Progress
+       - 记录 progress.md 操作日志
+
+    ## 错误处理（3-Strike 协议）
+
+    | 尝试 | 动作 |
+    |------|------|
+    | Attempt 1 | 诊断并修复 |
+    | Attempt 2 | 尝试替代方案 |
+    | Attempt 3 | 重新思考问题 |
+    | 3次失败 | 升级给用户 |
+
+    在 task_plan.md 的错误日志中记录每次尝试：
+
+    ```markdown
+    | 错误 | 尝试 | 解决方案 |
+    |------|------|----------|
+    | TypeError: ... | 1 | 添加 null check |
+    | TypeError: ... | 2 | 使用可选链 |
+    | TypeError: ... | 3 | 重构数据流 |
+    ```
+
+    ## 完成标准
+
+    - 所有 tasks.md 的 checkbox 已勾选
+    - task_plan.md Progress: 100%
+    - 所有验证步骤通过