calc-mcp-server 0.1.0

package/.claude/skills/openspec-bulk-archive-change/SKILL.md

@@ -0,0 +1,246 @@
+---
+name: openspec-bulk-archive-change
+description: Archive multiple completed changes at once. Use when archiving several parallel changes.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Archive multiple completed changes in a single operation.
+
+This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
+
+**Input**: None required (prompts for selection)
+
+**Steps**
+
+1. **Get active changes**
+
+   Run `openspec list --json` to get all active changes.
+
+   If no active changes exist, inform user and stop.
+
+2. **Prompt for change selection**
+
+   Use **AskUserQuestion tool** with multi-select to let user choose changes:
+   - Show each change with its schema
+   - Include an option for "All changes"
+   - Allow any number of selections (1+ works, 2+ is the typical use case)
+
+   **IMPORTANT**: Do NOT auto-select. Always let the user choose.
+
+3. **Batch validation - gather status for all selected changes**
+
+   For each selected change, collect:
+
+   a. **Artifact status** - Run `openspec status --change "<name>" --json`
+      - Parse `schemaName` and `artifacts` list
+      - Note which artifacts are `done` vs other states
+
+   b. **Task completion** - Read `openspec/changes/<name>/tasks.md`
+      - Count `- [ ]` (incomplete) vs `- [x]` (complete)
+      - If no tasks file exists, note as "No tasks"
+
+   c. **Delta specs** - Check `openspec/changes/<name>/specs/` directory
+      - List which capability specs exist
+      - For each, extract requirement names (lines matching `### Requirement: <name>`)
+
+4. **Detect spec conflicts**
+
+   Build a map of `capability -> [changes that touch it]`:
+
+   ```
+   auth -> [change-a, change-b]  <- CONFLICT (2+ changes)
+   api  -> [change-c]            <- OK (only 1 change)
+   ```
+
+   A conflict exists when 2+ selected changes have delta specs for the same capability.
+
+5. **Resolve conflicts agentically**
+
+   **For each conflict**, investigate the codebase:
+
+   a. **Read the delta specs** from each conflicting change to understand what each claims to add/modify
+
+   b. **Search the codebase** for implementation evidence:
+      - Look for code implementing requirements from each delta spec
+      - Check for related files, functions, or tests
+
+   c. **Determine resolution**:
+      - If only one change is actually implemented -> sync that one's specs
+      - If both implemented -> apply in chronological order (older first, newer overwrites)
+      - If neither implemented -> skip spec sync, warn user
+
+   d. **Record resolution** for each conflict:
+      - Which change's specs to apply
+      - In what order (if both)
+      - Rationale (what was found in codebase)
+
+6. **Show consolidated status table**
+
+   Display a table summarizing all changes:
+
+   ```
+   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |
+   |---------------------|-----------|-------|---------|-----------|--------|
+   | schema-management   | Done      | 5/5   | 2 delta | None      | Ready  |
+   | project-config      | Done      | 3/3   | 1 delta | None      | Ready  |
+   | add-oauth           | Done      | 4/4   | 1 delta | auth (!)  | Ready* |
+   | add-verify-skill    | 1 left    | 2/5   | None    | None      | Warn   |
+   ```
+
+   For conflicts, show the resolution:
+   ```
+   * Conflict resolution:
+     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)
+   ```
+
+   For incomplete changes, show warnings:
+   ```
+   Warnings:
+   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks
+   ```
+
+7. **Confirm batch operation**
+
+   Use **AskUserQuestion tool** with a single confirmation:
+
+   - "Archive N changes?" with options based on status
+   - Options might include:
+     - "Archive all N changes"
+     - "Archive only N ready changes (skip incomplete)"
+     - "Cancel"
+
+   If there are incomplete changes, make clear they'll be archived with warnings.
+
+8. **Execute archive for each confirmed change**
+
+   Process changes in the determined order (respecting conflict resolution):
+
+   a. **Sync specs** if delta specs exist:
+      - Use the openspec-sync-specs approach (agent-driven intelligent merge)
+      - For conflicts, apply in resolved order
+      - Track if sync was done
+
+   b. **Perform the archive**:
+      ```bash
+      mkdir -p openspec/changes/archive
+      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      ```
+
+   c. **Track outcome** for each change:
+      - Success: archived successfully
+      - Failed: error during archive (record error)
+      - Skipped: user chose not to archive (if applicable)
+
+9. **Display summary**
+
+   Show final results:
+
+   ```
+   ## Bulk Archive Complete
+
+   Archived 3 changes:
+   - schema-management-cli -> archive/2026-01-19-schema-management-cli/
+   - project-config -> archive/2026-01-19-project-config/
+   - add-oauth -> archive/2026-01-19-add-oauth/
+
+   Skipped 1 change:
+   - add-verify-skill (user chose not to archive incomplete)
+
+   Spec sync summary:
+   - 4 delta specs synced to main specs
+   - 1 conflict resolved (auth: applied both in chronological order)
+   ```
+
+   If any failures:
+   ```
+   Failed 1 change:
+   - some-change: Archive directory already exists
+   ```
+
+**Conflict Resolution Examples**
+
+Example 1: Only one implemented
+```
+Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]
+
+Checking add-oauth:
+- Delta adds "OAuth Provider Integration" requirement
+- Searching codebase... found src/auth/oauth.ts implementing OAuth flow
+
+Checking add-jwt:
+- Delta adds "JWT Token Handling" requirement
+- Searching codebase... no JWT implementation found
+
+Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
+```
+
+Example 2: Both implemented
+```
+Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]
+
+Checking add-rest-api (created 2026-01-10):
+- Delta adds "REST Endpoints" requirement
+- Searching codebase... found src/api/rest.ts
+
+Checking add-graphql (created 2026-01-15):
+- Delta adds "GraphQL Schema" requirement
+- Searching codebase... found src/api/graphql.ts
+
+Resolution: Both implemented. Will apply add-rest-api specs first,
+then add-graphql specs (chronological order, newer takes precedence).
+```
+
+**Output On Success**
+
+```
+## Bulk Archive Complete
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+- <change-2> -> archive/YYYY-MM-DD-<change-2>/
+
+Spec sync summary:
+- N delta specs synced to main specs
+- No conflicts (or: M conflicts resolved)
+```
+
+**Output On Partial Success**
+
+```
+## Bulk Archive Complete (partial)
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+
+Skipped M changes:
+- <change-2> (user chose not to archive incomplete)
+
+Failed K changes:
+- <change-3>: Archive directory already exists
+```
+
+**Output When No Changes**
+
+```
+## No Changes to Archive
+
+No active changes found. Use `/opsx:new` to create a new change.
+```
+
+**Guardrails**
+- Allow any number of changes (1+ is fine, 2+ is the typical use case)
+- Always prompt for selection, never auto-select
+- Detect spec conflicts early and resolve by checking codebase
+- When both changes are implemented, apply specs in chronological order
+- Skip spec sync only when implementation is missing (warn user)
+- Show clear per-change status before confirming
+- Use single confirmation for entire batch
+- Track and report all outcomes (success/skip/fail)
+- Preserve .openspec.yaml when moving to archive
+- Archive directory target uses current date: YYYY-MM-DD-<name>
+- If archive target exists, fail that change but continue with others

package/.claude/skills/openspec-continue-change/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: openspec-continue-change
+description: 通过创建下一个产物继续处理 OpenSpec 变更。当用户想要推进他们的变更、创建下一个产物或继续他们的工作流时使用。
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+通过创建下一个产物继续处理变更。
+
+**输入**：可选择指定变更名称。如果省略，检查是否可以从对话上下文中推断。如果模糊或不明确，必须提示可用的变更。
+
+**步骤**
+
+1. **如果没有提供变更名称，提示选择**
+
+   运行 `openspec list --json` 以获取按最近修改排序的可用变更。然后使用 **AskUserQuestion 工具** 让用户选择要处理哪个变更。
+
+   提供前 3-4 个最近修改的变更作为选项，显示：
+   - 变更名称
+   - Schema（如果有 `schema` 字段，否则为 "spec-driven"）
+   - 状态（例如，"0/5 tasks", "complete", "no tasks"）
+   - 最近修改时间（来自 `lastModified` 字段）
+
+   将最近修改的变更标记为 "(Recommended)"，因为这很可能是用户想要继续的。
+
+   **重要**：不要猜测或自动选择变更。始终让用户选择。
+
+2. **检查当前状态**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   解析 JSON 以了解当前状态。响应包括：
+   - `schemaName`：正在使用的工作流 Schema（例如，"spec-driven"）
+   - `artifacts`：产物数组及其状态（"done", "ready", "blocked"）
+   - `isComplete`：指示是否所有产物都已完成的布尔值
+
+3. **根据状态行动**：
+
+   ---
+
+   **如果所有产物都已完成 (`isComplete: true`)**：
+   - 祝贺用户
+   - 显示最终状态，包括使用的 Schema
+   - 建议："所有产物已创建！你现在可以实施此变更或将其归档。"
+   - 停止
+
+   ---
+
+   **如果有产物准备创建**（状态显示有 `status: "ready"` 的产物）：
+   - 从状态输出中选择第一个 `status: "ready"` 的产物
+   - 获取其指令：
+     ```bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     ```
+   - 解析 JSON。关键字段是：
+     - `context`：项目背景（给你的约束 - 不要包含在输出中）
+     - `rules`：产物特定规则（给你的约束 - 不要包含在输出中）
+     - `template`：用于输出文件的结构
+     - `instruction`：Schema 特定的指导
+     - `outputPath`：写入产物的位置
+     - `dependencies`：已完成的产物，用于阅读上下文
+   - **创建产物文件**：
+     - 阅读任何已完成的依赖文件以获取上下文
+     - 使用 `template` 作为结构 - 填充其部分
+     - 应用 `context` 和 `rules` 作为约束 - 但不要将它们复制到文件中
+     - 写入指令中指定的输出路径
+   - 显示已创建的内容以及现在解锁的内容
+   - 在创建一个产物后停止
+
+   ---
+
+   **如果没有产物准备好（全部阻塞）**：
+   - 这在有效 Schema 中不应发生
+   - 显示状态并建议检查问题
+
+4. **创建产物后，显示进度**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**输出**
+
+每次调用后，显示：
+- 创建了哪个产物
+- 正在使用的 Schema 工作流
+- 当前进度（N/M 完成）
+- 现在解锁了哪些产物
+- 提示："想要继续吗？只需让我继续或告诉我下一步做什么。"
+
+**产物创建指南**
+
+产物类型及其用途取决于 Schema。使用指令输出中的 `instruction` 字段来了解要创建什么。
+
+常见产物模式：
+
+**spec-driven schema** (proposal → specs → design → tasks):
+- **proposal.md**：如果不清楚，询问用户关于变更的信息。填写 Why, What Changes, Capabilities, Impact。
+  - Capabilities 部分至关重要 - 列出的每个 capability 都需要一个 spec 文件。
+- **specs/<capability>/spec.md**：为 proposal 的 Capabilities 部分中列出的每个 capability 创建一个 spec（使用 capability 名称，而不是变更名称）。
+- **design.md**：记录技术决策、架构和实施方法。
+- **tasks.md**：将实施分解为带复选框的任务。
+
+对于其他 Schema，遵循 CLI 输出中的 `instruction` 字段。
+
+**护栏**
+- 每次调用创建一个产物
+- 在创建新产物之前，始终阅读依赖产物
+- 绝不跳过产物或乱序创建
+- 如果上下文不清楚，在创建之前询问用户
+- 在标记进度之前，验证写入后产物文件是否存在
+- 使用 Schema 的产物序列，不要假设特定的产物名称
+- **重要**：`context` 和 `rules` 是给你的约束，不是文件内容
+  - 不要将 `<context>`, `<rules>`, `<project_context>` 块复制到产物中
+  - 这些指导你写什么，但绝不应出现在输出中

package/.claude/skills/openspec-explore/SKILL.md

@@ -0,0 +1,289 @@
+---
+name: openspec-explore
+description: 进入探索模式——一个用于探索想法、调查问题和澄清需求的思考伙伴。当用户想要在变更之前或期间思考某些事情时使用。
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+进入探索模式。深度思考。自由可视化。跟随对话的发展。
+
+**重要：探索模式用于思考，而非实施。** 你可以阅读文件、搜索代码和调查代码库，但你绝不能编写代码或实施功能。如果用户要求你实施某事，请提醒他们先退出探索模式（例如，使用 `/opsx:new` 或 `/opsx:ff` 开始一个变更）。如果用户要求，你可以创建 OpenSpec 产物（提案、设计、规范）——这是捕捉思考，而不是实施。
+
+**这是一种姿态，而不是工作流。** 没有固定的步骤，没有要求的顺序，没有强制的输出。你是帮助用户探索的思考伙伴。
+
+---
+
+## 姿态
+
+- **好奇而非指令性** - 提出自然涌现的问题，不要照本宣科
+- **开放话题而非审问** - 展示多个有趣的方向，让用户跟随共鸣之处。不要强迫他们通过单一的问题路径。
+- **可视化** - 当有助于通过 ASCII 图表澄清思路时，请大量使用
+- **适应性** - 跟随有趣的线索，当新信息出现时进行调整
+- **耐心** - 不要急于下结论，让问题的形状自然显现
+- **脚踏实地** - 在相关时探索实际的代码库，不仅仅是理论化
+
+---
+
+## 你可能做的事情
+
+根据用户提出的内容，你可能会：
+
+**探索问题空间**
+- 提出从他们所说内容中涌现的澄清性问题
+- 挑战假设
+- 重新构建问题
+- 寻找类比
+
+**调查代码库**
+- 绘制与讨论相关的现有架构图
+- 寻找集成点
+- 识别已在使用的模式
+- 揭示隐藏的复杂性
+
+**比较选项**
+- 头脑风暴多种方法
+- 建立比较表
+- 勾勒权衡
+- 推荐路径（如果被问及）
+
+**可视化**
+```
+┌─────────────────────────────────────────┐
+│           大量使用 ASCII 图表           │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ 状态   │────────▶│ 状态   │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   系统图、状态机、数据流、架构草图、    │
+│   依赖图、比较表                        │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**揭示风险和未知数**
+- 识别可能出错的地方
+- 发现理解上的差距
+- 建议探针（spikes）或调查
+
+---
+
+## OpenSpec 意识
+
+你拥有 OpenSpec 系统的完整上下文。自然地使用它，不要强迫。
+
+### 检查上下文
+
+开始时，快速检查已存在的内容：
+```bash
+openspec list --json
+```
+
+这会告诉你：
+- 是否有活跃的变更
+- 它们的名称、Schema 和状态
+- 用户可能正在处理的内容
+
+### 当没有变更存在时
+
+自由思考。当见解具体化时，你可以提供：
+
+- "这感觉足够扎实，可以开始一个变更了。要我创建一个吗？"
+  → 可以过渡到 `/opsx:new` 或 `/opsx:ff`
+- 或者继续探索 - 没有正式化的压力
+
+### 当变更存在时
+
+如果用户提到变更或你检测到相关变更：
+
+1. **阅读现有产物以获取上下文**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - 等等。
+
+2. **在对话中自然地引用它们**
+   - "你的设计提到使用 Redis，但我们刚意识到 SQLite 更合适..."
+   - "提案将此范围限定为高级用户，但我们现在考虑面向所有人..."
+
+3. **当做出决定时提议捕捉**
+
+   | 见解类型 | 捕捉位置 |
+   |----------|----------|
+   | 发现新需求 | `specs/<capability>/spec.md` |
+   | 需求变更 | `specs/<capability>/spec.md` |
+   | 做出设计决定 | `design.md` |
+   | 范围变更 | `proposal.md` |
+   | 识别新工作 | `tasks.md` |
+   | 假设失效 | 相关产物 |
+
+   示例提议：
+   - "这是一个设计决定。要把它记录在 design.md 中吗？"
+   - "这是一个新需求。要把它添加到规范中吗？"
+   - "这改变了范围。要更新提案吗？"
+
+4. **用户决定** - 提议并继续。不要施压。不要自动捕捉。
+
+---
+
+## 你不必做的事情
+
+- 遵循脚本
+- 每次都问同样的问题
+- 产生特定的产物
+- 得出结论
+- 如果离题有价值，不必保持在主题上
+- 简短（这是思考时间）
+
+---
+
+## 处理不同的入口点
+
+**用户带来一个模糊的想法：**
+```
+用户：我在考虑添加实时协作
+
+你：实时协作是一个很大的空间。让我想想...
+
+      协作谱系
+      ════════════════════════════════════════════
+
+      感知               协调                 同步
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │  在场  │         │  光标  │        │  CRDT  │
+      │ "3人   │         │  多选  │        │无冲突  │
+      │ 在线"  │         │        │        │        │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+         琐碎                中等                复杂
+
+      你的想法在哪里？
+```
+
+**用户带来一个具体的问题：**
+```
+用户：认证系统一团糟
+
+你：[阅读代码库]
+
+     ┌─────────────────────────────────────────────┐
+     │              当前认证流程                   │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  会话     │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   权限    │
+                  └───────────┘
+
+     我看到三个纠结之处。哪个最紧迫？
+```
+
+**用户在实施中途卡住：**
+```
+用户：/opsx:explore add-auth-system
+      OAuth 集成比预期的要复杂
+
+你：[阅读变更产物]
+
+     你在任务 4："实施 OAuth 流程"
+
+     让我追踪一下涉及的内容...
+
+     [绘制图表，探索选项，建议路径]
+
+     想要更新设计以反映这一点吗？
+     或者添加一个探针任务来调查？
+```
+
+**用户想要比较选项：**
+```
+用户：我们应该用 Postgres 还是 SQLite？
+
+你：通用的答案很无聊。上下文是什么？
+
+用户：一个跟踪本地开发环境的 CLI 工具
+
+你：那改变了一切。
+
+     ┌─────────────────────────────────────────────────┐
+     │             CLI 工具数据存储                    │
+     └─────────────────────────────────────────────────┘
+
+     关键约束：
+     • 无后台运行
+     • 必须离线工作
+     • 单用户
+
+                  SQLite          Postgres
+     部署         嵌入式 ✓        需要服务器 ✗
+     离线         是 ✓            否 ✗
+     单文件       是 ✓            否 ✗
+
+     SQLite。毫无疑问。
+
+     除非... 有同步组件吗？
+```
+
+---
+
+## 结束发现
+
+没有强制的结束。发现可能会：
+
+- **流入行动**："准备好开始了吗？ /opsx:new 或 /opsx:ff"
+- **导致产物更新**："已用这些决定更新 design.md"
+- **仅提供清晰度**：用户得到了他们需要的，继续前进
+- **稍后继续**："我们可以随时继续"
+
+当感觉事情具体化时，你可以总结：
+
+```
+## 我们弄清楚了什么
+
+**问题**：[具体化的理解]
+
+**方法**：[如果出现了一个]
+
+**未决问题**：[如果还有]
+
+**下一步**（如果准备好了）：
+- 创建变更：/opsx:new <name>
+- 快进到任务：/opsx:ff <name>
+- 继续探索：继续交谈
+```
+
+但这个总结是可选的。有时思考本身就是价值。
+
+---
+
+## 护栏
+
+- **不要实施** - 绝不编写代码或实施功能。创建 OpenSpec 产物是可以的，编写应用程序代码是不行的。
+- **不要假装理解** - 如果某事不清楚，深入挖掘
+- **不要匆忙** - 发现是思考时间，不是任务时间
+- **不要强迫结构** - 让模式自然显现
+- **不要自动捕捉** - 提议保存见解，不要直接做
+- **做可视化** - 一张好图胜过千言万语
+- **做探索代码库** - 将讨论建立在现实基础上
+- **做质疑假设** - 包括用户的和你自己的