fix
All checks were successful
Docker Build & Deploy / Build Docker Image (push) Successful in 4m27s
Docker Build & Deploy / Deploy to Production (push) Successful in 7s
Docker Build & Deploy / Cleanup Dangling Images (push) Successful in 1s
Docker Build & Deploy / WeChat Notification (push) Successful in 1s
All checks were successful
Docker Build & Deploy / Build Docker Image (push) Successful in 4m27s
Docker Build & Deploy / Deploy to Production (push) Successful in 7s
Docker Build & Deploy / Cleanup Dangling Images (push) Successful in 1s
Docker Build & Deploy / WeChat Notification (push) Successful in 1s
This commit is contained in:
SunCheng
202
.opencode/skills/bug-fix/SKILL.cn.md
Normal file
202
.opencode/skills/bug-fix/SKILL.cn.md
Normal file
@@ -0,0 +1,202 @@
|
||||
---
|
||||
name: bug-fix
|
||||
description: Bug诊断与修复技能 - 强调交互式确认和影响分析
|
||||
metadata:
|
||||
tags:
|
||||
- bug-fix
|
||||
- debugging
|
||||
- troubleshooting
|
||||
- interactive
|
||||
version: 1.0.1
|
||||
---
|
||||
|
||||
# Bug修复技能
|
||||
|
||||
## 技能概述
|
||||
|
||||
专门用于诊断和修复项目中的bug,强调谨慎的分析流程和充分的交互式确认,确保修复的准确性和完整性,避免引入新的问题或破坏现有功能。
|
||||
|
||||
## ⚠️ 强制交互规则(MUST FOLLOW)
|
||||
|
||||
**遇到需要用户确认的情况时,必须立即调用 `question` 工具:**
|
||||
|
||||
❌ **禁止**:"我需要向用户确认..."、"请用户回答..."、"在Plan模式下建议先询问..."
|
||||
✅ **必须**:直接调用工具,不要描述或延迟
|
||||
|
||||
**调用格式**:
|
||||
```javascript
|
||||
question({
|
||||
header: "问题确认",
|
||||
questions: [{
|
||||
question: "具体触发场景是什么?",
|
||||
options: ["新增时", "修改时", "批量导入时", "定时任务时", "其他"]
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
**规则**:
|
||||
- 每次最多 **3个问题**
|
||||
- 每个问题 **3-6个选项**(穷举常见情况 + "其他"兜底)
|
||||
- 用户通过**上下键导航**选择
|
||||
- 适用于**所有模式**(Build/Plan)
|
||||
|
||||
## 执行原则
|
||||
|
||||
### 1. 充分理解问题(必要时交互确认)
|
||||
|
||||
**触发条件**:
|
||||
- 用户对bug的描述含糊不清
|
||||
- 问题复现步骤不完整
|
||||
- 预期行为与实际行为表述存在歧义
|
||||
- 涉及多个可能的问题根因
|
||||
|
||||
**执行策略**:
|
||||
- ✅ **立即调用 `question` 工具**(不要描述,直接执行)
|
||||
- ✅ **暂停其他操作**,不要基于假设进行修复
|
||||
- ✅ 澄清:错误现象、触发条件、预期行为、是否有日志
|
||||
|
||||
### 2. 风险评估与影响分析(必要时交互确认)
|
||||
|
||||
**触发条件**:
|
||||
- 发现潜在的边界情况用户未提及
|
||||
- 代码修改可能影响其他功能模块
|
||||
- 存在多种修复方案,各有利弊
|
||||
- 发现可能的性能、安全或兼容性隐患
|
||||
|
||||
**执行策略**:
|
||||
- ✅ 代码分析后,**不要直接修改代码**
|
||||
- ✅ 报告潜在问题:影响范围、边界情况、测试场景、数据迁移需求
|
||||
- ✅ **使用 `question` 工具**让用户选择方案或确认风险
|
||||
|
||||
### 3. 关联代码检查(必要时交互确认)
|
||||
|
||||
**触发条件**:
|
||||
- 发现多个位置存在相似的代码逻辑
|
||||
- 修复需要同步更新多个文件
|
||||
- 存在可能依赖该bug行为的代码(反模式)
|
||||
- 发现测试用例可能基于错误行为编写
|
||||
|
||||
**执行策略**:
|
||||
- ✅ 使用代码搜索工具查找相似逻辑和调用链
|
||||
- ✅ 报告关联代码:是否需要同步修复、依赖关系、测试更新
|
||||
- ✅ **使用 `question` 工具**让用户确认修复范围
|
||||
|
||||
## 修复流程
|
||||
|
||||
### 阶段1: 问题诊断
|
||||
1. 阅读用户的bug描述
|
||||
2. 定位相关代码文件(使用 semantic_search, grep_search)
|
||||
3. 分析代码逻辑和调用链
|
||||
4. **触发点1**: 如有不明确之处 → **立即调用 `question` 工具**(不要描述计划)
|
||||
|
||||
### 阶段2: 根因分析
|
||||
1. 确定bug的根本原因
|
||||
2. 识别影响范围和边界情况
|
||||
3. **触发点2**: 发现用户未考虑的问题 → **立即调用 `question` 工具**
|
||||
|
||||
### 阶段3: 方案设计
|
||||
1. 设计修复方案
|
||||
2. 评估方案的影响和风险
|
||||
3. 查找相似代码和依赖关系
|
||||
4. **触发点3**: 可能影响其他逻辑 → **立即调用 `question` 工具**
|
||||
|
||||
### 阶段4: 实施修复
|
||||
1. 获得用户最终确认后执行代码修改
|
||||
2. 使用 `multi_replace_string_in_file` 批量修改
|
||||
3. 确保修改的原子性和一致性
|
||||
|
||||
### 阶段5: 验证建议
|
||||
提示用户执行:单元测试(`dotnet test`)、手动测试场景、回归测试
|
||||
|
||||
## 反模式与成功标准
|
||||
|
||||
❌ **不要**在未明确理解问题的情况下猜测修复
|
||||
❌ **不要**在未评估影响范围的情况下直接修改代码
|
||||
❌ **不要**假设用户已考虑所有边界情况
|
||||
❌ **不要**在发现关联逻辑时仅修复单个位置
|
||||
❌ **不要**跳过风险通知直接实施有争议的修复方案
|
||||
❌ **不要**修改代码后不提供验证建议
|
||||
❌ **不要**描述"我会询问用户..."而不调用 `question` 工具
|
||||
❌ **不要**列出问题清单让用户自行回答
|
||||
❌ **不要**在Plan模式下说"如果用户确认..."而不执行工具调用
|
||||
|
||||
## 成功标准
|
||||
|
||||
✅ 用户明确确认问题理解无误(通过 `question` 工具获取)
|
||||
✅ 所有潜在风险和影响已向用户说明(通过 `question` 工具确认)
|
||||
✅ 修复方案获得用户明确同意(通过 `question` 工具选择)
|
||||
✅ 相似逻辑和关联代码已同步处理(如适用)
|
||||
✅ 提供了完整的验证和测试建议
|
||||
|
||||
## 示例工作流
|
||||
|
||||
```
|
||||
用户: "策略计算结果不对,加价逻辑有问题"
|
||||
|
||||
Agent:
|
||||
[阶段1 - 问题诊断]
|
||||
我需要确认几个细节:
|
||||
1. 具体是哪种类型的策略计算不对?(机票、动态加价、固定加价?)
|
||||
2. 能否提供一个具体的测试用例输入和错误输出?
|
||||
3. 预期的正确输出是什么?
|
||||
|
||||
用户: "动态加价,百分比计算错误,应该是基准价×10%,但实际是×100%"
|
||||
|
||||
Agent:
|
||||
[阶段2 - 根因分析]
|
||||
已定位到问题:
|
||||
- 位置: src/Domain.Service/Services/AgentService.cs:234
|
||||
- 原因: 百分比未除以100
|
||||
|
||||
[阶段3 - 方案设计]
|
||||
⚠️ 发现以下需要确认的点:
|
||||
|
||||
1. **关联代码**: 在 PolicyService.cs 中发现相似的百分比计算(3处),
|
||||
是否也存在相同问题?
|
||||
|
||||
2. **单元测试**: UnitTestPolicy.cs:67 的断言值为100%,可能基于错误行为,
|
||||
修复后需要更新测试
|
||||
|
||||
3. **前端影响**: 如果历史数据按错误逻辑存储,前端展示需要迁移脚本吗?
|
||||
|
||||
请确认是否需要一并处理这些关联问题?
|
||||
|
||||
用户: "是的,PolicyService 也需要修复,测试用例也要改,历史数据没有存储"
|
||||
|
||||
Agent:
|
||||
[阶段4 - 实施修复]
|
||||
好的,我将修复以下位置:
|
||||
1. AgentService.cs:234
|
||||
2. PolicyService.cs:156, 178, 201
|
||||
3. UnitTestPolicy.cs:67
|
||||
|
||||
[执行代码修改...]
|
||||
|
||||
[阶段5 - 验证建议]
|
||||
修复完成!建议验证:
|
||||
1. 运行单元测试: dotnet test
|
||||
2. 手动测试场景:
|
||||
- 输入基准价1000,加价10%,期望结果1100
|
||||
- 验证策略列表API返回正确百分比
|
||||
3. 回归测试: 检查其他类型策略未受影响
|
||||
```
|
||||
|
||||
## 适用场景
|
||||
|
||||
- ✅ 逻辑错误修复
|
||||
- ✅ 空指针异常修复
|
||||
- ✅ 数据计算错误
|
||||
- ✅ API行为异常
|
||||
- ✅ 性能问题修复
|
||||
- ✅ 边界条件处理
|
||||
|
||||
## 相关技能
|
||||
|
||||
- `refactor`: 重构优化(非bug修复)
|
||||
- `feature`: 新功能开发
|
||||
- `test`: 测试用例编写
|
||||
|
||||
## 核心约束(必须遵守)
|
||||
1. **禁止开放式提问** - 所有需要用户输入的场景,必须提供选项列表
|
||||
2. 每次交互最多提出5个问题,避免信息过载
|
||||
3. 选项设计要穷举常见情况,并保留"其他"兜底选项
|
||||
466
.opencode/skills/code-refactoring/SKILL.cn.md
Normal file
466
.opencode/skills/code-refactoring/SKILL.cn.md
Normal file
@@ -0,0 +1,466 @@
|
||||
---
|
||||
name: code-refactoring
|
||||
description: 代码重构技能 - 强调保持功能不变的前提下优化代码结构,充分理解需求和交互式确认
|
||||
metadata:
|
||||
tags:
|
||||
- refactoring
|
||||
- code-quality
|
||||
- clean-code
|
||||
- interactive
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# 代码重构技能
|
||||
|
||||
## 技能概述
|
||||
|
||||
专门用于在**不改变现有功能逻辑**的前提下优化代码结构,包括:
|
||||
- 抽取公共方法、组件和工具类
|
||||
- 消除重复代码(DRY原则)
|
||||
- 移除无用代码(死代码、注释代码、未使用的依赖)
|
||||
- 改善代码可读性和可维护性
|
||||
- 优化代码结构和命名规范
|
||||
|
||||
## ⚠️ 核心原则(MUST FOLLOW)
|
||||
|
||||
### 1. 功能不变保证
|
||||
**禁止在重构过程中改变功能行为!**
|
||||
- ✅ 重构前后的输入输出必须完全一致
|
||||
- ✅ 重构前后的副作用必须一致(数据库操作、文件IO、日志等)
|
||||
- ✅ 重构不应改变性能特征(除非明确以性能优化为目标)
|
||||
- ❌ 严禁"顺便"添加新功能或修复bug
|
||||
|
||||
### 2. 充分理解需求
|
||||
**禁止根据模糊的需求开始重构!**
|
||||
- ✅ 彻底理解重构的目标和范围
|
||||
- ✅ 识别需求中的模糊点和二义性
|
||||
- ✅ 使用 `question` 工具获取明确的用户意图
|
||||
- ❌ 不要基于假设进行重构
|
||||
|
||||
### 3. 先确认再动手
|
||||
**禁止未经用户确认就直接修改代码!**
|
||||
- ✅ 先列出所有修改点和影响范围
|
||||
- ✅ 使用 `question` 工具让用户确认重构方案
|
||||
- ✅ 获得明确的同意后再执行修改
|
||||
- ❌ 不要边分析边修改
|
||||
|
||||
## ⚠️ 强制交互规则(MUST FOLLOW)
|
||||
|
||||
**遇到需要用户确认的情况时,必须立即调用 `question` 工具:**
|
||||
|
||||
❌ **禁止**:"我需要向用户确认..."、"建议向用户询问..."、"在执行前应该确认..."
|
||||
✅ **必须**:直接调用 `question` 工具,不要描述或延迟
|
||||
|
||||
**调用格式**:
|
||||
```javascript
|
||||
question({
|
||||
header: "重构确认",
|
||||
questions: [{
|
||||
question: "是否要将重复的验证逻辑抽取到公共方法中?",
|
||||
options: ["是,抽取到工具类", "是,抽取到基类", "否,保持现状", "其他"]
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
**规则**:
|
||||
- 每次最多 **3个问题**
|
||||
- 每个问题 **3-6个选项**(穷举常见情况 + "其他"兜底)
|
||||
- 用户通过**上下键导航**选择
|
||||
- 适用于**所有阶段**(需求理解、方案确认、风险评估)
|
||||
|
||||
## 重构流程
|
||||
|
||||
### 阶段1: 需求理解(必须交互确认)
|
||||
|
||||
#### 1.1 理解重构目标
|
||||
**获取用户意图**:
|
||||
- 用户想重构什么?(文件、模块、类、方法)
|
||||
- 重构的原因是什么?(代码重复、难以维护、命名不清晰、结构混乱)
|
||||
- 期望达到什么效果?(提高复用性、提升可读性、简化逻辑、统一规范)
|
||||
|
||||
**触发 `question` 工具的场景**:
|
||||
- 用户只说"重构这个文件"但未说明具体问题
|
||||
- 用户提到"优化"但没有明确优化方向
|
||||
- 用户的需求包含多个可能的重构方向
|
||||
- 重构范围不明确(单个文件 vs 整个模块)
|
||||
|
||||
**示例问题**:
|
||||
```javascript
|
||||
question({
|
||||
header: "明确重构目标",
|
||||
questions: [
|
||||
{
|
||||
question: "您主要关注哪方面的重构?",
|
||||
options: [
|
||||
"抽取重复代码",
|
||||
"改善命名和结构",
|
||||
"移除无用代码",
|
||||
"提取公共组件/方法",
|
||||
"全面优化"
|
||||
]
|
||||
},
|
||||
{
|
||||
question: "重构范围是?",
|
||||
options: [
|
||||
"仅当前文件",
|
||||
"当前模块(相关的几个文件)",
|
||||
"整个项目",
|
||||
"让我分析后建议"
|
||||
]
|
||||
}
|
||||
]
|
||||
})
|
||||
```
|
||||
|
||||
#### 1.2 识别约束条件
|
||||
**必须明确的约束**:
|
||||
- 是否有不能改动的接口或API(对外暴露的)
|
||||
- 是否有特殊的性能要求
|
||||
- 是否需要保持特定的代码风格
|
||||
- 是否有测试覆盖(如有,重构后测试必须通过)
|
||||
|
||||
**触发 `question` 工具的场景**:
|
||||
- 发现公开API可能需要调整
|
||||
- 代码涉及性能敏感的操作
|
||||
- 存在多种重构方式,各有权衡
|
||||
- 不确定某些代码是否仍在使用
|
||||
|
||||
**示例问题**:
|
||||
```javascript
|
||||
question({
|
||||
header: "重构约束确认",
|
||||
questions: [
|
||||
{
|
||||
question: "发现 `ProcessData` 方法被多个外部模块调用,重构时:",
|
||||
options: [
|
||||
"保持方法签名不变,仅优化内部实现",
|
||||
"可以修改方法签名,我会同步更新调用方",
|
||||
"先告诉我影响范围,我再决定",
|
||||
"其他"
|
||||
]
|
||||
}
|
||||
]
|
||||
})
|
||||
```
|
||||
|
||||
#### 1.3 理解代码上下文
|
||||
**分析现有代码**:
|
||||
- 使用 `semantic_search` 查找相关代码
|
||||
- 使用 `grep_search` 查找重复模式
|
||||
- 使用 `list_code_usages` 分析调用关系
|
||||
- 阅读相关文件理解业务逻辑
|
||||
|
||||
**注意事项**:
|
||||
- 不要在分析阶段进行任何修改
|
||||
- 记录发现的问题点和重构机会
|
||||
- 识别可能的风险和边界情况
|
||||
|
||||
### 阶段2: 方案设计(必须交互确认)
|
||||
|
||||
#### 2.1 列出重构点
|
||||
**详细列出每个修改点**:
|
||||
- 修改的文件和位置
|
||||
- 修改的具体内容(前后对比)
|
||||
- 修改的原因和收益
|
||||
- 可能的影响范围
|
||||
|
||||
**示例格式**:
|
||||
```
|
||||
## 重构点清单
|
||||
|
||||
### 1. 抽取重复的数据验证逻辑
|
||||
**位置**: TransactionController.cs (L45-L60, L120-L135)
|
||||
**操作**: 将重复的金额验证逻辑抽取到 ValidationHelper.ValidateAmount()
|
||||
**原因**: 两处代码完全相同,违反DRY原则
|
||||
**影响**: 无,纯内部优化
|
||||
|
||||
### 2. 移除未使用的导入和变量
|
||||
**位置**: BudgetService.cs (L5, L23)
|
||||
**操作**: 删除 `using System.Text.RegularExpressions;` 和未使用的 `_tempValue` 字段
|
||||
**原因**: 死代码,增加维护负担
|
||||
**影响**: 无
|
||||
|
||||
### 3. 重命名方法提高可读性
|
||||
**位置**: DataProcessor.cs (L89)
|
||||
**操作**: `DoWork()` → `ProcessTransactionData()`
|
||||
**原因**: 原名称不够清晰,无法表达具体功能
|
||||
**影响**: 4个调用点需要同步更新
|
||||
```
|
||||
|
||||
#### 2.2 评估风险和影响
|
||||
**必须分析的风险**:
|
||||
- 是否影响公开API
|
||||
- 是否影响性能
|
||||
- 是否影响测试
|
||||
- 是否涉及数据迁移
|
||||
- 是否存在隐藏的依赖关系
|
||||
|
||||
**触发 `question` 工具的场景**:
|
||||
- 发现重构会影响多个模块
|
||||
- 存在潜在的兼容性问题
|
||||
- 有多种实现方式可选
|
||||
- 需要在代码质量和改动风险间权衡
|
||||
|
||||
**示例问题**:
|
||||
```javascript
|
||||
question({
|
||||
header: "重构方案确认",
|
||||
questions: [
|
||||
{
|
||||
question: "发现3处重复的日期格式化代码,建议:",
|
||||
options: [
|
||||
"抽取到工具类(Common项目)",
|
||||
"抽取到当前服务的私有方法",
|
||||
"保留重复(代码简单,抽取收益小)",
|
||||
"让我看看代码再决定"
|
||||
]
|
||||
},
|
||||
{
|
||||
question: "重构会影响4个controller和2个service,是否继续?",
|
||||
options: [
|
||||
"是,一次性全部重构",
|
||||
"否,先重构影响小的部分",
|
||||
"告诉我每个的影响详情",
|
||||
"其他"
|
||||
]
|
||||
}
|
||||
]
|
||||
})
|
||||
```
|
||||
|
||||
#### 2.3 提交方案供确认
|
||||
**必须向用户展示**:
|
||||
1. 完整的重构点清单(如2.1格式)
|
||||
2. 风险评估和影响分析
|
||||
3. 建议的执行顺序
|
||||
4. 预计改动的文件数量
|
||||
|
||||
**必须调用 `question` 工具获得最终确认**:
|
||||
```javascript
|
||||
question({
|
||||
header: "最终确认",
|
||||
questions: [{
|
||||
question: "我已列出所有重构点和影响分析,是否开始执行?",
|
||||
options: [
|
||||
"是,按计划执行",
|
||||
"需要调整部分重构点",
|
||||
"取消重构",
|
||||
"其他问题"
|
||||
]
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
**重要**:
|
||||
- ❌ 不要在得到明确的"是,按计划执行"之前修改任何代码
|
||||
- ❌ 不要假设用户会同意
|
||||
- ✅ 如用户选择"需要调整",返回阶段1重新理解需求
|
||||
|
||||
### 阶段3: 执行重构
|
||||
|
||||
#### 3.1 执行原则
|
||||
- **小步快跑**: 一次完成一个重构点,不要多个同时进行
|
||||
- **频繁验证**: 每完成一个点就运行测试或构建验证
|
||||
- **保持可逆**: 确保随时可以回滚
|
||||
- **记录进度**: 使用 `manage_todo_list` 跟踪进度
|
||||
|
||||
#### 3.2 执行步骤
|
||||
1. **创建TODO清单**:
|
||||
```javascript
|
||||
manage_todo_list({
|
||||
todoList: [
|
||||
{
|
||||
id: 1,
|
||||
title: "抽取重复验证逻辑到ValidationHelper",
|
||||
description: "TransactionController.cs L45-L60, L120-L135",
|
||||
status: "not-started"
|
||||
},
|
||||
{
|
||||
id: 2,
|
||||
title: "移除BudgetService.cs中的未使用导入",
|
||||
description: "删除using System.Text.RegularExpressions",
|
||||
status: "not-started"
|
||||
},
|
||||
// ... 更多任务
|
||||
]
|
||||
})
|
||||
```
|
||||
|
||||
2. **逐个执行**:
|
||||
- 标记任务为 `in-progress`
|
||||
- 使用 `multi_replace_string_in_file` 或 `replace_string_in_file` 修改代码
|
||||
- 运行测试验证: `dotnet test` 或 `pnpm test`
|
||||
- 标记任务为 `completed`
|
||||
- 继续下一个
|
||||
|
||||
3. **验证每个步骤**:
|
||||
- 后端重构后运行: `dotnet build && dotnet test`
|
||||
- 前端重构后运行: `pnpm lint && pnpm build`
|
||||
- 确保没有引入编译错误或测试失败
|
||||
|
||||
#### 3.3 异常处理
|
||||
**如果遇到预期外的问题**:
|
||||
- ✅ 立即停止后续重构
|
||||
- ✅ 报告问题详情
|
||||
- ✅ 调用 `question` 工具询问如何处理
|
||||
|
||||
```javascript
|
||||
question({
|
||||
header: "重构遇到问题",
|
||||
questions: [{
|
||||
question: "抽取方法后发现测试 `TestValidation` 失败了,如何处理?",
|
||||
options: [
|
||||
"回滚这个改动",
|
||||
"修复测试用例",
|
||||
"暂停,我来看看",
|
||||
"继续其他重构点"
|
||||
]
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
### 阶段4: 验证和总结
|
||||
|
||||
#### 4.1 全面验证
|
||||
**必须执行的验证**:
|
||||
- 所有单元测试通过
|
||||
- 项目成功构建
|
||||
- Lint检查通过
|
||||
- 关键功能手动验证(如适用)
|
||||
|
||||
**验证命令**:
|
||||
```bash
|
||||
# 后端
|
||||
dotnet clean
|
||||
dotnet build EmailBill.sln
|
||||
dotnet test WebApi.Test/WebApi.Test.csproj
|
||||
|
||||
# 前端
|
||||
cd Web
|
||||
pnpm lint
|
||||
pnpm build
|
||||
```
|
||||
|
||||
#### 4.2 总结报告
|
||||
**提供清晰的总结**:
|
||||
```
|
||||
## 重构完成总结
|
||||
|
||||
### ✅ 已完成的重构
|
||||
1. 抽取重复验证逻辑 (ValidationHelper.cs)
|
||||
- 消除了 3 处重复代码
|
||||
- 减少代码行数 45 行
|
||||
|
||||
2. 移除未使用的导入和变量
|
||||
- BudgetService.cs: 移除 2 个未使用的 using
|
||||
- TransactionController.cs: 移除 1 个未使用字段
|
||||
|
||||
3. 改善方法命名
|
||||
- DoWork → ProcessTransactionData (4 处调用点已更新)
|
||||
- Calculate → CalculateMonthlyBudget (2 处调用点已更新)
|
||||
|
||||
### 📊 重构影响
|
||||
- 修改文件数: 6
|
||||
- 新增文件数: 1 (ValidationHelper.cs)
|
||||
- 删除代码行数: 78
|
||||
- 新增代码行数: 42
|
||||
- 净减少代码: 36 行
|
||||
|
||||
### ✅ 验证结果
|
||||
- ✓ 所有测试通过 (23/23)
|
||||
- ✓ 项目构建成功
|
||||
- ✓ Lint检查通过
|
||||
- ✓ 功能验证正常
|
||||
|
||||
### 📝 建议的后续工作
|
||||
- 考虑为 ValidationHelper 添加单元测试
|
||||
- 可以进一步重构 DataProcessor 类的其他方法
|
||||
```
|
||||
|
||||
## 常见重构模式
|
||||
|
||||
### 1. 抽取公共方法
|
||||
**识别标准**: 代码块在多处重复出现(≥2次)
|
||||
**操作**:
|
||||
- 创建独立方法或工具类
|
||||
- 保持方法签名简洁明确
|
||||
- 添加必要的注释和文档
|
||||
|
||||
### 2. 抽取公共组件
|
||||
**识别标准**: UI组件或业务逻辑在多个视图/页面重复
|
||||
**操作**:
|
||||
- 创建可复用组件(Vue组件、Service类等)
|
||||
- 使用Props/参数传递可变部分
|
||||
- 确保组件职责单一
|
||||
|
||||
### 3. 移除死代码
|
||||
**识别标准**:
|
||||
- 未被调用的方法
|
||||
- 未被使用的变量、导入、依赖
|
||||
- 注释掉的代码
|
||||
**操作**:
|
||||
- 使用 `list_code_usages` 确认真正未使用
|
||||
- 谨慎删除(可能有隐式调用)
|
||||
- 使用Git历史作为备份
|
||||
|
||||
### 4. 改善命名
|
||||
**识别标准**:
|
||||
- 名称不能表达意图(如 `DoWork`, `Process`, `temp`)
|
||||
- 名称与实际功能不符
|
||||
- 违反命名规范
|
||||
**操作**:
|
||||
- 使用 `list_code_usages` 找到所有使用点
|
||||
- 使用 `multi_replace_string_in_file` 批量更新
|
||||
- 确保命名符合项目规范(见AGENTS.md)
|
||||
|
||||
### 5. 简化复杂逻辑
|
||||
**识别标准**:
|
||||
- 深层嵌套(>3层)
|
||||
- 过长方法(>50行)
|
||||
- 复杂条件判断
|
||||
**操作**:
|
||||
- 早返回模式(guard clauses)
|
||||
- 拆分子方法
|
||||
- 使用策略模式或查表法
|
||||
|
||||
## 注意事项
|
||||
|
||||
### ❌ 不要做
|
||||
- 在重构中添加新功能
|
||||
- 在重构中修复bug(除非bug是重构导致的)
|
||||
- 未经确认就大范围修改
|
||||
- 改变公开API而不考虑兼容性
|
||||
- 跳过测试验证
|
||||
|
||||
### ✅ 要做
|
||||
- 保持每次重构的范围可控
|
||||
- 频繁提交代码(每完成一个重构点提交一次)
|
||||
- 确保测试覆盖率不降低
|
||||
- 保持代码风格一致
|
||||
- 记录重构的原因和收益
|
||||
|
||||
## 项目特定规范
|
||||
|
||||
### C# 代码重构
|
||||
- 遵循 `AGENTS.md` 中的 C# 代码风格
|
||||
- 使用 file-scoped namespace
|
||||
- 公共方法使用 XML 注释
|
||||
- 业务逻辑使用中文注释
|
||||
- 工具方法考虑放入 `Common` 项目
|
||||
|
||||
### Vue/TypeScript 代码重构
|
||||
- 使用 Composition API
|
||||
- 组件放入 `src/components`
|
||||
- 遵循 ESLint 和 Prettier 规则
|
||||
- 使用 `@/` 别名避免相对路径
|
||||
- 提取的组件使用 Vant UI 风格
|
||||
|
||||
## 总结
|
||||
|
||||
代码重构是一个**谨慎的、迭代的、需要充分确认的**过程。核心要点:
|
||||
|
||||
1. **理解先于行动** - 彻底理解需求和约束
|
||||
2. **交互式确认** - 使用 `question` 工具消除歧义
|
||||
3. **计划后执行** - 列出修改点并获得确认
|
||||
4. **小步快跑** - 逐个完成重构点,频繁验证
|
||||
5. **功能不变** - 始终确保行为一致性
|
||||
156
.opencode/skills/openspec-apply-change/SKILL.cn.md
Normal file
156
.opencode/skills/openspec-apply-change/SKILL.cn.md
Normal file
@@ -0,0 +1,156 @@
|
||||
---
|
||||
name: openspec-apply-change
|
||||
description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
从 OpenSpec 变更中实施任务。
|
||||
|
||||
**输入**：可选地指定变更名称。如果省略,则检查是否可以从对话上下文推断。如果模糊或不明确,您**必须**提示用户选择可用的变更。
|
||||
|
||||
**步骤**
|
||||
|
||||
1. **选择变更**
|
||||
|
||||
如果提供了名称,则使用它。否则:
|
||||
- 如果用户提到了变更,则从对话上下文推断
|
||||
- 如果只存在一个活动变更,则自动选择
|
||||
- 如果不明确,运行 `openspec list --json` 获取可用变更并使用 **AskUserQuestion 工具**让用户选择
|
||||
|
||||
始终宣布："使用变更: <名称>" 以及如何覆盖(例如 `/opsx-apply <其他>`)。
|
||||
|
||||
2. **检查状态以了解 schema**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
解析 JSON 以了解:
|
||||
- `schemaName`: 正在使用的工作流(例如 "spec-driven")
|
||||
- 哪个 artifact 包含任务(对于 spec-driven 通常是 "tasks",其他情况请检查状态)
|
||||
|
||||
3. **获取应用说明**
|
||||
|
||||
```bash
|
||||
openspec instructions apply --change "<name>" --json
|
||||
```
|
||||
|
||||
这将返回:
|
||||
- 上下文文件路径(因 schema 而异 - 可能是 proposal/specs/design/tasks 或 spec/tests/implementation/docs)
|
||||
- 进度(总数、已完成、剩余)
|
||||
- 带状态的任务列表
|
||||
- 基于当前状态的动态指令
|
||||
|
||||
**处理状态:**
|
||||
- 如果 `state: "blocked"`(缺少 artifacts): 显示消息,建议使用 openspec-continue-change
|
||||
- 如果 `state: "all_done"`: 祝贺,建议归档
|
||||
- 否则: 继续实施
|
||||
|
||||
4. **读取上下文文件**
|
||||
|
||||
读取应用说明输出中 `contextFiles` 列出的文件。
|
||||
文件取决于使用的 schema:
|
||||
- **spec-driven**: proposal、specs、design、tasks
|
||||
- 其他 schemas: 遵循 CLI 输出中的 contextFiles
|
||||
|
||||
5. **显示当前进度**
|
||||
|
||||
显示:
|
||||
- 正在使用的 Schema
|
||||
- 进度: "已完成 N/M 个任务"
|
||||
- 剩余任务概览
|
||||
- 来自 CLI 的动态指令
|
||||
|
||||
6. **实施任务(循环直到完成或阻塞)**
|
||||
|
||||
对于每个待处理任务:
|
||||
- 显示正在处理哪个任务
|
||||
- 进行所需的代码更改
|
||||
- 保持更改最小且专注
|
||||
- 在任务文件中标记任务完成: `- [ ]` → `- [x]`
|
||||
- 继续下一个任务
|
||||
|
||||
**暂停如果:**
|
||||
- 任务不清楚 → 请求澄清
|
||||
- 实施揭示设计问题 → 建议更新 artifacts
|
||||
- 遇到错误或阻塞 → 报告并等待指导
|
||||
- 用户中断
|
||||
|
||||
7. **完成或暂停时,显示状态**
|
||||
|
||||
显示:
|
||||
- 本次会话完成的任务
|
||||
- 总体进度: "已完成 N/M 个任务"
|
||||
- 如果全部完成: 建议归档
|
||||
- 如果暂停: 解释原因并等待指导
|
||||
|
||||
**实施期间的输出**
|
||||
|
||||
```
|
||||
## 正在实施: <change-name> (schema: <schema-name>)
|
||||
|
||||
正在处理任务 3/7: <任务描述>
|
||||
[...正在实施...]
|
||||
✓ 任务完成
|
||||
|
||||
正在处理任务 4/7: <任务描述>
|
||||
[...正在实施...]
|
||||
✓ 任务完成
|
||||
```
|
||||
|
||||
**完成时的输出**
|
||||
|
||||
```
|
||||
## 实施完成
|
||||
|
||||
**变更:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**进度:** 7/7 个任务完成 ✓
|
||||
|
||||
### 本次会话已完成
|
||||
- [x] 任务 1
|
||||
- [x] 任务 2
|
||||
...
|
||||
|
||||
所有任务完成! 准备归档此变更。
|
||||
```
|
||||
|
||||
**暂停时的输出(遇到问题)**
|
||||
|
||||
```
|
||||
## 实施已暂停
|
||||
|
||||
**变更:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**进度:** 已完成 4/7 个任务
|
||||
|
||||
### 遇到的问题
|
||||
<问题描述>
|
||||
|
||||
**选项:**
|
||||
1. <选项 1>
|
||||
2. <选项 2>
|
||||
3. 其他方法
|
||||
|
||||
您想怎么做?
|
||||
```
|
||||
|
||||
**护栏**
|
||||
- 持续处理任务直到完成或阻塞
|
||||
- 开始前始终读取上下文文件(从应用说明输出中)
|
||||
- 如果任务不明确,在实施前暂停并询问
|
||||
- 如果实施揭示问题,暂停并建议更新 artifact
|
||||
- 保持代码更改最小且限定在每个任务范围内
|
||||
- 完成每个任务后立即更新任务复选框
|
||||
- 遇到错误、阻塞或不清楚的需求时暂停 - 不要猜测
|
||||
- 使用 CLI 输出中的 contextFiles,不要假设特定文件名
|
||||
|
||||
**流畅工作流集成**
|
||||
|
||||
此技能支持"对变更的操作"模型:
|
||||
|
||||
- **可以随时调用**: 在所有 artifacts 完成之前(如果存在任务)、部分实施后、与其他操作交错进行
|
||||
- **允许更新 artifact**: 如果实施揭示设计问题,建议更新 artifacts - 不是阶段锁定,灵活工作
|
||||
156
.opencode/skills/openspec-apply-change/SKILL.md
Normal file
156
.opencode/skills/openspec-apply-change/SKILL.md
Normal file
@@ -0,0 +1,156 @@
|
||||
---
|
||||
name: openspec-apply-change
|
||||
description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Implement tasks from an OpenSpec change.
|
||||
|
||||
**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Select the change**
|
||||
|
||||
If a name is provided, use it. Otherwise:
|
||||
- Infer from conversation context if the user mentioned a change
|
||||
- Auto-select if only one active change exists
|
||||
- If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
|
||||
|
||||
Always announce: "Using change: <name>" and how to override (e.g., `/opsx-apply <other>`).
|
||||
|
||||
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 artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
|
||||
|
||||
3. **Get apply instructions**
|
||||
|
||||
```bash
|
||||
openspec instructions apply --change "<name>" --json
|
||||
```
|
||||
|
||||
This returns:
|
||||
- Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
|
||||
- Progress (total, complete, remaining)
|
||||
- Task list with status
|
||||
- Dynamic instruction based on current state
|
||||
|
||||
**Handle states:**
|
||||
- If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
|
||||
- If `state: "all_done"`: congratulate, suggest archive
|
||||
- Otherwise: proceed to implementation
|
||||
|
||||
4. **Read context files**
|
||||
|
||||
Read the files listed in `contextFiles` from the apply instructions output.
|
||||
The files depend on the schema being used:
|
||||
- **spec-driven**: proposal, specs, design, tasks
|
||||
- Other schemas: follow the contextFiles from CLI output
|
||||
|
||||
5. **Show current progress**
|
||||
|
||||
Display:
|
||||
- Schema being used
|
||||
- Progress: "N/M tasks complete"
|
||||
- Remaining tasks overview
|
||||
- Dynamic instruction from CLI
|
||||
|
||||
6. **Implement tasks (loop until done or blocked)**
|
||||
|
||||
For each pending task:
|
||||
- Show which task is being worked on
|
||||
- Make the code changes required
|
||||
- Keep changes minimal and focused
|
||||
- Mark task complete in the tasks file: `- [ ]` → `- [x]`
|
||||
- Continue to next task
|
||||
|
||||
**Pause if:**
|
||||
- Task is unclear → ask for clarification
|
||||
- Implementation reveals a design issue → suggest updating artifacts
|
||||
- Error or blocker encountered → report and wait for guidance
|
||||
- User interrupts
|
||||
|
||||
7. **On completion or pause, show status**
|
||||
|
||||
Display:
|
||||
- Tasks completed this session
|
||||
- Overall progress: "N/M tasks complete"
|
||||
- If all done: suggest archive
|
||||
- If paused: explain why and wait for guidance
|
||||
|
||||
**Output During Implementation**
|
||||
|
||||
```
|
||||
## Implementing: <change-name> (schema: <schema-name>)
|
||||
|
||||
Working on task 3/7: <task description>
|
||||
[...implementation happening...]
|
||||
✓ Task complete
|
||||
|
||||
Working on task 4/7: <task description>
|
||||
[...implementation happening...]
|
||||
✓ Task complete
|
||||
```
|
||||
|
||||
**Output On Completion**
|
||||
|
||||
```
|
||||
## Implementation Complete
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Progress:** 7/7 tasks complete ✓
|
||||
|
||||
### Completed This Session
|
||||
- [x] Task 1
|
||||
- [x] Task 2
|
||||
...
|
||||
|
||||
All tasks complete! Ready to archive this change.
|
||||
```
|
||||
|
||||
**Output On Pause (Issue Encountered)**
|
||||
|
||||
```
|
||||
## Implementation Paused
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Progress:** 4/7 tasks complete
|
||||
|
||||
### Issue Encountered
|
||||
<description of the issue>
|
||||
|
||||
**Options:**
|
||||
1. <option 1>
|
||||
2. <option 2>
|
||||
3. Other approach
|
||||
|
||||
What would you like to do?
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Keep going through tasks until done or blocked
|
||||
- Always read context files before starting (from the apply instructions output)
|
||||
- If task is ambiguous, pause and ask before implementing
|
||||
- If implementation reveals issues, pause and suggest artifact updates
|
||||
- Keep code changes minimal and scoped to each task
|
||||
- Update task checkbox immediately after completing each task
|
||||
- Pause on errors, blockers, or unclear requirements - don't guess
|
||||
- Use contextFiles from CLI output, don't assume specific file names
|
||||
|
||||
**Fluid Workflow Integration**
|
||||
|
||||
This skill supports the "actions on a change" model:
|
||||
|
||||
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
|
||||
- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
|
||||
114
.opencode/skills/openspec-archive-change/SKILL.cn.md
Normal file
114
.opencode/skills/openspec-archive-change/SKILL.cn.md
Normal file
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: openspec-archive-change
|
||||
description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
在实验工作流中归档已完成的变更。
|
||||
|
||||
**输入**: 可选择指定变更名称。如果省略,检查是否可以从对话上下文中推断。如果模糊或不明确,你**必须**提示可用的变更。
|
||||
|
||||
**步骤**
|
||||
|
||||
1. **如果未提供变更名称,提示用户选择**
|
||||
|
||||
运行 `openspec list --json` 获取可用的变更。使用 **AskUserQuestion 工具**让用户选择。
|
||||
|
||||
仅显示活跃的变更 (尚未归档的)。
|
||||
如果可用,包含每个变更使用的 schema。
|
||||
|
||||
**重要**: 不要猜测或自动选择变更。始终让用户选择。
|
||||
|
||||
2. **检查 artifact 完成状态**
|
||||
|
||||
运行 `openspec status --change "<name>" --json` 检查 artifact 完成情况。
|
||||
|
||||
解析 JSON 以了解:
|
||||
- `schemaName`: 正在使用的工作流
|
||||
- `artifacts`: artifacts 列表及其状态 (`done` 或其他)
|
||||
|
||||
**如果任何 artifacts 不是 `done` 状态:**
|
||||
- 显示警告,列出未完成的 artifacts
|
||||
- 使用 **AskUserQuestion 工具**确认用户是否要继续
|
||||
- 如果用户确认则继续
|
||||
|
||||
3. **检查任务完成状态**
|
||||
|
||||
读取任务文件 (通常是 `tasks.md`) 检查未完成的任务。
|
||||
|
||||
统计标记为 `- [ ]` (未完成) vs `- [x]` (已完成) 的任务。
|
||||
|
||||
**如果发现未完成的任务:**
|
||||
- 显示警告,显示未完成任务的数量
|
||||
- 使用 **AskUserQuestion 工具**确认用户是否要继续
|
||||
- 如果用户确认则继续
|
||||
|
||||
**如果不存在任务文件:** 无任务相关警告地继续。
|
||||
|
||||
4. **评估 delta spec 同步状态**
|
||||
|
||||
检查 `openspec/changes/<name>/specs/` 中的 delta specs。如果不存在,无同步提示地继续。
|
||||
|
||||
**如果存在 delta specs:**
|
||||
- 将每个 delta spec 与其对应的主 spec `openspec/specs/<capability>/spec.md` 比较
|
||||
- 确定将应用哪些更改 (添加、修改、删除、重命名)
|
||||
- 在提示前显示综合摘要
|
||||
|
||||
**提示选项:**
|
||||
- 如果需要更改: "立即同步 (推荐)", "归档但不同步"
|
||||
- 如果已同步: "立即归档", "仍然同步", "取消"
|
||||
|
||||
如果用户选择同步,执行 /opsx-sync 逻辑 (使用 openspec-sync-specs 技能)。无论选择什么都继续归档。
|
||||
|
||||
5. **执行归档**
|
||||
|
||||
如果不存在则创建归档目录:
|
||||
```bash
|
||||
mkdir -p openspec/changes/archive
|
||||
```
|
||||
|
||||
使用当前日期生成目标名称: `YYYY-MM-DD-<change-name>`
|
||||
|
||||
**检查目标是否已存在:**
|
||||
- 如果是: 失败并显示错误,建议重命名现有归档或使用不同日期
|
||||
- 如果否: 将变更目录移动到归档
|
||||
|
||||
```bash
|
||||
mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
|
||||
```
|
||||
|
||||
6. **显示摘要**
|
||||
|
||||
显示归档完成摘要,包括:
|
||||
- 变更名称
|
||||
- 使用的 Schema
|
||||
- 归档位置
|
||||
- 是否同步了 specs (如果适用)
|
||||
- 关于任何警告的注释 (未完成的 artifacts/任务)
|
||||
|
||||
**成功时的输出**
|
||||
|
||||
```
|
||||
## 归档完成
|
||||
|
||||
**变更:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**归档到:** openspec/changes/archive/YYYY-MM-DD-<name>/
|
||||
**Specs:** ✓ 已同步到主 specs (或 "无 delta specs" 或 "跳过同步")
|
||||
|
||||
所有 artifacts 完成。所有任务完成。
|
||||
```
|
||||
|
||||
**防护机制**
|
||||
- 如果未提供变更,始终提示选择
|
||||
- 使用 artifact 图 (openspec status --json) 进行完成度检查
|
||||
- 不要因警告而阻止归档 - 只需通知并确认
|
||||
- 移动到归档时保留 .openspec.yaml (它随目录一起移动)
|
||||
- 显示清晰的发生情况摘要
|
||||
- 如果请求同步,使用 openspec-sync-specs 方法 (代理驱动)
|
||||
- 如果存在 delta specs,在提示前始终运行同步评估并显示综合摘要
|
||||
114
.opencode/skills/openspec-archive-change/SKILL.md
Normal file
114
.opencode/skills/openspec-archive-change/SKILL.md
Normal file
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: openspec-archive-change
|
||||
description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Archive a completed change in the experimental workflow.
|
||||
|
||||
**Input**: Optionally specify a change name. 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 only active changes (not already archived).
|
||||
Include the schema used for each change if available.
|
||||
|
||||
**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
|
||||
|
||||
2. **Check artifact completion status**
|
||||
|
||||
Run `openspec status --change "<name>" --json` to check artifact completion.
|
||||
|
||||
Parse the JSON to understand:
|
||||
- `schemaName`: The workflow being used
|
||||
- `artifacts`: List of artifacts with their status (`done` or other)
|
||||
|
||||
**If any artifacts are not `done`:**
|
||||
- Display warning listing incomplete artifacts
|
||||
- Use **AskUserQuestion tool** to confirm user wants to proceed
|
||||
- Proceed if user confirms
|
||||
|
||||
3. **Check task completion status**
|
||||
|
||||
Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
|
||||
|
||||
Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
|
||||
|
||||
**If incomplete tasks found:**
|
||||
- Display warning showing count of incomplete tasks
|
||||
- Use **AskUserQuestion tool** to confirm user wants to proceed
|
||||
- Proceed if user confirms
|
||||
|
||||
**If no tasks file exists:** Proceed without task-related warning.
|
||||
|
||||
4. **Assess delta spec sync state**
|
||||
|
||||
Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
|
||||
|
||||
**If delta specs exist:**
|
||||
- Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
|
||||
- Determine what changes would be applied (adds, modifications, removals, renames)
|
||||
- Show a combined summary before prompting
|
||||
|
||||
**Prompt options:**
|
||||
- If changes needed: "Sync now (recommended)", "Archive without syncing"
|
||||
- If already synced: "Archive now", "Sync anyway", "Cancel"
|
||||
|
||||
If user chooses sync, execute /opsx-sync logic (use the openspec-sync-specs skill). Proceed to archive regardless of choice.
|
||||
|
||||
5. **Perform the archive**
|
||||
|
||||
Create the archive directory if it doesn't exist:
|
||||
```bash
|
||||
mkdir -p openspec/changes/archive
|
||||
```
|
||||
|
||||
Generate target name using current date: `YYYY-MM-DD-<change-name>`
|
||||
|
||||
**Check if target already exists:**
|
||||
- If yes: Fail with error, suggest renaming existing archive or using different date
|
||||
- If no: Move the change directory to archive
|
||||
|
||||
```bash
|
||||
mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
|
||||
```
|
||||
|
||||
6. **Display summary**
|
||||
|
||||
Show archive completion summary including:
|
||||
- Change name
|
||||
- Schema that was used
|
||||
- Archive location
|
||||
- Whether specs were synced (if applicable)
|
||||
- Note about any warnings (incomplete artifacts/tasks)
|
||||
|
||||
**Output On Success**
|
||||
|
||||
```
|
||||
## Archive Complete
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
|
||||
**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
|
||||
|
||||
All artifacts complete. All tasks complete.
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Always prompt for change selection if not provided
|
||||
- Use artifact graph (openspec status --json) for completion checking
|
||||
- Don't block archive on warnings - just inform and confirm
|
||||
- Preserve .openspec.yaml when moving to archive (it moves with the directory)
|
||||
- Show clear summary of what happened
|
||||
- If sync is requested, use openspec-sync-specs approach (agent-driven)
|
||||
- If delta specs exist, always run the sync assessment and show the combined summary before prompting
|
||||
246
.opencode/skills/openspec-bulk-archive-change/SKILL.cn.md
Normal file
246
.opencode/skills/openspec-bulk-archive-change/SKILL.cn.md
Normal file
@@ -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"
|
||||
---
|
||||
|
||||
在单个操作中归档多个已完成的变更。
|
||||
|
||||
该技能允许你批量归档变更,通过检查代码库来确定实际实现的内容,智能地处理 spec 冲突。
|
||||
|
||||
**输入**: 无需输入 (会提示选择)
|
||||
|
||||
**步骤**
|
||||
|
||||
1. **获取活跃的变更**
|
||||
|
||||
运行 `openspec list --json` 获取所有活跃的变更。
|
||||
|
||||
如果不存在活跃的变更,通知用户并停止。
|
||||
|
||||
2. **提示变更选择**
|
||||
|
||||
使用 **AskUserQuestion 工具**进行多选,让用户选择变更:
|
||||
- 显示每个变更及其 schema
|
||||
- 包含"所有变更"选项
|
||||
- 允许任意数量的选择 (1+ 即可,2+ 是典型用例)
|
||||
|
||||
**重要**: 不要自动选择。始终让用户选择。
|
||||
|
||||
3. **批量验证 - 收集所有选定变更的状态**
|
||||
|
||||
对于每个选定的变更,收集:
|
||||
|
||||
a. **Artifact 状态** - 运行 `openspec status --change "<name>" --json`
|
||||
- 解析 `schemaName` 和 `artifacts` 列表
|
||||
- 注意哪些 artifacts 是 `done` 状态 vs 其他状态
|
||||
|
||||
b. **任务完成度** - 读取 `openspec/changes/<name>/tasks.md`
|
||||
- 统计 `- [ ]` (未完成) vs `- [x]` (已完成)
|
||||
- 如果不存在任务文件,注明 "无任务"
|
||||
|
||||
c. **Delta specs** - 检查 `openspec/changes/<name>/specs/` 目录
|
||||
- 列出存在哪些 capability specs
|
||||
- 对于每个,提取需求名称 (匹配 `### Requirement: <name>` 的行)
|
||||
|
||||
4. **检测 spec 冲突**
|
||||
|
||||
建立 `capability -> [涉及它的变更]` 映射:
|
||||
|
||||
```
|
||||
auth -> [change-a, change-b] <- 冲突 (2+ 个变更)
|
||||
api -> [change-c] <- 正常 (只有 1 个变更)
|
||||
```
|
||||
|
||||
当 2+ 个选定的变更对同一个 capability 有 delta specs 时,存在冲突。
|
||||
|
||||
5. **智能解决冲突**
|
||||
|
||||
**对于每个冲突**,调查代码库:
|
||||
|
||||
a. **读取 delta specs** 从每个冲突的变更中,了解每个声称添加/修改的内容
|
||||
|
||||
b. **搜索代码库**寻找实现证据:
|
||||
- 寻找实现每个 delta spec 需求的代码
|
||||
- 检查相关的文件、函数或测试
|
||||
|
||||
c. **确定解决方案**:
|
||||
- 如果只有一个变更实际实现了 -> 同步那个的 specs
|
||||
- 如果两者都实现了 -> 按时间顺序应用 (较旧的先,较新的覆盖)
|
||||
- 如果都未实现 -> 跳过 spec 同步,警告用户
|
||||
|
||||
d. **记录解决方案**对于每个冲突:
|
||||
- 应用哪个变更的 specs
|
||||
- 以什么顺序 (如果两者都有)
|
||||
- 理由 (在代码库中找到了什么)
|
||||
|
||||
6. **显示综合状态表**
|
||||
|
||||
显示总结所有变更的表格:
|
||||
|
||||
```
|
||||
| 变更 | Artifacts | 任务 | Specs | 冲突 | 状态 |
|
||||
|--------------------|-----------|-------|---------|-----------|--------|
|
||||
| schema-management | 完成 | 5/5 | 2 delta | 无 | 就绪 |
|
||||
| project-config | 完成 | 3/3 | 1 delta | 无 | 就绪 |
|
||||
| add-oauth | 完成 | 4/4 | 1 delta | auth (!) | 就绪* |
|
||||
| add-verify-skill | 剩余 1 | 2/5 | 无 | 无 | 警告 |
|
||||
```
|
||||
|
||||
对于冲突,显示解决方案:
|
||||
```
|
||||
* 冲突解决:
|
||||
- auth spec: 将应用 add-oauth 然后 add-jwt (两者都已实现,按时间顺序)
|
||||
```
|
||||
|
||||
对于未完成的变更,显示警告:
|
||||
```
|
||||
警告:
|
||||
- add-verify-skill: 1 个未完成 artifact, 3 个未完成任务
|
||||
```
|
||||
|
||||
7. **确认批量操作**
|
||||
|
||||
使用 **AskUserQuestion 工具**进行单次确认:
|
||||
|
||||
- "归档 N 个变更?" 根据状态提供选项
|
||||
- 选项可能包括:
|
||||
- "归档所有 N 个变更"
|
||||
- "仅归档 N 个就绪的变更 (跳过未完成的)"
|
||||
- "取消"
|
||||
|
||||
如果有未完成的变更,明确说明它们将带警告归档。
|
||||
|
||||
8. **为每个确认的变更执行归档**
|
||||
|
||||
按确定的顺序处理变更 (遵循冲突解决方案):
|
||||
|
||||
a. **同步 specs** 如果存在 delta specs:
|
||||
- 使用 openspec-sync-specs 方法 (代理驱动的智能合并)
|
||||
- 对于冲突,按已解决的顺序应用
|
||||
- 跟踪是否完成同步
|
||||
|
||||
b. **执行归档**:
|
||||
```bash
|
||||
mkdir -p openspec/changes/archive
|
||||
mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
|
||||
```
|
||||
|
||||
c. **跟踪结果**对于每个变更:
|
||||
- 成功: 成功归档
|
||||
- 失败: 归档期间出错 (记录错误)
|
||||
- 跳过: 用户选择不归档 (如果适用)
|
||||
|
||||
9. **显示摘要**
|
||||
|
||||
显示最终结果:
|
||||
|
||||
```
|
||||
## 批量归档完成
|
||||
|
||||
已归档 3 个变更:
|
||||
- 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/
|
||||
|
||||
跳过 1 个变更:
|
||||
- add-verify-skill (用户选择不归档未完成的)
|
||||
|
||||
Spec 同步摘要:
|
||||
- 4 个 delta specs 同步到主 specs
|
||||
- 1 个冲突已解决 (auth: 按时间顺序应用两者)
|
||||
```
|
||||
|
||||
如果有任何失败:
|
||||
```
|
||||
失败 1 个变更:
|
||||
- some-change: 归档目录已存在
|
||||
```
|
||||
|
||||
**冲突解决示例**
|
||||
|
||||
示例 1: 只有一个已实现
|
||||
```
|
||||
冲突: specs/auth/spec.md 被 [add-oauth, add-jwt] 涉及
|
||||
|
||||
检查 add-oauth:
|
||||
- Delta 添加了 "OAuth 提供者集成" 需求
|
||||
- 搜索代码库... 找到 src/auth/oauth.ts 实现 OAuth 流程
|
||||
|
||||
检查 add-jwt:
|
||||
- Delta 添加了 "JWT 令牌处理" 需求
|
||||
- 搜索代码库... 未找到 JWT 实现
|
||||
|
||||
解决: 只有 add-oauth 已实现。将仅同步 add-oauth specs。
|
||||
```
|
||||
|
||||
示例 2: 两者都已实现
|
||||
```
|
||||
冲突: specs/api/spec.md 被 [add-rest-api, add-graphql] 涉及
|
||||
|
||||
检查 add-rest-api (创建于 2026-01-10):
|
||||
- Delta 添加了 "REST 端点" 需求
|
||||
- 搜索代码库... 找到 src/api/rest.ts
|
||||
|
||||
检查 add-graphql (创建于 2026-01-15):
|
||||
- Delta 添加了 "GraphQL Schema" 需求
|
||||
- 搜索代码库... 找到 src/api/graphql.ts
|
||||
|
||||
解决: 两者都已实现。将先应用 add-rest-api specs,
|
||||
然后应用 add-graphql specs (按时间顺序,较新的优先)。
|
||||
```
|
||||
|
||||
**成功时的输出**
|
||||
|
||||
```
|
||||
## 批量归档完成
|
||||
|
||||
已归档 N 个变更:
|
||||
- <change-1> -> archive/YYYY-MM-DD-<change-1>/
|
||||
- <change-2> -> archive/YYYY-MM-DD-<change-2>/
|
||||
|
||||
Spec 同步摘要:
|
||||
- N 个 delta specs 同步到主 specs
|
||||
- 无冲突 (或: M 个冲突已解决)
|
||||
```
|
||||
|
||||
**部分成功时的输出**
|
||||
|
||||
```
|
||||
## 批量归档完成 (部分)
|
||||
|
||||
已归档 N 个变更:
|
||||
- <change-1> -> archive/YYYY-MM-DD-<change-1>/
|
||||
|
||||
跳过 M 个变更:
|
||||
- <change-2> (用户选择不归档未完成的)
|
||||
|
||||
失败 K 个变更:
|
||||
- <change-3>: 归档目录已存在
|
||||
```
|
||||
|
||||
**无变更时的输出**
|
||||
|
||||
```
|
||||
## 无变更可归档
|
||||
|
||||
未找到活跃的变更。使用 `/opsx-new` 创建新变更。
|
||||
```
|
||||
|
||||
**防护机制**
|
||||
- 允许任意数量的变更 (1+ 即可,2+ 是典型用例)
|
||||
- 始终提示选择,永不自动选择
|
||||
- 提前检测 spec 冲突并通过检查代码库解决
|
||||
- 当两个变更都已实现时,按时间顺序应用 specs
|
||||
- 仅当实现缺失时跳过 spec 同步 (警告用户)
|
||||
- 在确认前显示清晰的每个变更状态
|
||||
- 对整个批次使用单次确认
|
||||
- 跟踪并报告所有结果 (成功/跳过/失败)
|
||||
- 移动到归档时保留 .openspec.yaml
|
||||
- 归档目录目标使用当前日期: YYYY-MM-DD-<name>
|
||||
- 如果归档目标存在,使该变更失败但继续处理其他变更
|
||||
246
.opencode/skills/openspec-bulk-archive-change/SKILL.md
Normal file
246
.opencode/skills/openspec-bulk-archive-change/SKILL.md
Normal file
@@ -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
|
||||
118
.opencode/skills/openspec-continue-change/SKILL.cn.md
Normal file
118
.opencode/skills/openspec-continue-change/SKILL.cn.md
Normal file
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: openspec-continue-change
|
||||
description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
通过创建下一个 artifact 来继续处理变更。
|
||||
|
||||
**输入**：可选地指定变更名称。如果省略,则检查是否可以从对话上下文推断。如果模糊或不明确,您**必须**提示用户选择可用的变更。
|
||||
|
||||
**步骤**
|
||||
|
||||
1. **如果未提供变更名称,提示选择**
|
||||
|
||||
运行 `openspec list --json` 获取按最近修改时间排序的可用变更。然后使用 **AskUserQuestion 工具**让用户选择要处理的变更。
|
||||
|
||||
将最近修改的前 3-4 个变更作为选项呈现,显示:
|
||||
- 变更名称
|
||||
- Schema(如果存在 `schema` 字段则显示,否则为 "spec-driven")
|
||||
- 状态(例如 "0/5 个任务"、"完成"、"无任务")
|
||||
- 最近修改时间(来自 `lastModified` 字段)
|
||||
|
||||
将最近修改的变更标记为 "(推荐)",因为这可能是用户想要继续的内容。
|
||||
|
||||
**重要**: 不要猜测或自动选择变更。始终让用户选择。
|
||||
|
||||
2. **检查当前状态**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
解析 JSON 以了解当前状态。响应包括:
|
||||
- `schemaName`: 正在使用的工作流 schema(例如 "spec-driven")
|
||||
- `artifacts`: 包含状态的 artifacts 数组("done"、"ready"、"blocked")
|
||||
- `isComplete`: 指示所有 artifacts 是否完成的布尔值
|
||||
|
||||
3. **根据状态采取行动**:
|
||||
|
||||
---
|
||||
|
||||
**如果所有 artifacts 都已完成(`isComplete: true`)**:
|
||||
- 祝贺用户
|
||||
- 显示最终状态,包括使用的 schema
|
||||
- 建议: "所有 artifacts 已创建! 现在可以实施此变更或归档它。"
|
||||
- 停止
|
||||
|
||||
---
|
||||
|
||||
**如果 artifacts 准备创建**(状态显示 `status: "ready"` 的 artifacts):
|
||||
- 从状态输出中选择**第一个** `status: "ready"` 的 artifact
|
||||
- 获取其说明:
|
||||
```bash
|
||||
openspec instructions <artifact-id> --change "<name>" --json
|
||||
```
|
||||
- 解析 JSON。关键字段是:
|
||||
- `context`: 项目背景(对您的约束 - 不要包含在输出中)
|
||||
- `rules`: Artifact 特定规则(对您的约束 - 不要包含在输出中)
|
||||
- `template`: 用于输出文件的结构
|
||||
- `instruction`: Schema 特定指导
|
||||
- `outputPath`: artifact 的写入位置
|
||||
- `dependencies`: 已完成的 artifacts,读取以获取上下文
|
||||
- **创建 artifact 文件**:
|
||||
- 读取任何已完成的依赖文件以获取上下文
|
||||
- 使用 `template` 作为结构 - 填充其各个部分
|
||||
- 在写入时应用 `context` 和 `rules` 作为约束 - 但不要将它们复制到文件中
|
||||
- 写入说明中指定的输出路径
|
||||
- 显示创建的内容以及现在解锁的内容
|
||||
- 创建一个 artifact 后停止
|
||||
|
||||
---
|
||||
|
||||
**如果没有 artifacts 准备好(全部被阻塞)**:
|
||||
- 使用有效的 schema 不应该发生这种情况
|
||||
- 显示状态并建议检查问题
|
||||
|
||||
4. **创建 artifact 后,显示进度**
|
||||
```bash
|
||||
openspec status --change "<name>"
|
||||
```
|
||||
|
||||
**输出**
|
||||
|
||||
每次调用后,显示:
|
||||
- 创建了哪个 artifact
|
||||
- 正在使用的 Schema 工作流
|
||||
- 当前进度(已完成 N/M)
|
||||
- 现在解锁了哪些 artifacts
|
||||
- 提示: "想要继续吗? 只需让我继续或告诉我下一步该做什么。"
|
||||
|
||||
**Artifact 创建指南**
|
||||
|
||||
artifact 类型及其用途取决于 schema。使用说明输出中的 `instruction` 字段来了解要创建什么。
|
||||
|
||||
常见 artifact 模式:
|
||||
|
||||
**spec-driven schema**(proposal → specs → design → tasks):
|
||||
- **proposal.md**: 如果不清楚,询问用户关于变更的信息。填写为什么、什么变更、能力、影响。
|
||||
- Capabilities 部分至关重要 - 列出的每个能力都需要一个 spec 文件。
|
||||
- **specs/<capability>/spec.md**: 为 proposal 的 Capabilities 部分列出的每个能力创建一个 spec(使用能力名称,而不是变更名称)。
|
||||
- **design.md**: 记录技术决策、架构和实施方法。
|
||||
- **tasks.md**: 将实施分解为带复选框的任务。
|
||||
|
||||
对于其他 schemas,遵循 CLI 输出中的 `instruction` 字段。
|
||||
|
||||
**护栏**
|
||||
- 每次调用创建一个 artifact
|
||||
- 在创建新 artifact 之前始终读取依赖 artifacts
|
||||
- 永远不要跳过 artifacts 或无序创建
|
||||
- 如果上下文不清楚,在创建前询问用户
|
||||
- 写入后验证 artifact 文件存在,然后再标记进度
|
||||
- 使用 schema 的 artifact 序列,不要假设特定的 artifact 名称
|
||||
- **重要**: `context` 和 `rules` 是对您的约束,不是文件内容
|
||||
- 不要将 `<context>`、`<rules>`、`<project_context>` 块复制到 artifact 中
|
||||
- 这些指导您写什么,但永远不应出现在输出中
|
||||
118
.opencode/skills/openspec-continue-change/SKILL.md
Normal file
118
.opencode/skills/openspec-continue-change/SKILL.md
Normal file
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: openspec-continue-change
|
||||
description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Continue working on a change by creating the next artifact.
|
||||
|
||||
**Input**: Optionally specify a change name. 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 sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
|
||||
|
||||
Present the top 3-4 most recently modified changes as options, showing:
|
||||
- Change name
|
||||
- Schema (from `schema` field if present, otherwise "spec-driven")
|
||||
- Status (e.g., "0/5 tasks", "complete", "no tasks")
|
||||
- How recently it was modified (from `lastModified` field)
|
||||
|
||||
Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.
|
||||
|
||||
**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
|
||||
|
||||
2. **Check current status**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
Parse the JSON to understand current state. The response includes:
|
||||
- `schemaName`: The workflow schema being used (e.g., "spec-driven")
|
||||
- `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
|
||||
- `isComplete`: Boolean indicating if all artifacts are complete
|
||||
|
||||
3. **Act based on status**:
|
||||
|
||||
---
|
||||
|
||||
**If all artifacts are complete (`isComplete: true`)**:
|
||||
- Congratulate the user
|
||||
- Show final status including the schema used
|
||||
- Suggest: "All artifacts created! You can now implement this change or archive it."
|
||||
- STOP
|
||||
|
||||
---
|
||||
|
||||
**If artifacts are ready to create** (status shows artifacts with `status: "ready"`):
|
||||
- Pick the FIRST artifact with `status: "ready"` from the status output
|
||||
- Get its instructions:
|
||||
```bash
|
||||
openspec instructions <artifact-id> --change "<name>" --json
|
||||
```
|
||||
- Parse the JSON. The key fields are:
|
||||
- `context`: Project background (constraints for you - do NOT include in output)
|
||||
- `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
|
||||
- `template`: The structure to use for your output file
|
||||
- `instruction`: Schema-specific guidance
|
||||
- `outputPath`: Where to write the artifact
|
||||
- `dependencies`: Completed artifacts to read for context
|
||||
- **Create the artifact file**:
|
||||
- Read any completed dependency files for context
|
||||
- Use `template` as the structure - fill in its sections
|
||||
- Apply `context` and `rules` as constraints when writing - but do NOT copy them into the file
|
||||
- Write to the output path specified in instructions
|
||||
- Show what was created and what's now unlocked
|
||||
- STOP after creating ONE artifact
|
||||
|
||||
---
|
||||
|
||||
**If no artifacts are ready (all blocked)**:
|
||||
- This shouldn't happen with a valid schema
|
||||
- Show status and suggest checking for issues
|
||||
|
||||
4. **After creating an artifact, show progress**
|
||||
```bash
|
||||
openspec status --change "<name>"
|
||||
```
|
||||
|
||||
**Output**
|
||||
|
||||
After each invocation, show:
|
||||
- Which artifact was created
|
||||
- Schema workflow being used
|
||||
- Current progress (N/M complete)
|
||||
- What artifacts are now unlocked
|
||||
- Prompt: "Want to continue? Just ask me to continue or tell me what to do next."
|
||||
|
||||
**Artifact Creation Guidelines**
|
||||
|
||||
The artifact types and their purpose depend on the schema. Use the `instruction` field from the instructions output to understand what to create.
|
||||
|
||||
Common artifact patterns:
|
||||
|
||||
**spec-driven schema** (proposal → specs → design → tasks):
|
||||
- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
|
||||
- The Capabilities section is critical - each capability listed will need a spec file.
|
||||
- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
|
||||
- **design.md**: Document technical decisions, architecture, and implementation approach.
|
||||
- **tasks.md**: Break down implementation into checkboxed tasks.
|
||||
|
||||
For other schemas, follow the `instruction` field from the CLI output.
|
||||
|
||||
**Guardrails**
|
||||
- Create ONE artifact per invocation
|
||||
- Always read dependency artifacts before creating a new one
|
||||
- Never skip artifacts or create out of order
|
||||
- If context is unclear, ask the user before creating
|
||||
- Verify the artifact file exists after writing before marking progress
|
||||
- Use the schema's artifact sequence, don't assume specific artifact names
|
||||
- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
|
||||
- Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
|
||||
- These guide what you write, but should never appear in the output
|
||||
289
.opencode/skills/openspec-explore/SKILL.cn.md
Normal file
289
.opencode/skills/openspec-explore/SKILL.cn.md
Normal file
@@ -0,0 +1,289 @@
|
||||
---
|
||||
name: openspec-explore
|
||||
description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
进入探索模式。深入思考。自由可视化。跟随对话到任何方向。
|
||||
|
||||
**重要: 探索模式是用于思考,而不是实施。**您可以读取文件、搜索代码和调查代码库,但您**绝不能**编写代码或实施功能。如果用户要求您实施某些内容,提醒他们首先退出探索模式(例如,使用 `/opsx-new` 或 `/opsx-ff` 开始变更)。如果用户要求,您**可以**创建 OpenSpec artifacts(proposals、designs、specs)——这是捕获思考,而不是实施。
|
||||
|
||||
**这是一种姿态,而不是工作流。**没有固定步骤,没有必需的序列,没有强制性输出。您是一个思考伙伴,帮助用户探索。
|
||||
|
||||
---
|
||||
|
||||
## 姿态
|
||||
|
||||
- **好奇,而非规定** - 提出自然出现的问题,不要遵循脚本
|
||||
- **开放线索,而非审问** - 提出多个有趣的方向,让用户跟随共鸣的内容。不要将他们引导到单一的问题路径。
|
||||
- **可视化** - 当有助于澄清思考时,大量使用 ASCII 图表
|
||||
- **适应性** - 跟随有趣的线索,在新信息出现时调整
|
||||
- **耐心** - 不要急于得出结论,让问题的形状自然显现
|
||||
- **扎根** - 在相关时探索实际代码库,不只是理论化
|
||||
|
||||
---
|
||||
|
||||
## 您可能做什么
|
||||
|
||||
根据用户带来的内容,您可能:
|
||||
|
||||
**探索问题空间**
|
||||
- 提出从他们所说的内容中自然产生的澄清问题
|
||||
- 挑战假设
|
||||
- 重新定义问题
|
||||
- 寻找类比
|
||||
|
||||
**调查代码库**
|
||||
- 映射与讨论相关的现有架构
|
||||
- 找到集成点
|
||||
- 识别已在使用的模式
|
||||
- 揭示隐藏的复杂性
|
||||
|
||||
**比较选项**
|
||||
- 头脑风暴多种方法
|
||||
- 构建比较表
|
||||
- 勾勒权衡
|
||||
- 推荐路径(如果被询问)
|
||||
|
||||
**可视化**
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ 大量使用 ASCII 图表 │
|
||||
├─────────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌────────┐ ┌────────┐ │
|
||||
│ │ 状态 │────────▶│ 状态 │ │
|
||||
│ │ A │ │ B │ │
|
||||
│ └────────┘ └────────┘ │
|
||||
│ │
|
||||
│ 系统图、状态机、数据流、 │
|
||||
│ 架构草图、依赖图、比较表 │
|
||||
│ │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**揭示风险和未知因素**
|
||||
- 识别可能出错的地方
|
||||
- 找到理解上的差距
|
||||
- 建议探索或调查
|
||||
|
||||
---
|
||||
|
||||
## OpenSpec 感知
|
||||
|
||||
您拥有 OpenSpec 系统的完整上下文。自然地使用它,不要强制。
|
||||
|
||||
### 检查上下文
|
||||
|
||||
开始时,快速检查存在什么:
|
||||
```bash
|
||||
openspec list --json
|
||||
```
|
||||
|
||||
这会告诉您:
|
||||
- 是否有活动变更
|
||||
- 它们的名称、schemas 和状态
|
||||
- 用户可能正在处理什么
|
||||
|
||||
### 当不存在变更时
|
||||
|
||||
自由思考。当见解具体化时,您可能会提供:
|
||||
|
||||
- "这感觉足够扎实可以开始变更了。想让我创建一个吗?"
|
||||
→ 可以过渡到 `/opsx-new` 或 `/opsx-ff`
|
||||
- 或继续探索 - 不必急于正式化
|
||||
|
||||
### 当存在变更时
|
||||
|
||||
如果用户提到变更或您检测到相关变更:
|
||||
|
||||
1. **读取现有 artifacts 以获取上下文**
|
||||
- `openspec/changes/<name>/proposal.md`
|
||||
- `openspec/changes/<name>/design.md`
|
||||
- `openspec/changes/<name>/tasks.md`
|
||||
- 等等
|
||||
|
||||
2. **在对话中自然引用它们**
|
||||
- "您的设计提到使用 Redis,但我们刚刚意识到 SQLite 更合适..."
|
||||
- "proposal 将范围限定为高级用户,但我们现在考虑所有人..."
|
||||
|
||||
3. **在做出决策时提供捕获建议**
|
||||
|
||||
| 见解类型 | 捕获位置 |
|
||||
|---------|----------|
|
||||
| 发现新需求 | `specs/<capability>/spec.md` |
|
||||
| 需求变更 | `specs/<capability>/spec.md` |
|
||||
| 做出设计决策 | `design.md` |
|
||||
| 范围变更 | `proposal.md` |
|
||||
| 识别新工作 | `tasks.md` |
|
||||
| 假设失效 | 相关 artifact |
|
||||
|
||||
示例建议:
|
||||
- "这是一个设计决策。在 design.md 中捕获它?"
|
||||
- "这是一个新需求。添加到 specs?"
|
||||
- "这改变了范围。更新 proposal?"
|
||||
|
||||
4. **用户决定** - 提供建议并继续。不要施压。不要自动捕获。
|
||||
|
||||
---
|
||||
|
||||
## 您不必做什么
|
||||
|
||||
- 遵循脚本
|
||||
- 每次都问相同的问题
|
||||
- 产生特定的 artifact
|
||||
- 得出结论
|
||||
- 如果有价值的切线,保持主题
|
||||
- 简短(这是思考时间)
|
||||
|
||||
---
|
||||
|
||||
## 处理不同的入口点
|
||||
|
||||
**用户带来模糊想法:**
|
||||
```
|
||||
用户: 我在考虑添加实时协作功能
|
||||
|
||||
您: 实时协作是一个很大的空间。让我想想...
|
||||
|
||||
协作频谱
|
||||
════════════════════════════════════════════
|
||||
|
||||
意识 协调 同步
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌────────┐ ┌────────┐ ┌────────┐
|
||||
│在线状态│ │ 光标 │ │ CRDT │
|
||||
│ "3人 │ │ 多选 │ │无冲突 │
|
||||
│在线" │ │ │ │ │
|
||||
└────────┘ └────────┘ └────────┘
|
||||
│ │ │
|
||||
简单 中等 复杂
|
||||
|
||||
您的想法是什么?
|
||||
```
|
||||
|
||||
**用户带来具体问题:**
|
||||
```
|
||||
用户: 认证系统一团糟
|
||||
|
||||
您: [读取代码库]
|
||||
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ 当前认证流程 │
|
||||
└─────────────────────────────────────────────┘
|
||||
│
|
||||
┌─────────────┼─────────────┐
|
||||
▼ ▼ ▼
|
||||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
||||
│ Google │ │ GitHub │ │ Email │
|
||||
│ OAuth │ │ OAuth │ │ Magic │
|
||||
└────┬────┘ └────┬────┘ └────┬────┘
|
||||
│ │ │
|
||||
└─────────────┼─────────────┘
|
||||
▼
|
||||
┌───────────┐
|
||||
│ Session │
|
||||
└─────┬─────┘
|
||||
│
|
||||
▼
|
||||
┌───────────┐
|
||||
│ Perms │
|
||||
└───────────┘
|
||||
|
||||
我看到三处纠缠。哪一个在燃烧?
|
||||
```
|
||||
|
||||
**用户在实施中卡住:**
|
||||
```
|
||||
用户: /opsx-explore add-auth-system
|
||||
OAuth 集成比预期的更复杂
|
||||
|
||||
您: [读取变更 artifacts]
|
||||
|
||||
您在任务 4: "实施 OAuth 流程"
|
||||
|
||||
让我跟踪涉及的内容...
|
||||
|
||||
[绘制图表,探索选项,建议路径]
|
||||
|
||||
想要更新设计以反映这一点吗?
|
||||
或者添加一个探索任务来调查?
|
||||
```
|
||||
|
||||
**用户想要比较选项:**
|
||||
```
|
||||
用户: 我们应该使用 Postgres 还是 SQLite?
|
||||
|
||||
您: 通用答案很无聊。上下文是什么?
|
||||
|
||||
用户: 一个跟踪本地开发环境的 CLI 工具
|
||||
|
||||
您: 这改变了一切。
|
||||
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ CLI 工具数据存储 │
|
||||
└─────────────────────────────────────────────────┘
|
||||
|
||||
关键约束:
|
||||
• 没有运行的守护进程
|
||||
• 必须离线工作
|
||||
• 单用户
|
||||
|
||||
SQLite Postgres
|
||||
部署 嵌入式 ✓ 需要服务器 ✗
|
||||
离线 是 ✓ 否 ✗
|
||||
单文件 是 ✓ 否 ✗
|
||||
|
||||
SQLite。甚至不接近。
|
||||
|
||||
除非... 有同步组件吗?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 结束探索
|
||||
|
||||
没有必需的结束。探索可能:
|
||||
|
||||
- **流向行动**: "准备开始了吗? /opsx-new 或 /opsx-ff"
|
||||
- **导致 artifact 更新**: "用这些决策更新了 design.md"
|
||||
- **只是提供清晰度**: 用户得到了他们需要的,继续前进
|
||||
- **稍后继续**: "我们可以随时继续这个"
|
||||
|
||||
当感觉事情正在具体化时,您可能会总结:
|
||||
|
||||
```
|
||||
## 我们弄清楚了什么
|
||||
|
||||
**问题**: [具体化的理解]
|
||||
|
||||
**方法**: [如果出现了一个]
|
||||
|
||||
**开放问题**: [如果还有的话]
|
||||
|
||||
**下一步**(如果准备好):
|
||||
- 创建变更: /opsx-new <name>
|
||||
- 快进到任务: /opsx-ff <name>
|
||||
- 继续探索: 继续交谈
|
||||
```
|
||||
|
||||
但此总结是可选的。有时思考本身就是价值。
|
||||
|
||||
---
|
||||
|
||||
## 护栏
|
||||
|
||||
- **不要实施** - 永远不要编写代码或实施功能。创建 OpenSpec artifacts 是可以的,编写应用程序代码则不行。
|
||||
- **不要假装理解** - 如果某些东西不清楚,深入挖掘
|
||||
- **不要急** - 探索是思考时间,不是任务时间
|
||||
- **不要强制结构** - 让模式自然显现
|
||||
- **不要自动捕获** - 提供保存见解的建议,不要直接做
|
||||
- **要可视化** - 一个好的图表胜过许多段落
|
||||
- **要探索代码库** - 在现实中基础讨论
|
||||
- **要质疑假设** - 包括用户的和您自己的
|
||||
290
.opencode/skills/openspec-explore/SKILL.md
Normal file
290
.opencode/skills/openspec-explore/SKILL.md
Normal file
@@ -0,0 +1,290 @@
|
||||
---
|
||||
name: openspec-explore
|
||||
description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
|
||||
|
||||
**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first (e.g., start a change with `/opsx-new` or `/opsx-ff`). You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
|
||||
|
||||
**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
|
||||
|
||||
---
|
||||
|
||||
## The Stance
|
||||
|
||||
- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
|
||||
- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
|
||||
- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
|
||||
- **Adaptive** - Follow interesting threads, pivot when new information emerges
|
||||
- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
|
||||
- **Grounded** - Explore the actual codebase when relevant, don't just theorize
|
||||
|
||||
---
|
||||
|
||||
## What You Might Do
|
||||
|
||||
Depending on what the user brings, you might:
|
||||
|
||||
**Explore the problem space**
|
||||
- Ask clarifying questions that emerge from what they said
|
||||
- Challenge assumptions
|
||||
- Reframe the problem
|
||||
- Find analogies
|
||||
|
||||
**Investigate the codebase**
|
||||
- Map existing architecture relevant to the discussion
|
||||
- Find integration points
|
||||
- Identify patterns already in use
|
||||
- Surface hidden complexity
|
||||
|
||||
**Compare options**
|
||||
- Brainstorm multiple approaches
|
||||
- Build comparison tables
|
||||
- Sketch tradeoffs
|
||||
- Recommend a path (if asked)
|
||||
|
||||
**Visualize**
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Use ASCII diagrams liberally │
|
||||
├─────────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌────────┐ ┌────────┐ │
|
||||
│ │ State │────────▶│ State │ │
|
||||
│ │ A │ │ B │ │
|
||||
│ └────────┘ └────────┘ │
|
||||
│ │
|
||||
│ System diagrams, state machines, │
|
||||
│ data flows, architecture sketches, │
|
||||
│ dependency graphs, comparison tables │
|
||||
│ │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Surface risks and unknowns**
|
||||
- Identify what could go wrong
|
||||
- Find gaps in understanding
|
||||
- Suggest spikes or investigations
|
||||
|
||||
---
|
||||
|
||||
## OpenSpec Awareness
|
||||
|
||||
You have full context of the OpenSpec system. Use it naturally, don't force it.
|
||||
|
||||
### Check for context
|
||||
|
||||
At the start, quickly check what exists:
|
||||
```bash
|
||||
openspec list --json
|
||||
```
|
||||
|
||||
This tells you:
|
||||
- If there are active changes
|
||||
- Their names, schemas, and status
|
||||
- What the user might be working on
|
||||
|
||||
### When no change exists
|
||||
|
||||
Think freely. When insights crystallize, you might offer:
|
||||
|
||||
- "This feels solid enough to start a change. Want me to create one?"
|
||||
→ Can transition to `/opsx-new` or `/opsx-ff`
|
||||
- Or keep exploring - no pressure to formalize
|
||||
|
||||
### When a change exists
|
||||
|
||||
If the user mentions a change or you detect one is relevant:
|
||||
|
||||
1. **Read existing artifacts for context**
|
||||
- `openspec/changes/<name>/proposal.md`
|
||||
- `openspec/changes/<name>/design.md`
|
||||
- `openspec/changes/<name>/tasks.md`
|
||||
- etc.
|
||||
|
||||
2. **Reference them naturally in conversation**
|
||||
- "Your design mentions using Redis, but we just realized SQLite fits better..."
|
||||
- "The proposal scopes this to premium users, but we're now thinking everyone..."
|
||||
|
||||
3. **Offer to capture when decisions are made**
|
||||
|
||||
| Insight Type | Where to Capture |
|
||||
|--------------|------------------|
|
||||
| New requirement discovered | `specs/<capability>/spec.md` |
|
||||
| Requirement changed | `specs/<capability>/spec.md` |
|
||||
| Design decision made | `design.md` |
|
||||
| Scope changed | `proposal.md` |
|
||||
| New work identified | `tasks.md` |
|
||||
| Assumption invalidated | Relevant artifact |
|
||||
|
||||
Example offers:
|
||||
- "That's a design decision. Capture it in design.md?"
|
||||
- "This is a new requirement. Add it to specs?"
|
||||
- "This changes scope. Update the proposal?"
|
||||
|
||||
4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
|
||||
|
||||
---
|
||||
|
||||
## What You Don't Have To Do
|
||||
|
||||
- Follow a script
|
||||
- Ask the same questions every time
|
||||
- Produce a specific artifact
|
||||
- Reach a conclusion
|
||||
- Stay on topic if a tangent is valuable
|
||||
- Be brief (this is thinking time)
|
||||
|
||||
---
|
||||
|
||||
## Handling Different Entry Points
|
||||
|
||||
**User brings a vague idea:**
|
||||
```
|
||||
User: I'm thinking about adding real-time collaboration
|
||||
|
||||
You: Real-time collab is a big space. Let me think about this...
|
||||
|
||||
COLLABORATION SPECTRUM
|
||||
════════════════════════════════════════════
|
||||
|
||||
Awareness Coordination Sync
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌────────┐ ┌────────┐ ┌────────┐
|
||||
│Presence│ │Cursors │ │ CRDT │
|
||||
│ "3 │ │ Multi │ │Conflict│
|
||||
│online" │ │ select │ │ free │
|
||||
└────────┘ └────────┘ └────────┘
|
||||
│ │ │
|
||||
trivial moderate complex
|
||||
|
||||
Where's your head at?
|
||||
```
|
||||
|
||||
**User brings a specific problem:**
|
||||
```
|
||||
User: The auth system is a mess
|
||||
|
||||
You: [reads codebase]
|
||||
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ CURRENT AUTH FLOW │
|
||||
└─────────────────────────────────────────────┘
|
||||
│
|
||||
┌─────────────┼─────────────┐
|
||||
▼ ▼ ▼
|
||||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
||||
│ Google │ │ GitHub │ │ Email │
|
||||
│ OAuth │ │ OAuth │ │ Magic │
|
||||
└────┬────┘ └────┬────┘ └────┬────┘
|
||||
│ │ │
|
||||
└─────────────┼─────────────┘
|
||||
▼
|
||||
┌───────────┐
|
||||
│ Session │
|
||||
└─────┬─────┘
|
||||
│
|
||||
▼
|
||||
┌───────────┐
|
||||
│ Perms │
|
||||
└───────────┘
|
||||
|
||||
I see three tangles. Which one's burning?
|
||||
```
|
||||
|
||||
**User is stuck mid-implementation:**
|
||||
```
|
||||
User: /opsx-explore add-auth-system
|
||||
The OAuth integration is more complex than expected
|
||||
|
||||
You: [reads change artifacts]
|
||||
|
||||
You're on task 4: "Implement OAuth flow"
|
||||
|
||||
Let me trace what's involved...
|
||||
|
||||
[draws diagram, explores options, suggests paths]
|
||||
|
||||
Want to update the design to reflect this?
|
||||
Or add a spike task to investigate?
|
||||
```
|
||||
|
||||
**User wants to compare options:**
|
||||
```
|
||||
User: Should we use Postgres or SQLite?
|
||||
|
||||
You: Generic answer is boring. What's the context?
|
||||
|
||||
User: A CLI tool that tracks local dev environments
|
||||
|
||||
You: That changes everything.
|
||||
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ CLI TOOL DATA STORAGE │
|
||||
└─────────────────────────────────────────────────┘
|
||||
|
||||
Key constraints:
|
||||
• No daemon running
|
||||
• Must work offline
|
||||
• Single user
|
||||
|
||||
SQLite Postgres
|
||||
Deployment embedded ✓ needs server ✗
|
||||
Offline yes ✓ no ✗
|
||||
Single file yes ✓ no ✗
|
||||
|
||||
SQLite. Not even close.
|
||||
|
||||
Unless... is there a sync component?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ending Discovery
|
||||
|
||||
There's no required ending. Discovery might:
|
||||
|
||||
- **Flow into action**: "Ready to start? /opsx-new or /opsx-ff"
|
||||
- **Result in artifact updates**: "Updated design.md with these decisions"
|
||||
- **Just provide clarity**: User has what they need, moves on
|
||||
- **Continue later**: "We can pick this up anytime"
|
||||
|
||||
When it feels like things are crystallizing, you might summarize:
|
||||
|
||||
```
|
||||
## What We Figured Out
|
||||
|
||||
**The problem**: [crystallized understanding]
|
||||
|
||||
**The approach**: [if one emerged]
|
||||
|
||||
**Open questions**: [if any remain]
|
||||
|
||||
**Next steps** (if ready):
|
||||
- Create a change: /opsx-new <name>
|
||||
- Fast-forward to tasks: /opsx-ff <name>
|
||||
- Keep exploring: just keep talking
|
||||
```
|
||||
|
||||
But this summary is optional. Sometimes the thinking IS the value.
|
||||
|
||||
---
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
|
||||
- **Don't fake understanding** - If something is unclear, dig deeper
|
||||
- **Don't rush** - Discovery is thinking time, not task time
|
||||
- **Don't force structure** - Let patterns emerge naturally
|
||||
- **Don't auto-capture** - Offer to save insights, don't just do it
|
||||
- **Do visualize** - A good diagram is worth many paragraphs
|
||||
- **Do explore the codebase** - Ground discussions in reality
|
||||
- **Do question assumptions** - Including the user's and your own
|
||||
101
.opencode/skills/openspec-ff-change/SKILL.cn.md
Normal file
101
.opencode/skills/openspec-ff-change/SKILL.cn.md
Normal file
@@ -0,0 +1,101 @@
|
||||
---
|
||||
name: openspec-ff-change
|
||||
description: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
快速完成 artifact 创建 - 一次性生成开始实现所需的所有内容。
|
||||
|
||||
**输入**: 用户的请求应该包含变更名称 (kebab-case) 或对他们想要构建的内容的描述。
|
||||
|
||||
**步骤**
|
||||
|
||||
1. **如果未提供明确输入,询问他们想要构建什么**
|
||||
|
||||
使用 **AskUserQuestion 工具** (开放式,无预设选项) 询问:
|
||||
> "你想要处理什么变更?描述你想要构建或修复的内容。"
|
||||
|
||||
从他们的描述中,导出 kebab-case 名称 (例如: "add user authentication" → `add-user-auth`)。
|
||||
|
||||
**重要**: 不要在不了解用户想要构建什么的情况下继续。
|
||||
|
||||
2. **创建变更目录**
|
||||
```bash
|
||||
openspec new change "<name>"
|
||||
```
|
||||
这将在 `openspec/changes/<name>/` 创建一个脚手架变更。
|
||||
|
||||
3. **获取 artifact 构建顺序**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
解析 JSON 以获取:
|
||||
- `applyRequires`: 实现前需要的 artifact ID 数组 (例如: `["tasks"]`)
|
||||
- `artifacts`: 所有 artifacts 的列表及其状态和依赖关系
|
||||
|
||||
4. **按顺序创建 artifacts 直到准备好应用**
|
||||
|
||||
使用 **TodoWrite 工具**跟踪 artifacts 的进度。
|
||||
|
||||
按依赖顺序循环 artifacts (没有待处理依赖关系的 artifacts 优先):
|
||||
|
||||
a. **对于每个 `ready` 状态的 artifact (依赖关系已满足)**:
|
||||
- 获取指令:
|
||||
```bash
|
||||
openspec instructions <artifact-id> --change "<name>" --json
|
||||
```
|
||||
- 指令 JSON 包括:
|
||||
- `context`: 项目背景 (对你的约束 - 不要包含在输出中)
|
||||
- `rules`: Artifact 特定规则 (对你的约束 - 不要包含在输出中)
|
||||
- `template`: 用于输出文件的结构
|
||||
- `instruction`: 此 artifact 类型的 schema 特定指导
|
||||
- `outputPath`: artifact 写入位置
|
||||
- `dependencies`: 要读取以获取上下文的已完成 artifacts
|
||||
- 读取任何已完成的依赖文件以获取上下文
|
||||
- 使用 `template` 作为结构创建 artifact 文件
|
||||
- 将 `context` 和 `rules` 作为约束应用 - 但不要将它们复制到文件中
|
||||
- 显示简短进度: "✓ 已创建 <artifact-id>"
|
||||
|
||||
b. **继续直到所有 `applyRequires` artifacts 完成**
|
||||
- 创建每个 artifact 后,重新运行 `openspec status --change "<name>" --json`
|
||||
- 检查 `applyRequires` 中的每个 artifact ID 在 artifacts 数组中的 `status: "done"`
|
||||
- 当所有 `applyRequires` artifacts 都完成时停止
|
||||
|
||||
c. **如果 artifact 需要用户输入** (上下文不清楚):
|
||||
- 使用 **AskUserQuestion 工具**澄清
|
||||
- 然后继续创建
|
||||
|
||||
5. **显示最终状态**
|
||||
```bash
|
||||
openspec status --change "<name>"
|
||||
```
|
||||
|
||||
**输出**
|
||||
|
||||
完成所有 artifacts 后,总结:
|
||||
- 变更名称和位置
|
||||
- 创建的 artifacts 列表及简短描述
|
||||
- 准备就绪的内容: "所有 artifacts 已创建!准备实现。"
|
||||
- 提示: "运行 `/opsx-apply` 或要求我实现以开始处理任务。"
|
||||
|
||||
**Artifact 创建指南**
|
||||
|
||||
- 遵循每个 artifact 类型的 `openspec instructions` 中的 `instruction` 字段
|
||||
- Schema 定义了每个 artifact 应该包含什么 - 遵循它
|
||||
- 在创建新 artifacts 之前读取依赖 artifacts 以获取上下文
|
||||
- 使用 `template` 作为输出文件的结构 - 填充其部分
|
||||
- **重要**: `context` 和 `rules` 是对你的约束,而不是文件的内容
|
||||
- 不要将 `<context>`, `<rules>`, `<project_context>` 块复制到 artifact 中
|
||||
- 这些指导你写什么,但永远不应该出现在输出中
|
||||
|
||||
**防护机制**
|
||||
- 创建实现所需的所有 artifacts (由 schema 的 `apply.requires` 定义)
|
||||
- 在创建新 artifact 之前始终读取依赖 artifacts
|
||||
- 如果上下文严重不清楚,询问用户 - 但更倾向于做出合理决策以保持势头
|
||||
- 如果已存在同名变更,建议继续该变更
|
||||
- 在继续下一个之前验证每个 artifact 文件是否存在
|
||||
101
.opencode/skills/openspec-ff-change/SKILL.md
Normal file
101
.opencode/skills/openspec-ff-change/SKILL.md
Normal file
@@ -0,0 +1,101 @@
|
||||
---
|
||||
name: openspec-ff-change
|
||||
description: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Fast-forward through artifact creation - generate everything needed to start implementation in one go.
|
||||
|
||||
**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **If no clear input provided, ask what they want to build**
|
||||
|
||||
Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
|
||||
> "What change do you want to work on? Describe what you want to build or fix."
|
||||
|
||||
From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
|
||||
|
||||
**IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
|
||||
|
||||
2. **Create the change directory**
|
||||
```bash
|
||||
openspec new change "<name>"
|
||||
```
|
||||
This creates a scaffolded change at `openspec/changes/<name>/`.
|
||||
|
||||
3. **Get the artifact build order**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
Parse the JSON to get:
|
||||
- `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
|
||||
- `artifacts`: list of all artifacts with their status and dependencies
|
||||
|
||||
4. **Create artifacts in sequence until apply-ready**
|
||||
|
||||
Use the **TodoWrite tool** to track progress through the artifacts.
|
||||
|
||||
Loop through artifacts in dependency order (artifacts with no pending dependencies first):
|
||||
|
||||
a. **For each artifact that is `ready` (dependencies satisfied)**:
|
||||
- Get instructions:
|
||||
```bash
|
||||
openspec instructions <artifact-id> --change "<name>" --json
|
||||
```
|
||||
- The instructions JSON includes:
|
||||
- `context`: Project background (constraints for you - do NOT include in output)
|
||||
- `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
|
||||
- `template`: The structure to use for your output file
|
||||
- `instruction`: Schema-specific guidance for this artifact type
|
||||
- `outputPath`: Where to write the artifact
|
||||
- `dependencies`: Completed artifacts to read for context
|
||||
- Read any completed dependency files for context
|
||||
- Create the artifact file using `template` as the structure
|
||||
- Apply `context` and `rules` as constraints - but do NOT copy them into the file
|
||||
- Show brief progress: "✓ Created <artifact-id>"
|
||||
|
||||
b. **Continue until all `applyRequires` artifacts are complete**
|
||||
- After creating each artifact, re-run `openspec status --change "<name>" --json`
|
||||
- Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
|
||||
- Stop when all `applyRequires` artifacts are done
|
||||
|
||||
c. **If an artifact requires user input** (unclear context):
|
||||
- Use **AskUserQuestion tool** to clarify
|
||||
- Then continue with creation
|
||||
|
||||
5. **Show final status**
|
||||
```bash
|
||||
openspec status --change "<name>"
|
||||
```
|
||||
|
||||
**Output**
|
||||
|
||||
After completing all artifacts, summarize:
|
||||
- Change name and location
|
||||
- List of artifacts created with brief descriptions
|
||||
- What's ready: "All artifacts created! Ready for implementation."
|
||||
- Prompt: "Run `/opsx-apply` or ask me to implement to start working on the tasks."
|
||||
|
||||
**Artifact Creation Guidelines**
|
||||
|
||||
- Follow the `instruction` field from `openspec instructions` for each artifact type
|
||||
- The schema defines what each artifact should contain - follow it
|
||||
- Read dependency artifacts for context before creating new ones
|
||||
- Use `template` as the structure for your output file - fill in its sections
|
||||
- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
|
||||
- Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
|
||||
- These guide what you write, but should never appear in the output
|
||||
|
||||
**Guardrails**
|
||||
- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
|
||||
- Always read dependency artifacts before creating a new one
|
||||
- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
|
||||
- If a change with that name already exists, suggest continuing that change instead
|
||||
- Verify each artifact file exists after writing before proceeding to next
|
||||
74
.opencode/skills/openspec-new-change/SKILL.cn.md
Normal file
74
.opencode/skills/openspec-new-change/SKILL.cn.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
name: openspec-new-change
|
||||
description: Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
使用实验性 artifact 驱动方法开始新变更。
|
||||
|
||||
**输入**：用户的请求应包含变更名称(kebab-case)或他们想要构建的内容的描述。
|
||||
|
||||
**步骤**
|
||||
|
||||
1. **如果未提供明确输入,询问他们想要构建什么**
|
||||
|
||||
使用 **AskUserQuestion 工具**(开放式,无预设选项)询问:
|
||||
> "您想处理什么变更? 描述您想要构建或修复的内容。"
|
||||
|
||||
从他们的描述中,派生一个 kebab-case 名称(例如 "add user authentication" → `add-user-auth`)。
|
||||
|
||||
**重要**: 在不了解用户想要构建什么之前,不要继续。
|
||||
|
||||
2. **确定工作流 schema**
|
||||
|
||||
使用默认 schema(省略 `--schema`),除非用户明确请求不同的工作流。
|
||||
|
||||
**仅在用户提到时使用不同的 schema:**
|
||||
- 特定 schema 名称 → 使用 `--schema <name>`
|
||||
- "显示工作流"或"有哪些工作流" → 运行 `openspec schemas --json` 并让他们选择
|
||||
|
||||
**否则**: 省略 `--schema` 以使用默认值。
|
||||
|
||||
3. **创建变更目录**
|
||||
```bash
|
||||
openspec new change "<name>"
|
||||
```
|
||||
仅当用户请求特定工作流时才添加 `--schema <name>`。
|
||||
这将在 `openspec/changes/<name>/` 创建一个使用所选 schema 的脚手架变更。
|
||||
|
||||
4. **显示 artifact 状态**
|
||||
```bash
|
||||
openspec status --change "<name>"
|
||||
```
|
||||
这显示需要创建哪些 artifacts 以及哪些已准备好(依赖关系已满足)。
|
||||
|
||||
5. **获取第一个 artifact 的说明**
|
||||
第一个 artifact 取决于 schema(例如 spec-driven 的 `proposal`)。
|
||||
检查状态输出以找到第一个状态为 "ready" 的 artifact。
|
||||
```bash
|
||||
openspec instructions <first-artifact-id> --change "<name>"
|
||||
```
|
||||
这将输出创建第一个 artifact 的模板和上下文。
|
||||
|
||||
6. **停止并等待用户指示**
|
||||
|
||||
**输出**
|
||||
|
||||
完成步骤后,总结:
|
||||
- 变更名称和位置
|
||||
- 正在使用的 Schema/工作流及其 artifact 序列
|
||||
- 当前状态(已完成 0/N 个 artifacts)
|
||||
- 第一个 artifact 的模板
|
||||
- 提示: "准备创建第一个 artifact 了吗? 只需描述此变更的内容,我会起草它,或者让我继续。"
|
||||
|
||||
**护栏**
|
||||
- 还不要创建任何 artifacts - 只显示说明
|
||||
- 不要超越显示第一个 artifact 模板
|
||||
- 如果名称无效(不是 kebab-case),请求一个有效名称
|
||||
- 如果该名称的变更已存在,建议继续该变更
|
||||
- 如果使用非默认工作流,传递 --schema
|
||||
74
.opencode/skills/openspec-new-change/SKILL.md
Normal file
74
.opencode/skills/openspec-new-change/SKILL.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
name: openspec-new-change
|
||||
description: Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Start a new change using the experimental artifact-driven approach.
|
||||
|
||||
**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **If no clear input provided, ask what they want to build**
|
||||
|
||||
Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
|
||||
> "What change do you want to work on? Describe what you want to build or fix."
|
||||
|
||||
From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
|
||||
|
||||
**IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
|
||||
|
||||
2. **Determine the workflow schema**
|
||||
|
||||
Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
|
||||
|
||||
**Use a different schema only if the user mentions:**
|
||||
- A specific schema name → use `--schema <name>`
|
||||
- "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
|
||||
|
||||
**Otherwise**: Omit `--schema` to use the default.
|
||||
|
||||
3. **Create the change directory**
|
||||
```bash
|
||||
openspec new change "<name>"
|
||||
```
|
||||
Add `--schema <name>` only if the user requested a specific workflow.
|
||||
This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
|
||||
|
||||
4. **Show the artifact status**
|
||||
```bash
|
||||
openspec status --change "<name>"
|
||||
```
|
||||
This shows which artifacts need to be created and which are ready (dependencies satisfied).
|
||||
|
||||
5. **Get instructions for the first artifact**
|
||||
The first artifact depends on the schema (e.g., `proposal` for spec-driven).
|
||||
Check the status output to find the first artifact with status "ready".
|
||||
```bash
|
||||
openspec instructions <first-artifact-id> --change "<name>"
|
||||
```
|
||||
This outputs the template and context for creating the first artifact.
|
||||
|
||||
6. **STOP and wait for user direction**
|
||||
|
||||
**Output**
|
||||
|
||||
After completing the steps, summarize:
|
||||
- Change name and location
|
||||
- Schema/workflow being used and its artifact sequence
|
||||
- Current status (0/N artifacts complete)
|
||||
- The template for the first artifact
|
||||
- Prompt: "Ready to create the first artifact? Just describe what this change is about and I'll draft it, or ask me to continue."
|
||||
|
||||
**Guardrails**
|
||||
- Do NOT create any artifacts yet - just show the instructions
|
||||
- Do NOT advance beyond showing the first artifact template
|
||||
- If the name is invalid (not kebab-case), ask for a valid name
|
||||
- If a change with that name already exists, suggest continuing that change instead
|
||||
- Pass --schema if using a non-default workflow
|
||||
529
.opencode/skills/openspec-onboard/SKILL.cn.md
Normal file
529
.opencode/skills/openspec-onboard/SKILL.cn.md
Normal file
@@ -0,0 +1,529 @@
|
||||
---
|
||||
name: openspec-onboard
|
||||
description: OpenSpec 引导式入门教程 - 通过真实代码库工作完整演示工作流程
|
||||
license: MIT
|
||||
compatibility: 需要 openspec CLI。
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
引导用户完成他们的第一个完整 OpenSpec 工作流程周期。这是一次教学体验——你将在他们的代码库中做真实的工作,同时解释每个步骤。
|
||||
|
||||
---
|
||||
|
||||
## 准备检查
|
||||
|
||||
在开始之前,检查 OpenSpec 是否已初始化:
|
||||
|
||||
```bash
|
||||
openspec status --json 2>&1 || echo "NOT_INITIALIZED"
|
||||
```
|
||||
|
||||
**如果未初始化:**
|
||||
> OpenSpec 还未在此项目中设置。请先运行 `openspec init`,然后再回到 `/opsx-onboard`。
|
||||
|
||||
如果未初始化,在这里停止。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 1: 欢迎
|
||||
|
||||
显示:
|
||||
|
||||
```
|
||||
## 欢迎使用 OpenSpec!
|
||||
|
||||
我将带你完成一个完整的变更周期——从想法到实现——使用代码库中的真实任务。在此过程中,你将通过实践来学习工作流程。
|
||||
|
||||
**我们将做什么:**
|
||||
1. 在你的代码库中选择一个小的真实任务
|
||||
2. 简要探索问题
|
||||
3. 创建一个变更(我们工作的容器)
|
||||
4. 构建工件: proposal → specs → design → tasks
|
||||
5. 实现任务
|
||||
6. 归档完成的变更
|
||||
|
||||
**时间:** ~15-20 分钟
|
||||
|
||||
让我们从找到要做的事情开始。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 阶段 2: 任务选择
|
||||
|
||||
### 代码库分析
|
||||
|
||||
扫描代码库寻找小的改进机会。查找:
|
||||
|
||||
1. **TODO/FIXME 注释** - 在代码文件中搜索 `TODO`, `FIXME`, `HACK`, `XXX`
|
||||
2. **缺失的错误处理** - 吞噬错误的 `catch` 块,没有 try-catch 的风险操作
|
||||
3. **缺少测试的函数** - 将 `src/` 与测试目录交叉引用
|
||||
4. **类型问题** - TypeScript 文件中的 `any` 类型(`: any`, `as any`)
|
||||
5. **调试残留** - 非调试代码中的 `console.log`, `console.debug`, `debugger` 语句
|
||||
6. **缺失的验证** - 没有验证的用户输入处理器
|
||||
|
||||
还检查最近的 git 活动:
|
||||
```bash
|
||||
git log --oneline -10 2>/dev/null || echo "No git history"
|
||||
```
|
||||
|
||||
### 呈现建议
|
||||
|
||||
根据你的分析,呈现 3-4 个具体建议:
|
||||
|
||||
```
|
||||
## 任务建议
|
||||
|
||||
基于扫描你的代码库,这里有一些不错的入门任务:
|
||||
|
||||
**1. [最有希望的任务]**
|
||||
位置: `src/path/to/file.ts:42`
|
||||
范围: ~1-2 个文件, ~20-30 行
|
||||
为什么适合: [简短原因]
|
||||
|
||||
**2. [第二个任务]**
|
||||
位置: `src/another/file.ts`
|
||||
范围: ~1 个文件, ~15 行
|
||||
为什么适合: [简短原因]
|
||||
|
||||
**3. [第三个任务]**
|
||||
位置: [位置]
|
||||
范围: [估计]
|
||||
为什么适合: [简短原因]
|
||||
|
||||
**4. 其他?**
|
||||
告诉我你想做什么。
|
||||
|
||||
你对哪个任务感兴趣? (选择一个数字或描述你自己的)
|
||||
```
|
||||
|
||||
**如果没找到:** 退而询问用户想构建什么:
|
||||
> 我在你的代码库中没找到明显的快速改进。有什么小事情是你一直想添加或修复的吗?
|
||||
|
||||
### 范围守护
|
||||
|
||||
如果用户选择或描述的东西太大(主要功能,多天的工作):
|
||||
|
||||
```
|
||||
这是一个有价值的任务,但对于你第一次运行 OpenSpec 可能比理想的要大。
|
||||
|
||||
对于学习工作流程,越小越好——它让你看到完整的周期而不会陷入实现细节。
|
||||
|
||||
**选项:**
|
||||
1. **切得更小** - [他们的任务]最小的有用部分是什么? 也许只是[具体切片]?
|
||||
2. **选择其他** - 其他建议之一,或不同的小任务?
|
||||
3. **照做** - 如果你真的想处理这个,我们可以。只是知道会花更长时间。
|
||||
|
||||
你更喜欢什么?
|
||||
```
|
||||
|
||||
如果他们坚持,让用户覆盖——这是一个软守护。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 3: 探索演示
|
||||
|
||||
一旦选择了任务,简要演示探索模式:
|
||||
|
||||
```
|
||||
在创建变更之前,让我快速展示**探索模式**——这是你在承诺方向之前思考问题的方式。
|
||||
```
|
||||
|
||||
花 1-2 分钟调查相关代码:
|
||||
- 读取涉及的文件
|
||||
- 如果有帮助,画一个快速的 ASCII 图
|
||||
- 注意任何考虑因素
|
||||
|
||||
```
|
||||
## 快速探索
|
||||
|
||||
[你的简要分析——你发现了什么,任何考虑因素]
|
||||
|
||||
┌─────────────────────────────────────────┐
|
||||
│ [可选: 如果有帮助的 ASCII 图] │
|
||||
└─────────────────────────────────────────┘
|
||||
|
||||
探索模式 (`/opsx-explore`) 就是用于这种思考——在实现之前进行调查。你可以在需要思考问题时随时使用它。
|
||||
|
||||
现在让我们创建一个变更来保存我们的工作。
|
||||
```
|
||||
|
||||
**暂停** - 等待用户确认后再继续。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 4: 创建变更
|
||||
|
||||
**解释:**
|
||||
```
|
||||
## 创建变更
|
||||
|
||||
在 OpenSpec 中,"变更"是围绕一项工作的所有思考和规划的容器。它位于 `openspec/changes/<name>/` 中,包含你的工件——proposal、specs、design、tasks。
|
||||
|
||||
让我为我们的任务创建一个。
|
||||
```
|
||||
|
||||
**执行:** 使用派生的 kebab-case 名称创建变更:
|
||||
```bash
|
||||
openspec new change "<derived-name>"
|
||||
```
|
||||
|
||||
**显示:**
|
||||
```
|
||||
创建: `openspec/changes/<name>/`
|
||||
|
||||
文件夹结构:
|
||||
```
|
||||
openspec/changes/<name>/
|
||||
├── proposal.md ← 我们为什么这样做(空的,我们会填充)
|
||||
├── design.md ← 我们如何构建它(空的)
|
||||
├── specs/ ← 详细需求(空的)
|
||||
└── tasks.md ← 实现检查清单(空的)
|
||||
```
|
||||
|
||||
现在让我们填充第一个工件——proposal。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 阶段 5: Proposal
|
||||
|
||||
**解释:**
|
||||
```
|
||||
## Proposal
|
||||
|
||||
proposal 捕获我们为什么进行这个变更以及高层次的内容。这是工作的"电梯演讲"。
|
||||
|
||||
我将根据我们的任务起草一个。
|
||||
```
|
||||
|
||||
**执行:** 起草 proposal 内容(还不要保存):
|
||||
|
||||
```
|
||||
这是一个草案 proposal:
|
||||
|
||||
---
|
||||
|
||||
## 为什么 (Why)
|
||||
|
||||
[1-2 句话解释问题/机会]
|
||||
|
||||
## 变更内容 (What Changes)
|
||||
|
||||
[将会有什么不同的要点]
|
||||
|
||||
## 能力 (Capabilities)
|
||||
|
||||
### 新能力
|
||||
- `<capability-name>`: [简要描述]
|
||||
|
||||
### 修改的能力
|
||||
<!-- 如果修改现有行为 -->
|
||||
|
||||
## 影响 (Impact)
|
||||
|
||||
- `src/path/to/file.ts`: [什么变更]
|
||||
- [其他适用的文件]
|
||||
|
||||
---
|
||||
|
||||
这是否捕获了意图? 我可以在保存前调整。
|
||||
```
|
||||
|
||||
**暂停** - 等待用户批准/反馈。
|
||||
|
||||
批准后,保存 proposal:
|
||||
```bash
|
||||
openspec instructions proposal --change "<name>" --json
|
||||
```
|
||||
然后将内容写入 `openspec/changes/<name>/proposal.md`。
|
||||
|
||||
```
|
||||
Proposal 已保存。这是你的"为什么"文档——随着理解的演变,你总是可以回来完善它。
|
||||
|
||||
接下来: specs。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 阶段 6: Specs
|
||||
|
||||
**解释:**
|
||||
```
|
||||
## Specs
|
||||
|
||||
Specs 以精确、可测试的术语定义我们正在构建什么。它们使用需求/场景格式,使预期行为非常清晰。
|
||||
|
||||
对于像这样的小任务,我们可能只需要一个 spec 文件。
|
||||
```
|
||||
|
||||
**执行:** 创建 spec 文件:
|
||||
```bash
|
||||
mkdir -p openspec/changes/<name>/specs/<capability-name>
|
||||
```
|
||||
|
||||
起草 spec 内容:
|
||||
|
||||
```
|
||||
这是 spec:
|
||||
|
||||
---
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: <名称>
|
||||
|
||||
<系统应该做什么的描述>
|
||||
|
||||
#### Scenario: <场景名称>
|
||||
|
||||
- **WHEN** <触发条件>
|
||||
- **THEN** <预期结果>
|
||||
- **AND** <如需要的额外结果>
|
||||
|
||||
---
|
||||
|
||||
这种格式——WHEN/THEN/AND——使需求可测试。你可以直接将它们作为测试用例来读。
|
||||
```
|
||||
|
||||
保存到 `openspec/changes/<name>/specs/<capability>/spec.md`。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 7: Design
|
||||
|
||||
**解释:**
|
||||
```
|
||||
## Design
|
||||
|
||||
design 捕获我们如何构建它——技术决策、权衡、方法。
|
||||
|
||||
对于小变更,这可能很简短。这没关系——不是每个变更都需要深度设计讨论。
|
||||
```
|
||||
|
||||
**执行:** 起草 design.md:
|
||||
|
||||
```
|
||||
这是 design:
|
||||
|
||||
---
|
||||
|
||||
## 上下文 (Context)
|
||||
|
||||
[关于当前状态的简要上下文]
|
||||
|
||||
## 目标 / 非目标 (Goals / Non-Goals)
|
||||
|
||||
**目标:**
|
||||
- [我们试图实现什么]
|
||||
|
||||
**非目标:**
|
||||
- [明确超出范围的内容]
|
||||
|
||||
## 决策 (Decisions)
|
||||
|
||||
### Decision 1: [关键决策]
|
||||
|
||||
[方法和理由的解释]
|
||||
|
||||
---
|
||||
|
||||
对于小任务,这捕获了关键决策而不会过度设计。
|
||||
```
|
||||
|
||||
保存到 `openspec/changes/<name>/design.md`。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 8: Tasks
|
||||
|
||||
**解释:**
|
||||
```
|
||||
## Tasks
|
||||
|
||||
最后,我们将工作分解为实现任务——驱动应用阶段的复选框。
|
||||
|
||||
这些应该小、清晰且按逻辑顺序排列。
|
||||
```
|
||||
|
||||
**执行:** 基于 specs 和 design 生成任务:
|
||||
|
||||
```
|
||||
这是实现任务:
|
||||
|
||||
---
|
||||
|
||||
## 1. [类别或文件]
|
||||
|
||||
- [ ] 1.1 [具体任务]
|
||||
- [ ] 1.2 [具体任务]
|
||||
|
||||
## 2. 验证 (Verify)
|
||||
|
||||
- [ ] 2.1 [验证步骤]
|
||||
|
||||
---
|
||||
|
||||
每个复选框在应用阶段成为一个工作单元。准备好实现了吗?
|
||||
```
|
||||
|
||||
**暂停** - 等待用户确认他们准备好实现。
|
||||
|
||||
保存到 `openspec/changes/<name>/tasks.md`。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 9: Apply (实现)
|
||||
|
||||
**解释:**
|
||||
```
|
||||
## 实现 (Implementation)
|
||||
|
||||
现在我们实现每个任务,在进行时勾选它们。我会宣布每一个,偶尔注意 specs/design 如何指导方法。
|
||||
```
|
||||
|
||||
**执行:** 对于每个任务:
|
||||
|
||||
1. 宣布: "正在处理任务 N: [描述]"
|
||||
2. 在代码库中进行所需的更改
|
||||
3. 自然地引用 specs/design: "spec 说 X,所以我做 Y"
|
||||
4. 在 tasks.md 中标记完成: `- [ ]` → `- [x]`
|
||||
5. 简要状态: "✓ 任务 N 完成"
|
||||
|
||||
保持叙述轻量——不要过度解释每行代码。
|
||||
|
||||
所有任务完成后:
|
||||
|
||||
```
|
||||
## 实现完成
|
||||
|
||||
所有任务完成:
|
||||
- [x] Task 1
|
||||
- [x] Task 2
|
||||
- [x] ...
|
||||
|
||||
变更已实现! 还有一步——让我们归档它。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 阶段 10: Archive
|
||||
|
||||
**解释:**
|
||||
```
|
||||
## 归档 (Archiving)
|
||||
|
||||
当变更完成时,我们归档它。这将它从 `openspec/changes/` 移动到 `openspec/changes/archive/YYYY-MM-DD-<name>/`。
|
||||
|
||||
归档的变更成为你项目的决策历史——你总是可以在以后找到它们,以了解为什么某些东西是以某种方式构建的。
|
||||
```
|
||||
|
||||
**执行:**
|
||||
```bash
|
||||
openspec archive "<name>"
|
||||
```
|
||||
|
||||
**显示:**
|
||||
```
|
||||
归档到: `openspec/changes/archive/YYYY-MM-DD-<name>/`
|
||||
|
||||
变更现在是你项目历史的一部分。代码在你的代码库中,决策记录被保存。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 阶段 11: 回顾与下一步
|
||||
|
||||
```
|
||||
## 恭喜!
|
||||
|
||||
你刚刚完成了一个完整的 OpenSpec 周期:
|
||||
|
||||
1. **Explore** - 思考问题
|
||||
2. **New** - 创建变更容器
|
||||
3. **Proposal** - 捕获为什么 (WHY)
|
||||
4. **Specs** - 详细定义什么 (WHAT)
|
||||
5. **Design** - 决定如何 (HOW)
|
||||
6. **Tasks** - 分解为步骤
|
||||
7. **Apply** - 实现工作
|
||||
8. **Archive** - 保存记录
|
||||
|
||||
这个相同的节奏适用于任何规模的变更——无论是小修复还是主要功能。
|
||||
|
||||
---
|
||||
|
||||
## 命令参考
|
||||
|
||||
| 命令 | 功能 |
|
||||
|---------|--------------|
|
||||
| `/opsx-explore` | 在工作前/期间思考问题 |
|
||||
| `/opsx-new` | 启动新变更,逐步完成工件 |
|
||||
| `/opsx-ff` | 快进: 一次创建所有工件 |
|
||||
| `/opsx-continue` | 继续现有变更的工作 |
|
||||
| `/opsx-apply` | 实现变更中的任务 |
|
||||
| `/opsx-verify` | 验证实现与工件匹配 |
|
||||
| `/opsx-archive` | 归档完成的变更 |
|
||||
|
||||
---
|
||||
|
||||
## 下一步是什么?
|
||||
|
||||
在你真正想构建的东西上尝试 `/opsx-new` 或 `/opsx-ff`。你现在已经掌握了节奏!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 优雅退出处理
|
||||
|
||||
### 用户想中途停止
|
||||
|
||||
如果用户说他们需要停止、想暂停或看起来不再参与:
|
||||
|
||||
```
|
||||
没问题! 你的变更保存在 `openspec/changes/<name>/`。
|
||||
|
||||
要在以后从我们离开的地方继续:
|
||||
- `/opsx-continue <name>` - 恢复工件创建
|
||||
- `/opsx-apply <name>` - 跳转到实现(如果任务存在)
|
||||
|
||||
工作不会丢失。准备好时随时回来。
|
||||
```
|
||||
|
||||
优雅退出,不施加压力。
|
||||
|
||||
### 用户只想要命令参考
|
||||
|
||||
如果用户说他们只想看命令或跳过教程:
|
||||
|
||||
```
|
||||
## OpenSpec 快速参考
|
||||
|
||||
| 命令 | 功能 |
|
||||
|---------|--------------|
|
||||
| `/opsx-explore` | 思考问题(不改代码) |
|
||||
| `/opsx-new <name>` | 启动新变更,逐步进行 |
|
||||
| `/opsx-ff <name>` | 快进: 一次所有工件 |
|
||||
| `/opsx-continue <name>` | 继续现有变更 |
|
||||
| `/opsx-apply <name>` | 实现任务 |
|
||||
| `/opsx-verify <name>` | 验证实现 |
|
||||
| `/opsx-archive <name>` | 完成时归档 |
|
||||
|
||||
试试 `/opsx-new` 来开始你的第一个变更,或者如果你想快速移动就用 `/opsx-ff`。
|
||||
```
|
||||
|
||||
优雅退出。
|
||||
|
||||
---
|
||||
|
||||
## 守护
|
||||
|
||||
- **遵循 EXPLAIN → DO → SHOW → PAUSE 模式** 在关键转换点(探索后、proposal 草案后、任务后、归档后)
|
||||
- **保持叙述轻量** 在实现期间——教学但不说教
|
||||
- **不要跳过阶段** 即使变更很小——目标是教学工作流程
|
||||
- **在标记的点暂停等待确认**,但不要过度暂停
|
||||
- **优雅处理退出**——永远不要强迫用户继续
|
||||
- **使用真实代码库任务**——不要模拟或使用假例子
|
||||
- **温和地调整范围**——引导向更小的任务但尊重用户选择
|
||||
529
.opencode/skills/openspec-onboard/SKILL.md
Normal file
529
.opencode/skills/openspec-onboard/SKILL.md
Normal file
@@ -0,0 +1,529 @@
|
||||
---
|
||||
name: openspec-onboard
|
||||
description: Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Guide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
|
||||
|
||||
---
|
||||
|
||||
## Preflight
|
||||
|
||||
Before starting, check if OpenSpec is initialized:
|
||||
|
||||
```bash
|
||||
openspec status --json 2>&1 || echo "NOT_INITIALIZED"
|
||||
```
|
||||
|
||||
**If not initialized:**
|
||||
> OpenSpec isn't set up in this project yet. Run `openspec init` first, then come back to `/opsx-onboard`.
|
||||
|
||||
Stop here if not initialized.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Welcome
|
||||
|
||||
Display:
|
||||
|
||||
```
|
||||
## Welcome to OpenSpec!
|
||||
|
||||
I'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.
|
||||
|
||||
**What we'll do:**
|
||||
1. Pick a small, real task in your codebase
|
||||
2. Explore the problem briefly
|
||||
3. Create a change (the container for our work)
|
||||
4. Build the artifacts: proposal → specs → design → tasks
|
||||
5. Implement the tasks
|
||||
6. Archive the completed change
|
||||
|
||||
**Time:** ~15-20 minutes
|
||||
|
||||
Let's start by finding something to work on.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Task Selection
|
||||
|
||||
### Codebase Analysis
|
||||
|
||||
Scan the codebase for small improvement opportunities. Look for:
|
||||
|
||||
1. **TODO/FIXME comments** - Search for `TODO`, `FIXME`, `HACK`, `XXX` in code files
|
||||
2. **Missing error handling** - `catch` blocks that swallow errors, risky operations without try-catch
|
||||
3. **Functions without tests** - Cross-reference `src/` with test directories
|
||||
4. **Type issues** - `any` types in TypeScript files (`: any`, `as any`)
|
||||
5. **Debug artifacts** - `console.log`, `console.debug`, `debugger` statements in non-debug code
|
||||
6. **Missing validation** - User input handlers without validation
|
||||
|
||||
Also check recent git activity:
|
||||
```bash
|
||||
git log --oneline -10 2>/dev/null || echo "No git history"
|
||||
```
|
||||
|
||||
### Present Suggestions
|
||||
|
||||
From your analysis, present 3-4 specific suggestions:
|
||||
|
||||
```
|
||||
## Task Suggestions
|
||||
|
||||
Based on scanning your codebase, here are some good starter tasks:
|
||||
|
||||
**1. [Most promising task]**
|
||||
Location: `src/path/to/file.ts:42`
|
||||
Scope: ~1-2 files, ~20-30 lines
|
||||
Why it's good: [brief reason]
|
||||
|
||||
**2. [Second task]**
|
||||
Location: `src/another/file.ts`
|
||||
Scope: ~1 file, ~15 lines
|
||||
Why it's good: [brief reason]
|
||||
|
||||
**3. [Third task]**
|
||||
Location: [location]
|
||||
Scope: [estimate]
|
||||
Why it's good: [brief reason]
|
||||
|
||||
**4. Something else?**
|
||||
Tell me what you'd like to work on.
|
||||
|
||||
Which task interests you? (Pick a number or describe your own)
|
||||
```
|
||||
|
||||
**If nothing found:** Fall back to asking what the user wants to build:
|
||||
> I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?
|
||||
|
||||
### Scope Guardrail
|
||||
|
||||
If the user picks or describes something too large (major feature, multi-day work):
|
||||
|
||||
```
|
||||
That's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.
|
||||
|
||||
For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.
|
||||
|
||||
**Options:**
|
||||
1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?
|
||||
2. **Pick something else** - One of the other suggestions, or a different small task?
|
||||
3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.
|
||||
|
||||
What would you prefer?
|
||||
```
|
||||
|
||||
Let the user override if they insist—this is a soft guardrail.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Explore Demo
|
||||
|
||||
Once a task is selected, briefly demonstrate explore mode:
|
||||
|
||||
```
|
||||
Before we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.
|
||||
```
|
||||
|
||||
Spend 1-2 minutes investigating the relevant code:
|
||||
- Read the file(s) involved
|
||||
- Draw a quick ASCII diagram if it helps
|
||||
- Note any considerations
|
||||
|
||||
```
|
||||
## Quick Exploration
|
||||
|
||||
[Your brief analysis—what you found, any considerations]
|
||||
|
||||
┌─────────────────────────────────────────┐
|
||||
│ [Optional: ASCII diagram if helpful] │
|
||||
└─────────────────────────────────────────┘
|
||||
|
||||
Explore mode (`/opsx-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.
|
||||
|
||||
Now let's create a change to hold our work.
|
||||
```
|
||||
|
||||
**PAUSE** - Wait for user acknowledgment before proceeding.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Create the Change
|
||||
|
||||
**EXPLAIN:**
|
||||
```
|
||||
## Creating a Change
|
||||
|
||||
A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives in `openspec/changes/<name>/` and holds your artifacts—proposal, specs, design, tasks.
|
||||
|
||||
Let me create one for our task.
|
||||
```
|
||||
|
||||
**DO:** Create the change with a derived kebab-case name:
|
||||
```bash
|
||||
openspec new change "<derived-name>"
|
||||
```
|
||||
|
||||
**SHOW:**
|
||||
```
|
||||
Created: `openspec/changes/<name>/`
|
||||
|
||||
The folder structure:
|
||||
```
|
||||
openspec/changes/<name>/
|
||||
├── proposal.md ← Why we're doing this (empty, we'll fill it)
|
||||
├── design.md ← How we'll build it (empty)
|
||||
├── specs/ ← Detailed requirements (empty)
|
||||
└── tasks.md ← Implementation checklist (empty)
|
||||
```
|
||||
|
||||
Now let's fill in the first artifact—the proposal.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Proposal
|
||||
|
||||
**EXPLAIN:**
|
||||
```
|
||||
## The Proposal
|
||||
|
||||
The proposal captures **why** we're making this change and **what** it involves at a high level. It's the "elevator pitch" for the work.
|
||||
|
||||
I'll draft one based on our task.
|
||||
```
|
||||
|
||||
**DO:** Draft the proposal content (don't save yet):
|
||||
|
||||
```
|
||||
Here's a draft proposal:
|
||||
|
||||
---
|
||||
|
||||
## Why
|
||||
|
||||
[1-2 sentences explaining the problem/opportunity]
|
||||
|
||||
## What Changes
|
||||
|
||||
[Bullet points of what will be different]
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `<capability-name>`: [brief description]
|
||||
|
||||
### Modified Capabilities
|
||||
<!-- If modifying existing behavior -->
|
||||
|
||||
## Impact
|
||||
|
||||
- `src/path/to/file.ts`: [what changes]
|
||||
- [other files if applicable]
|
||||
|
||||
---
|
||||
|
||||
Does this capture the intent? I can adjust before we save it.
|
||||
```
|
||||
|
||||
**PAUSE** - Wait for user approval/feedback.
|
||||
|
||||
After approval, save the proposal:
|
||||
```bash
|
||||
openspec instructions proposal --change "<name>" --json
|
||||
```
|
||||
Then write the content to `openspec/changes/<name>/proposal.md`.
|
||||
|
||||
```
|
||||
Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
|
||||
|
||||
Next up: specs.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Specs
|
||||
|
||||
**EXPLAIN:**
|
||||
```
|
||||
## Specs
|
||||
|
||||
Specs define **what** we're building in precise, testable terms. They use a requirement/scenario format that makes expected behavior crystal clear.
|
||||
|
||||
For a small task like this, we might only need one spec file.
|
||||
```
|
||||
|
||||
**DO:** Create the spec file:
|
||||
```bash
|
||||
mkdir -p openspec/changes/<name>/specs/<capability-name>
|
||||
```
|
||||
|
||||
Draft the spec content:
|
||||
|
||||
```
|
||||
Here's the spec:
|
||||
|
||||
---
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: <Name>
|
||||
|
||||
<Description of what the system should do>
|
||||
|
||||
#### Scenario: <Scenario name>
|
||||
|
||||
- **WHEN** <trigger condition>
|
||||
- **THEN** <expected outcome>
|
||||
- **AND** <additional outcome if needed>
|
||||
|
||||
---
|
||||
|
||||
This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.
|
||||
```
|
||||
|
||||
Save to `openspec/changes/<name>/specs/<capability>/spec.md`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Design
|
||||
|
||||
**EXPLAIN:**
|
||||
```
|
||||
## Design
|
||||
|
||||
The design captures **how** we'll build it—technical decisions, tradeoffs, approach.
|
||||
|
||||
For small changes, this might be brief. That's fine—not every change needs deep design discussion.
|
||||
```
|
||||
|
||||
**DO:** Draft design.md:
|
||||
|
||||
```
|
||||
Here's the design:
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
[Brief context about the current state]
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- [What we're trying to achieve]
|
||||
|
||||
**Non-Goals:**
|
||||
- [What's explicitly out of scope]
|
||||
|
||||
## Decisions
|
||||
|
||||
### Decision 1: [Key decision]
|
||||
|
||||
[Explanation of approach and rationale]
|
||||
|
||||
---
|
||||
|
||||
For a small task, this captures the key decisions without over-engineering.
|
||||
```
|
||||
|
||||
Save to `openspec/changes/<name>/design.md`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 8: Tasks
|
||||
|
||||
**EXPLAIN:**
|
||||
```
|
||||
## Tasks
|
||||
|
||||
Finally, we break the work into implementation tasks—checkboxes that drive the apply phase.
|
||||
|
||||
These should be small, clear, and in logical order.
|
||||
```
|
||||
|
||||
**DO:** Generate tasks based on specs and design:
|
||||
|
||||
```
|
||||
Here are the implementation tasks:
|
||||
|
||||
---
|
||||
|
||||
## 1. [Category or file]
|
||||
|
||||
- [ ] 1.1 [Specific task]
|
||||
- [ ] 1.2 [Specific task]
|
||||
|
||||
## 2. Verify
|
||||
|
||||
- [ ] 2.1 [Verification step]
|
||||
|
||||
---
|
||||
|
||||
Each checkbox becomes a unit of work in the apply phase. Ready to implement?
|
||||
```
|
||||
|
||||
**PAUSE** - Wait for user to confirm they're ready to implement.
|
||||
|
||||
Save to `openspec/changes/<name>/tasks.md`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 9: Apply (Implementation)
|
||||
|
||||
**EXPLAIN:**
|
||||
```
|
||||
## Implementation
|
||||
|
||||
Now we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs/design informed the approach.
|
||||
```
|
||||
|
||||
**DO:** For each task:
|
||||
|
||||
1. Announce: "Working on task N: [description]"
|
||||
2. Implement the change in the codebase
|
||||
3. Reference specs/design naturally: "The spec says X, so I'm doing Y"
|
||||
4. Mark complete in tasks.md: `- [ ]` → `- [x]`
|
||||
5. Brief status: "✓ Task N complete"
|
||||
|
||||
Keep narration light—don't over-explain every line of code.
|
||||
|
||||
After all tasks:
|
||||
|
||||
```
|
||||
## Implementation Complete
|
||||
|
||||
All tasks done:
|
||||
- [x] Task 1
|
||||
- [x] Task 2
|
||||
- [x] ...
|
||||
|
||||
The change is implemented! One more step—let's archive it.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 10: Archive
|
||||
|
||||
**EXPLAIN:**
|
||||
```
|
||||
## Archiving
|
||||
|
||||
When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
|
||||
|
||||
Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
|
||||
```
|
||||
|
||||
**DO:**
|
||||
```bash
|
||||
openspec archive "<name>"
|
||||
```
|
||||
|
||||
**SHOW:**
|
||||
```
|
||||
Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`
|
||||
|
||||
The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 11: Recap & Next Steps
|
||||
|
||||
```
|
||||
## Congratulations!
|
||||
|
||||
You just completed a full OpenSpec cycle:
|
||||
|
||||
1. **Explore** - Thought through the problem
|
||||
2. **New** - Created a change container
|
||||
3. **Proposal** - Captured WHY
|
||||
4. **Specs** - Defined WHAT in detail
|
||||
5. **Design** - Decided HOW
|
||||
6. **Tasks** - Broke it into steps
|
||||
7. **Apply** - Implemented the work
|
||||
8. **Archive** - Preserved the record
|
||||
|
||||
This same rhythm works for any size change—a small fix or a major feature.
|
||||
|
||||
---
|
||||
|
||||
## Command Reference
|
||||
|
||||
| Command | What it does |
|
||||
|---------|--------------|
|
||||
| `/opsx-explore` | Think through problems before/during work |
|
||||
| `/opsx-new` | Start a new change, step through artifacts |
|
||||
| `/opsx-ff` | Fast-forward: create all artifacts at once |
|
||||
| `/opsx-continue` | Continue working on an existing change |
|
||||
| `/opsx-apply` | Implement tasks from a change |
|
||||
| `/opsx-verify` | Verify implementation matches artifacts |
|
||||
| `/opsx-archive` | Archive a completed change |
|
||||
|
||||
---
|
||||
|
||||
## What's Next?
|
||||
|
||||
Try `/opsx-new` or `/opsx-ff` on something you actually want to build. You've got the rhythm now!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Graceful Exit Handling
|
||||
|
||||
### User wants to stop mid-way
|
||||
|
||||
If the user says they need to stop, want to pause, or seem disengaged:
|
||||
|
||||
```
|
||||
No problem! Your change is saved at `openspec/changes/<name>/`.
|
||||
|
||||
To pick up where we left off later:
|
||||
- `/opsx-continue <name>` - Resume artifact creation
|
||||
- `/opsx-apply <name>` - Jump to implementation (if tasks exist)
|
||||
|
||||
The work won't be lost. Come back whenever you're ready.
|
||||
```
|
||||
|
||||
Exit gracefully without pressure.
|
||||
|
||||
### User just wants command reference
|
||||
|
||||
If the user says they just want to see the commands or skip the tutorial:
|
||||
|
||||
```
|
||||
## OpenSpec Quick Reference
|
||||
|
||||
| Command | What it does |
|
||||
|---------|--------------|
|
||||
| `/opsx-explore` | Think through problems (no code changes) |
|
||||
| `/opsx-new <name>` | Start a new change, step by step |
|
||||
| `/opsx-ff <name>` | Fast-forward: all artifacts at once |
|
||||
| `/opsx-continue <name>` | Continue an existing change |
|
||||
| `/opsx-apply <name>` | Implement tasks |
|
||||
| `/opsx-verify <name>` | Verify implementation |
|
||||
| `/opsx-archive <name>` | Archive when done |
|
||||
|
||||
Try `/opsx-new` to start your first change, or `/opsx-ff` if you want to move fast.
|
||||
```
|
||||
|
||||
Exit gracefully.
|
||||
|
||||
---
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **Follow the EXPLAIN → DO → SHOW → PAUSE pattern** at key transitions (after explore, after proposal draft, after tasks, after archive)
|
||||
- **Keep narration light** during implementation—teach without lecturing
|
||||
- **Don't skip phases** even if the change is small—the goal is teaching the workflow
|
||||
- **Pause for acknowledgment** at marked points, but don't over-pause
|
||||
- **Handle exits gracefully**—never pressure the user to continue
|
||||
- **Use real codebase tasks**—don't simulate or use fake examples
|
||||
- **Adjust scope gently**—guide toward smaller tasks but respect user choice
|
||||
138
.opencode/skills/openspec-sync-specs/SKILL.cn.md
Normal file
138
.opencode/skills/openspec-sync-specs/SKILL.cn.md
Normal file
@@ -0,0 +1,138 @@
|
||||
---
|
||||
name: openspec-sync-specs
|
||||
description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
将变更的 delta specs 同步到主 specs。
|
||||
|
||||
这是一个**代理驱动**的操作 - 你将读取 delta specs 并直接编辑主 specs 以应用更改。这允许智能合并 (例如,添加场景而不复制整个需求)。
|
||||
|
||||
**输入**: 可选择指定变更名称。如果省略,检查是否可以从对话上下文中推断。如果模糊或不明确,你**必须**提示可用的变更。
|
||||
|
||||
**步骤**
|
||||
|
||||
1. **如果未提供变更名称,提示用户选择**
|
||||
|
||||
运行 `openspec list --json` 获取可用的变更。使用 **AskUserQuestion 工具**让用户选择。
|
||||
|
||||
显示具有 delta specs 的变更 (在 `specs/` 目录下)。
|
||||
|
||||
**重要**: 不要猜测或自动选择变更。始终让用户选择。
|
||||
|
||||
2. **查找 delta specs**
|
||||
|
||||
在 `openspec/changes/<name>/specs/*/spec.md` 中查找 delta spec 文件。
|
||||
|
||||
每个 delta spec 文件包含如下部分:
|
||||
- `## ADDED Requirements` - 要添加的新需求
|
||||
- `## MODIFIED Requirements` - 对现有需求的更改
|
||||
- `## REMOVED Requirements` - 要删除的需求
|
||||
- `## RENAMED Requirements` - 要重命名的需求 (FROM:/TO: 格式)
|
||||
|
||||
如果未找到 delta specs,通知用户并停止。
|
||||
|
||||
3. **对于每个 delta spec,将更改应用到主 specs**
|
||||
|
||||
对于每个在 `openspec/changes/<name>/specs/<capability>/spec.md` 有 delta spec 的 capability:
|
||||
|
||||
a. **读取 delta spec** 以了解预期的更改
|
||||
|
||||
b. **读取主 spec** 在 `openspec/specs/<capability>/spec.md` (可能尚不存在)
|
||||
|
||||
c. **智能应用更改**:
|
||||
|
||||
**ADDED Requirements:**
|
||||
- 如果需求在主 spec 中不存在 → 添加它
|
||||
- 如果需求已存在 → 更新它以匹配 (视为隐式 MODIFIED)
|
||||
|
||||
**MODIFIED Requirements:**
|
||||
- 在主 spec 中找到需求
|
||||
- 应用更改 - 这可以是:
|
||||
- 添加新场景 (不需要复制现有场景)
|
||||
- 修改现有场景
|
||||
- 更改需求描述
|
||||
- 保留 delta 中未提及的场景/内容
|
||||
|
||||
**REMOVED Requirements:**
|
||||
- 从主 spec 中删除整个需求块
|
||||
|
||||
**RENAMED Requirements:**
|
||||
- 找到 FROM 需求,重命名为 TO
|
||||
|
||||
d. **创建新的主 spec** 如果 capability 尚不存在:
|
||||
- 创建 `openspec/specs/<capability>/spec.md`
|
||||
- 添加 Purpose 部分 (可以简短,标记为 TBD)
|
||||
- 添加 Requirements 部分,包含 ADDED 需求
|
||||
|
||||
4. **显示摘要**
|
||||
|
||||
应用所有更改后,总结:
|
||||
- 更新了哪些 capabilities
|
||||
- 做了哪些更改 (需求添加/修改/删除/重命名)
|
||||
|
||||
**Delta Spec 格式参考**
|
||||
|
||||
```markdown
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 新功能
|
||||
系统应当做某件新事情。
|
||||
|
||||
#### Scenario: 基本情况
|
||||
- **WHEN** 用户执行 X
|
||||
- **THEN** 系统执行 Y
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: 现有功能
|
||||
#### Scenario: 要添加的新场景
|
||||
- **WHEN** 用户执行 A
|
||||
- **THEN** 系统执行 B
|
||||
|
||||
## REMOVED Requirements
|
||||
|
||||
### Requirement: 已弃用功能
|
||||
|
||||
## RENAMED Requirements
|
||||
|
||||
- FROM: `### Requirement: 旧名称`
|
||||
- TO: `### Requirement: 新名称`
|
||||
```
|
||||
|
||||
**核心原则: 智能合并**
|
||||
|
||||
与程序化合并不同,你可以应用**部分更新**:
|
||||
- 要添加场景,只需在 MODIFIED 下包含该场景 - 不要复制现有场景
|
||||
- Delta 代表*意图*,而不是全部替换
|
||||
- 使用你的判断合理地合并更改
|
||||
|
||||
**成功时的输出**
|
||||
|
||||
```
|
||||
## Specs 已同步: <change-name>
|
||||
|
||||
更新的主 specs:
|
||||
|
||||
**<capability-1>**:
|
||||
- 添加需求: "新功能"
|
||||
- 修改需求: "现有功能" (添加 1 个场景)
|
||||
|
||||
**<capability-2>**:
|
||||
- 创建新 spec 文件
|
||||
- 添加需求: "另一个功能"
|
||||
|
||||
主 specs 现已更新。变更保持活跃 - 实现完成后归档。
|
||||
```
|
||||
|
||||
**防护机制**
|
||||
- 在进行更改前读取 delta 和主 specs
|
||||
- 保留 delta 中未提及的现有内容
|
||||
- 如果有不清楚的地方,请求澄清
|
||||
- 边做边显示你正在更改的内容
|
||||
- 操作应该是幂等的 - 运行两次应该给出相同结果
|
||||
138
.opencode/skills/openspec-sync-specs/SKILL.md
Normal file
138
.opencode/skills/openspec-sync-specs/SKILL.md
Normal file
@@ -0,0 +1,138 @@
|
||||
---
|
||||
name: openspec-sync-specs
|
||||
description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Sync delta specs from a change to main specs.
|
||||
|
||||
This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
|
||||
|
||||
**Input**: Optionally specify a change name. 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 delta specs (under `specs/` directory).
|
||||
|
||||
**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
|
||||
|
||||
2. **Find delta specs**
|
||||
|
||||
Look for delta spec files in `openspec/changes/<name>/specs/*/spec.md`.
|
||||
|
||||
Each delta spec file contains sections like:
|
||||
- `## ADDED Requirements` - New requirements to add
|
||||
- `## MODIFIED Requirements` - Changes to existing requirements
|
||||
- `## REMOVED Requirements` - Requirements to remove
|
||||
- `## RENAMED Requirements` - Requirements to rename (FROM:/TO: format)
|
||||
|
||||
If no delta specs found, inform user and stop.
|
||||
|
||||
3. **For each delta spec, apply changes to main specs**
|
||||
|
||||
For each capability with a delta spec at `openspec/changes/<name>/specs/<capability>/spec.md`:
|
||||
|
||||
a. **Read the delta spec** to understand the intended changes
|
||||
|
||||
b. **Read the main spec** at `openspec/specs/<capability>/spec.md` (may not exist yet)
|
||||
|
||||
c. **Apply changes intelligently**:
|
||||
|
||||
**ADDED Requirements:**
|
||||
- If requirement doesn't exist in main spec → add it
|
||||
- If requirement already exists → update it to match (treat as implicit MODIFIED)
|
||||
|
||||
**MODIFIED Requirements:**
|
||||
- Find the requirement in main spec
|
||||
- Apply the changes - this can be:
|
||||
- Adding new scenarios (don't need to copy existing ones)
|
||||
- Modifying existing scenarios
|
||||
- Changing the requirement description
|
||||
- Preserve scenarios/content not mentioned in the delta
|
||||
|
||||
**REMOVED Requirements:**
|
||||
- Remove the entire requirement block from main spec
|
||||
|
||||
**RENAMED Requirements:**
|
||||
- Find the FROM requirement, rename to TO
|
||||
|
||||
d. **Create new main spec** if capability doesn't exist yet:
|
||||
- Create `openspec/specs/<capability>/spec.md`
|
||||
- Add Purpose section (can be brief, mark as TBD)
|
||||
- Add Requirements section with the ADDED requirements
|
||||
|
||||
4. **Show summary**
|
||||
|
||||
After applying all changes, summarize:
|
||||
- Which capabilities were updated
|
||||
- What changes were made (requirements added/modified/removed/renamed)
|
||||
|
||||
**Delta Spec Format Reference**
|
||||
|
||||
```markdown
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: New Feature
|
||||
The system SHALL do something new.
|
||||
|
||||
#### Scenario: Basic case
|
||||
- **WHEN** user does X
|
||||
- **THEN** system does Y
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Existing Feature
|
||||
#### Scenario: New scenario to add
|
||||
- **WHEN** user does A
|
||||
- **THEN** system does B
|
||||
|
||||
## REMOVED Requirements
|
||||
|
||||
### Requirement: Deprecated Feature
|
||||
|
||||
## RENAMED Requirements
|
||||
|
||||
- FROM: `### Requirement: Old Name`
|
||||
- TO: `### Requirement: New Name`
|
||||
```
|
||||
|
||||
**Key Principle: Intelligent Merging**
|
||||
|
||||
Unlike programmatic merging, you can apply **partial updates**:
|
||||
- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
|
||||
- The delta represents *intent*, not a wholesale replacement
|
||||
- Use your judgment to merge changes sensibly
|
||||
|
||||
**Output On Success**
|
||||
|
||||
```
|
||||
## Specs Synced: <change-name>
|
||||
|
||||
Updated main specs:
|
||||
|
||||
**<capability-1>**:
|
||||
- Added requirement: "New Feature"
|
||||
- Modified requirement: "Existing Feature" (added 1 scenario)
|
||||
|
||||
**<capability-2>**:
|
||||
- Created new spec file
|
||||
- Added requirement: "Another Feature"
|
||||
|
||||
Main specs are now updated. The change remains active - archive when implementation is complete.
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Read both delta and main specs before making changes
|
||||
- Preserve existing content not mentioned in delta
|
||||
- If something is unclear, ask for clarification
|
||||
- Show what you're changing as you go
|
||||
- The operation should be idempotent - running twice should give same result
|
||||
168
.opencode/skills/openspec-verify-change/SKILL.cn.md
Normal file
168
.opencode/skills/openspec-verify-change/SKILL.cn.md
Normal file
@@ -0,0 +1,168 @@
|
||||
---
|
||||
name: openspec-verify-change
|
||||
description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
验证实现是否与变更 artifacts (specs、tasks、design) 匹配。
|
||||
|
||||
**输入**: 可选择指定变更名称。如果省略,检查是否可以从对话上下文中推断。如果模糊或不明确,你**必须**提示可用的变更。
|
||||
|
||||
**步骤**
|
||||
|
||||
1. **如果未提供变更名称,提示用户选择**
|
||||
|
||||
运行 `openspec list --json` 获取可用的变更。使用 **AskUserQuestion 工具**让用户选择。
|
||||
|
||||
显示具有实现任务的变更 (tasks artifact 存在)。
|
||||
如果可用,包含每个变更使用的 schema。
|
||||
将具有未完成任务的变更标记为 "(进行中)"。
|
||||
|
||||
**重要**: 不要猜测或自动选择变更。始终让用户选择。
|
||||
|
||||
2. **检查状态以了解 schema**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
解析 JSON 以了解:
|
||||
- `schemaName`: 正在使用的工作流 (例如: "spec-driven")
|
||||
- 此变更存在哪些 artifacts
|
||||
|
||||
3. **获取变更目录并加载 artifacts**
|
||||
|
||||
```bash
|
||||
openspec instructions apply --change "<name>" --json
|
||||
```
|
||||
|
||||
这将返回变更目录和上下文文件。从 `contextFiles` 读取所有可用的 artifacts。
|
||||
|
||||
4. **初始化验证报告结构**
|
||||
|
||||
创建具有三个维度的报告结构:
|
||||
- **完整性 (Completeness)**: 跟踪任务和 spec 覆盖率
|
||||
- **正确性 (Correctness)**: 跟踪需求实现和场景覆盖
|
||||
- **一致性 (Coherence)**: 跟踪设计遵循情况和模式一致性
|
||||
|
||||
每个维度可以有 CRITICAL、WARNING 或 SUGGESTION 问题。
|
||||
|
||||
5. **验证完整性**
|
||||
|
||||
**任务完成度**:
|
||||
- 如果 contextFiles 中存在 tasks.md,读取它
|
||||
- 解析复选框: `- [ ]` (未完成) vs `- [x]` (已完成)
|
||||
- 统计已完成任务 vs 总任务数
|
||||
- 如果存在未完成的任务:
|
||||
- 为每个未完成的任务添加 CRITICAL 问题
|
||||
- 建议: "完成任务: <描述>" 或 "如果已实现请标记为完成"
|
||||
|
||||
**Spec 覆盖率**:
|
||||
- 如果 `openspec/changes/<name>/specs/` 中存在 delta specs:
|
||||
- 提取所有需求 (标记为 "### Requirement:")
|
||||
- 对于每个需求:
|
||||
- 在代码库中搜索与需求相关的关键字
|
||||
- 评估实现是否可能存在
|
||||
- 如果需求看起来未实现:
|
||||
- 添加 CRITICAL 问题: "未找到需求: <需求名称>"
|
||||
- 建议: "实现需求 X: <描述>"
|
||||
|
||||
6. **验证正确性**
|
||||
|
||||
**需求实现映射**:
|
||||
- 对于 delta specs 中的每个需求:
|
||||
- 在代码库中搜索实现证据
|
||||
- 如果找到,记录文件路径和行范围
|
||||
- 评估实现是否符合需求意图
|
||||
- 如果检测到偏差:
|
||||
- 添加 WARNING: "实现可能偏离 spec: <详情>"
|
||||
- 建议: "根据需求 X 审查 <file>:<lines>"
|
||||
|
||||
**场景覆盖**:
|
||||
- 对于 delta specs 中的每个场景 (标记为 "#### Scenario:"):
|
||||
- 检查代码中是否处理了条件
|
||||
- 检查是否存在覆盖该场景的测试
|
||||
- 如果场景看起来未覆盖:
|
||||
- 添加 WARNING: "场景未覆盖: <场景名称>"
|
||||
- 建议: "为场景添加测试或实现: <描述>"
|
||||
|
||||
7. **验证一致性**
|
||||
|
||||
**设计遵循**:
|
||||
- 如果 contextFiles 中存在 design.md:
|
||||
- 提取关键决策 (查找类似 "Decision:", "Approach:", "Architecture:" 的部分)
|
||||
- 验证实现是否遵循这些决策
|
||||
- 如果检测到矛盾:
|
||||
- 添加 WARNING: "未遵循设计决策: <决策>"
|
||||
- 建议: "更新实现或修订 design.md 以匹配实际情况"
|
||||
- 如果没有 design.md: 跳过设计遵循检查,注明 "没有 design.md 可供验证"
|
||||
|
||||
**代码模式一致性**:
|
||||
- 审查新代码与项目模式的一致性
|
||||
- 检查文件命名、目录结构、编码风格
|
||||
- 如果发现重大偏差:
|
||||
- 添加 SUGGESTION: "代码模式偏差: <详情>"
|
||||
- 建议: "考虑遵循项目模式: <示例>"
|
||||
|
||||
8. **生成验证报告**
|
||||
|
||||
**总结记分卡**:
|
||||
```
|
||||
## 验证报告: <change-name>
|
||||
|
||||
### 总结
|
||||
| 维度 | 状态 |
|
||||
|-----------|-------------------|
|
||||
| 完整性 | X/Y 任务, N 需求 |
|
||||
| 正确性 | M/N 需求已覆盖 |
|
||||
| 一致性 | 已遵循/有问题 |
|
||||
```
|
||||
|
||||
**按优先级分类的问题**:
|
||||
|
||||
1. **CRITICAL** (归档前必须修复):
|
||||
- 未完成的任务
|
||||
- 缺失的需求实现
|
||||
- 每个都有具体、可操作的建议
|
||||
|
||||
2. **WARNING** (应该修复):
|
||||
- Spec/design 偏差
|
||||
- 缺失的场景覆盖
|
||||
- 每个都有具体建议
|
||||
|
||||
3. **SUGGESTION** (最好修复):
|
||||
- 模式不一致
|
||||
- 小改进
|
||||
- 每个都有具体建议
|
||||
|
||||
**最终评估**:
|
||||
- 如果有 CRITICAL 问题: "发现 X 个关键问题。归档前请修复。"
|
||||
- 如果只有警告: "无关键问题。有 Y 个警告需要考虑。准备归档 (带注明的改进)。"
|
||||
- 如果全部通过: "所有检查通过。准备归档。"
|
||||
|
||||
**验证启发式方法**
|
||||
|
||||
- **完整性**: 专注于客观的检查清单项 (复选框、需求列表)
|
||||
- **正确性**: 使用关键字搜索、文件路径分析、合理推断 - 不要求完全确定
|
||||
- **一致性**: 寻找明显的不一致,不要挑剔风格
|
||||
- **误报**: 如果不确定,优先选择 SUGGESTION 而不是 WARNING,WARNING 而不是 CRITICAL
|
||||
- **可操作性**: 每个问题都必须有具体的建议,并在适用时提供文件/行引用
|
||||
|
||||
**优雅降级**
|
||||
|
||||
- 如果只存在 tasks.md: 仅验证任务完成度,跳过 spec/design 检查
|
||||
- 如果 tasks + specs 存在: 验证完整性和正确性,跳过 design
|
||||
- 如果完整 artifacts 存在: 验证所有三个维度
|
||||
- 始终注明跳过了哪些检查以及原因
|
||||
|
||||
**输出格式**
|
||||
|
||||
使用清晰的 markdown:
|
||||
- 总结记分卡使用表格
|
||||
- 问题分组列表 (CRITICAL/WARNING/SUGGESTION)
|
||||
- 代码引用格式: `file.ts:123`
|
||||
- 具体、可操作的建议
|
||||
- 不要使用模糊的建议如 "考虑审查"
|
||||
168
.opencode/skills/openspec-verify-change/SKILL.md
Normal file
168
.opencode/skills/openspec-verify-change/SKILL.md
Normal file
@@ -0,0 +1,168 @@
|
||||
---
|
||||
name: openspec-verify-change
|
||||
description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.1.1"
|
||||
---
|
||||
|
||||
Verify that an implementation matches the change artifacts (specs, tasks, design).
|
||||
|
||||
**Input**: Optionally specify a change name. 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"
|
||||
765
.opencode/skills/pancli-design/SKILL.cn.md
Normal file
765
.opencode/skills/pancli-design/SKILL.cn.md
Normal file
@@ -0,0 +1,765 @@
|
||||
---
|
||||
name: pancli-design
|
||||
description: 专业的设计技能,用于使用 pancli (pencil tools) 创建现代化、一致的 EmailBill 移动端 UI 设计
|
||||
license: MIT
|
||||
compatibility: Requires pencil_* tools (batch_design, batch_get, etc.)
|
||||
metadata:
|
||||
author: EmailBill Design Team
|
||||
version: "2.0.0"
|
||||
generatedBy: opencode
|
||||
lastUpdated: "2026-02-03"
|
||||
source: ".pans/v2.pen 日历设计 (亮色/暗色)"
|
||||
---
|
||||
|
||||
# pancli-design - EmailBill UI 设计系统
|
||||
|
||||
> 专业的设计技能,用于使用 pancli (pencil tools) 创建现代化、一致的移动端 UI 设计。
|
||||
|
||||
## 何时使用此技能
|
||||
|
||||
**总是使用此技能当:**
|
||||
- 使用 pancli 创建新的 UI 界面或组件
|
||||
- 修改现有的 .pen 设计文件
|
||||
- 处理亮色/暗色主题设计
|
||||
- 为 EmailBill 项目设计移动端优先的界面
|
||||
|
||||
**触发条件:**
|
||||
- 用户提到 "画设计图"、"设计"、"UI"、"界面"、"pancli"、".pen"
|
||||
- 任务涉及 `pencil_*` 工具
|
||||
- 创建视觉原型或模型
|
||||
|
||||
## 核心设计原则
|
||||
|
||||
### 1. 现代移动端优先设计
|
||||
|
||||
**核心规范:**
|
||||
- 移动视口: 375px 宽度 (iPhone SE 基准)
|
||||
- 安全区域: 尊重 iOS/Android 安全区域边距
|
||||
- 交互元素最小触摸目标: 44x44px
|
||||
- 间距基于 8px 网格: 4px, 8px, 12px, 16px, 24px, 32px
|
||||
- 卡片阴影: `0 2px 12px rgba(0,0,0,0.08)` (亮色模式)
|
||||
|
||||
**反 AI 设计痕迹检查清单:**
|
||||
- ❌ 使用 "Dashboard", "Lorem Ipsum" 等通用占位符
|
||||
- ❌ 使用过饱和的颜色或生硬的渐变
|
||||
- ❌ 使用装饰性字体 (Comic Sans, Papyrus)
|
||||
- ✅ 使用代码库中的真实中文业务术语
|
||||
- ✅ 使用克制的配色和柔和的阴影
|
||||
- ✅ 使用专业的系统字体
|
||||
|
||||
### 2. 统一色彩系统
|
||||
|
||||
**色彩分层:**
|
||||
- **背景层**: 页面背景 → 卡片背景 → 强调背景 (三层递进)
|
||||
- **文本层**: 主文本 → 次要文本 → 三级文本 (三级层次)
|
||||
- **语义色**: 红色(支出/危险) → 黄色(警告) → 绿色(收入/成功) → 蓝色(主操作/信息)
|
||||
|
||||
**颜色使用规则:**
|
||||
- 始终使用语义颜色变量,避免硬编码十六进制值
|
||||
- 支出/负数统一使用红色 `#FF6B6B`,收入/正数使用绿色系
|
||||
- 主操作按钮统一使用蓝色 `#3B82F6`
|
||||
- 避免纯黑 (#000000) 或纯白 (#FFFFFF) 文本,使用柔和的色调
|
||||
- 暗色模式下减少阴影强度或完全移除
|
||||
- 详细色值参见文末"快速参考"表格
|
||||
|
||||
### 3. 排版系统
|
||||
|
||||
**字体栈:**
|
||||
- **标题**: `'Bricolage Grotesque'` - 用于大数值、章节标题
|
||||
- **正文**: `'DM Sans'` - 用于界面文本、说明
|
||||
- **数字**: `'DIN Alternate'` - 用于金额、数据显示
|
||||
- **备选**: `-apple-system, 'PingFang SC'` - 系统默认字体
|
||||
|
||||
**排版原则:**
|
||||
- 使用真实中文业务术语,避免 Lorem Ipsum
|
||||
- 行高: 1.4-1.6 保证可读性
|
||||
- 数字数据使用等宽字体 (tabular-nums)
|
||||
- 字号遵循比例系统,避免任意数值
|
||||
- 详细字号比例参见文末"快速参考"表格
|
||||
|
||||
### 4. 组件库
|
||||
|
||||
**设计原则:**
|
||||
- 所有尺寸和间距基于 8px 网格系统
|
||||
- 圆角: 12px (小按钮), 16px/20px (卡片), 22px/28px (圆形按钮)
|
||||
- 交互元素最小触摸目标: 44x44px
|
||||
- 详细组件规格参见文末"快速参考"表格
|
||||
|
||||
**卡片设计 (基于 statsCard, tCard):**
|
||||
```
|
||||
统计卡片 (大卡片):
|
||||
- 背景: #F6F7F8 (亮色), #18181B (暗色)
|
||||
- 内边距: 20px
|
||||
- 圆角: 20px
|
||||
- 间距: 12px (元素之间)
|
||||
- 布局: 垂直
|
||||
|
||||
交易卡片 (列表卡片):
|
||||
- 背景: #F6F7F8 (亮色), #18181B (暗色)
|
||||
- 内边距: 16px
|
||||
- 圆角: 16px
|
||||
- 间距: 14px (水平元素)
|
||||
- 高度: 自适应内容
|
||||
```
|
||||
|
||||
**按钮 (基于实际设计):**
|
||||
```
|
||||
图标按钮 (通知按钮):
|
||||
- 尺寸: 44x44px
|
||||
- 圆角: 22px (完全圆形)
|
||||
- 背景: #F5F5F5 (亮色), #27272A (暗色)
|
||||
- 图标大小: 20px
|
||||
|
||||
标签按钮:
|
||||
- 内边距: 6px 10px / 6px 12px
|
||||
- 圆角: 12px
|
||||
- 字体: DM Sans 13px/500
|
||||
- 颜色:
|
||||
- 温暖色: #FFFBEB (亮色), #451A03 (暗色)
|
||||
- 绿色: #F0FDF4 (亮色), #064E3B (暗色)
|
||||
- 蓝色: #E0E7FF (亮色), #312E81 (暗色)
|
||||
|
||||
悬浮按钮 (FAB):
|
||||
- 尺寸: 56x56px
|
||||
- 圆角: 28px
|
||||
- 背景: #3B82F6
|
||||
- 描边: 4px 白色边框
|
||||
- 阴影: 提升效果
|
||||
```
|
||||
|
||||
**图标与文字:**
|
||||
```
|
||||
图标容器:
|
||||
- 尺寸: 44x44px
|
||||
- 圆角: 22px
|
||||
- 背景: #FFFFFF (亮色), #27272A (暗色)
|
||||
- 图标: 20px (lucide 字体)
|
||||
- 颜色: #FF6B6B (星标), #FCD34D (咖啡)
|
||||
|
||||
章节标题:
|
||||
- 字体: Bricolage Grotesque 18px/700
|
||||
- 颜色: #1A1A1A (亮色), #F4F4F5 (暗色)
|
||||
|
||||
大数值:
|
||||
- 字体: Bricolage Grotesque 32px/800
|
||||
- 颜色: #1A1A1A (亮色), #F4F4F5 (暗色)
|
||||
```
|
||||
|
||||
**布局模式 (基于 Calendar 结构):**
|
||||
```
|
||||
页面容器: 402px (设计视口), 垂直布局, 24px 内边距
|
||||
头部区域: 水平布局, 两端对齐, 8px 24px 内边距
|
||||
内容区域: 垂直布局, 24px 内边距, 12-16px 间距
|
||||
```
|
||||
|
||||
**关键布局原则:**
|
||||
- 遵循 Flex 容器模式 (见下方"5. 布局模式")
|
||||
- 导航栏背景必须透明 (`:deep(.van-nav-bar) { background: transparent !important; }`)
|
||||
- 尊重安全区域 (`env(safe-area-inset-bottom)`)
|
||||
|
||||
### 5. 布局模式
|
||||
|
||||
**页面结构 (Flex 容器):**
|
||||
```
|
||||
.page-container-flex:
|
||||
- display: flex
|
||||
- flex-direction: column
|
||||
- height: 100%
|
||||
- overflow: hidden
|
||||
|
||||
结构:
|
||||
1. van-nav-bar (固定高度)
|
||||
2. van-tabs 或 sticky-header
|
||||
3. scroll-content (flex: 1, overflow-y: auto)
|
||||
4. bottom-button 或 van-tabbar (固定)
|
||||
```
|
||||
|
||||
**导航栏背景透明化 (项目标准模式):**
|
||||
```css
|
||||
/* 所有页面统一设置 */
|
||||
:deep(.van-nav-bar) {
|
||||
background: transparent !important;
|
||||
}
|
||||
```
|
||||
**关键要求:**
|
||||
- 页面容器必须有明确的背景色
|
||||
- 必须使用 `:deep()` 选择器覆盖 Vant 样式
|
||||
- 必须添加 `!important` 标记
|
||||
- 在 `<style scoped>` 块中添加此规则
|
||||
|
||||
**安全区域处理:**
|
||||
```css
|
||||
/* iPhone 刘海底部内边距 */
|
||||
padding-bottom: env(safe-area-inset-bottom, 0px);
|
||||
|
||||
/* 状态栏顶部内边距 */
|
||||
padding-top: max(0px, calc(env(safe-area-inset-top, 0px) * 0.75));
|
||||
```
|
||||
|
||||
**固定元素:**
|
||||
```css
|
||||
.sticky-header {
|
||||
position: sticky;
|
||||
top: 0;
|
||||
z-index: 10;
|
||||
background: var(--van-background-2);
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 2px 8px rgba(0,0,0,0.04);
|
||||
margin: 12px;
|
||||
padding: 12px 16px;
|
||||
}
|
||||
```
|
||||
|
||||
### 6. 交互模式
|
||||
|
||||
**触摸反馈:**
|
||||
- 激活状态: 点击时 scale(0.95)
|
||||
- 涟漪效果: 使用 Vant 内置触摸反馈
|
||||
- 悬停状态: 12% 透明度叠加 (网页端)
|
||||
|
||||
**加载状态:**
|
||||
```
|
||||
van-pull-refresh:
|
||||
- 用于顶层可滚动内容
|
||||
- 最小高度: calc(100vh - nav - tabbar)
|
||||
|
||||
van-loading:
|
||||
- 容器内居中
|
||||
- 尺寸: 内联 24px, 页面 32px
|
||||
```
|
||||
|
||||
**空状态:**
|
||||
```
|
||||
van-empty:
|
||||
- 图标: 60px 大小
|
||||
- 描述: 14px, var(--van-text-color-2)
|
||||
- 内边距: 垂直 48px
|
||||
```
|
||||
|
||||
**悬浮操作:**
|
||||
```
|
||||
van-floating-bubble:
|
||||
- 图标大小: 24px
|
||||
- 位置: 右下角, 距底部 100px (避开 tabbar)
|
||||
- 磁吸: 贴靠 x 轴边缘
|
||||
```
|
||||
|
||||
### 7. 数据可视化
|
||||
|
||||
**预算进度条:**
|
||||
```
|
||||
渐变逻辑:
|
||||
支出 (0% → 100%):
|
||||
- 0%: #40a9ff (安全蓝)
|
||||
- 40%: #36cfc9 (青色过渡)
|
||||
- 70%: #faad14 (警告黄)
|
||||
- 100%: #ff4d4f (危险红)
|
||||
|
||||
收入 (0% → 100%):
|
||||
- 0%: #f5222d (深红 - 未开始)
|
||||
- 45%: #ffcccc (浅红)
|
||||
- 50%: #f0f2f5 (中性灰)
|
||||
- 55%: #bae7ff (浅蓝)
|
||||
- 100%: #1890ff (深蓝 - 达成)
|
||||
```
|
||||
|
||||
**金额显示:**
|
||||
```css
|
||||
.amount {
|
||||
font-family: 'DIN Alternate', system-ui;
|
||||
font-weight: 600;
|
||||
font-variant-numeric: tabular-nums;
|
||||
}
|
||||
|
||||
.expense { color: var(--van-danger-color); }
|
||||
.income { color: var(--van-success-color); }
|
||||
```
|
||||
|
||||
**图表 (如果使用):**
|
||||
- 折线图: 2px 笔画, 圆角连接
|
||||
- 柱状图: 8px 圆角, 4px 间距
|
||||
- 颜色: 使用语义色阶
|
||||
- 网格线: 1px, 8% 透明度
|
||||
|
||||
### 8. 主题切换 (亮色/暗色)
|
||||
|
||||
**实现策略:**
|
||||
```javascript
|
||||
// 自动检测系统偏好
|
||||
const isDark = window.matchMedia('(prefers-color-scheme: dark)').matches
|
||||
theme.value = isDark ? 'dark' : 'light'
|
||||
document.documentElement.setAttribute('data-theme', theme.value)
|
||||
```
|
||||
|
||||
**设计文件要求:**
|
||||
- **必须同时创建亮色和暗色变体**
|
||||
- 使用 Vant 的主题变量 (自动切换)
|
||||
- 测试对比度: WCAG AA 最低标准 (文本 4.5:1)
|
||||
- 暗色模式适配:
|
||||
- 减少卡片阴影至 0 2px 8px rgba(0,0,0,0.24)
|
||||
- 增加边框对比度
|
||||
- 白色文本柔化至 #e5e5e5
|
||||
|
||||
**pancli 工作流:**
|
||||
```
|
||||
1. 先创建亮色主题设计
|
||||
2. 复制帧用于暗色模式
|
||||
3. 使用 replace_all_matching_properties 批量更新:
|
||||
- 背景颜色
|
||||
- 文本颜色
|
||||
- 边框颜色
|
||||
4. 手动调整阴影和叠加
|
||||
5. 命名帧: "[屏幕名称] - Light" / "[屏幕名称] - Dark"
|
||||
```
|
||||
|
||||
### 9. 命名约定
|
||||
|
||||
**帧名称:**
|
||||
```
|
||||
格式: [模块] - [屏幕] - [变体]
|
||||
|
||||
示例:
|
||||
✅ Budget - List View - Light
|
||||
✅ Budget - Edit Dialog - Dark
|
||||
✅ Transaction - Card Component
|
||||
✅ Statistics - Chart Section
|
||||
|
||||
❌ Screen1
|
||||
❌ Frame_Copy_2
|
||||
❌ New Design
|
||||
```
|
||||
|
||||
**组件层级:**
|
||||
```
|
||||
可复用组件:
|
||||
- 前缀 "Component/"
|
||||
- 示例: "Component/BudgetCard"
|
||||
|
||||
屏幕:
|
||||
- 按模块分组
|
||||
- 示例: "Budget/ListView", "Budget/EditForm"
|
||||
```
|
||||
|
||||
### 10. 质量检查清单
|
||||
|
||||
**设计完成前必检项:**
|
||||
- [ ] 同时创建亮色和暗色主题
|
||||
- [ ] 使用真实中文业务术语 (无占位文本)
|
||||
- [ ] 交互元素 ≥ 44x44px
|
||||
- [ ] 间距遵循 8px 网格
|
||||
- [ ] 使用语义颜色变量 (非硬编码)
|
||||
- [ ] 导航栏背景透明 (`:deep(.van-nav-bar)`)
|
||||
- [ ] 帧命名: 模块-屏幕-变体 格式
|
||||
- [ ] 可复用组件标记 `reusable: true`
|
||||
- [ ] 两种主题截图验证
|
||||
|
||||
**无障碍标准:**
|
||||
- [ ] 正文对比度 ≥ 4.5:1
|
||||
- [ ] 大文本对比度 ≥ 3:1 (18px+)
|
||||
- [ ] 触摸目标间距 ≥ 8px
|
||||
|
||||
## PANCLI 工作流程
|
||||
|
||||
### 阶段 1: 设置与风格选择
|
||||
|
||||
```typescript
|
||||
// 1. 获取编辑器状态
|
||||
pencil_get_editor_state(include_schema: true)
|
||||
|
||||
// 2. 获取设计指南
|
||||
pencil_get_guidelines(topic: "landing-page") // 或 "design-system"
|
||||
|
||||
// 3. 选择合适的风格指南
|
||||
pencil_get_style_guide_tags() // 获取可用标签
|
||||
|
||||
// 4. 使用标签获取风格指南
|
||||
pencil_get_style_guide(tags: [
|
||||
"mobile", // 必需
|
||||
"webapp", // 类应用界面
|
||||
"modern", // 简洁, 现代
|
||||
"minimal", // 避免杂乱
|
||||
"professional", // 商业环境
|
||||
"blue", // 主色提示
|
||||
"fintech" // 如果可用
|
||||
])
|
||||
```
|
||||
|
||||
### 阶段 2: 创建亮色主题设计
|
||||
|
||||
```typescript
|
||||
// 5. 读取现有组件 (如果有)
|
||||
pencil_batch_get(
|
||||
filePath: "designs/emailbill.pen",
|
||||
patterns: [{ reusable: true }],
|
||||
readDepth: 2
|
||||
)
|
||||
|
||||
// 6. 创建亮色主题屏幕
|
||||
pencil_batch_design(
|
||||
filePath: "designs/emailbill.pen",
|
||||
operations: `
|
||||
screen=I(document, {
|
||||
type: "frame",
|
||||
name: "Budget - List View - Light",
|
||||
width: 375,
|
||||
height: 812,
|
||||
fill: "#FFFFFF",
|
||||
layout: "vertical",
|
||||
placeholder: true
|
||||
})
|
||||
|
||||
navbar=I(screen, {
|
||||
type: "frame",
|
||||
name: "Navbar",
|
||||
width: "fill_container",
|
||||
height: 44,
|
||||
fill: "transparent",
|
||||
layout: "horizontal",
|
||||
padding: [12, 16, 12, 16]
|
||||
})
|
||||
|
||||
title=I(navbar, {
|
||||
type: "text",
|
||||
content: "预算管理",
|
||||
fontSize: 16,
|
||||
fontWeight: "600",
|
||||
textColor: "#1A1A1A"
|
||||
})
|
||||
|
||||
// ... 更多操作
|
||||
`
|
||||
)
|
||||
```
|
||||
|
||||
### 阶段 3: 创建暗色主题变体
|
||||
|
||||
```typescript
|
||||
// 7. 复制亮色主题帧
|
||||
pencil_batch_design(
|
||||
operations: `
|
||||
darkScreen=C("light-screen-id", document, {
|
||||
name: "Budget - List View - Dark",
|
||||
positionDirection: "right",
|
||||
positionPadding: 48
|
||||
})
|
||||
`
|
||||
)
|
||||
|
||||
// 8. 批量替换暗色主题颜色
|
||||
pencil_replace_all_matching_properties(
|
||||
parents: ["dark-screen-id"],
|
||||
properties: {
|
||||
fillColor: [
|
||||
{ from: "#FFFFFF", to: "#09090B" }, // 页面背景
|
||||
{ from: "#F6F7F8", to: "#18181B" }, // 卡片背景
|
||||
{ from: "#F5F5F5", to: "#27272A" } // 边框
|
||||
],
|
||||
textColor: [
|
||||
{ from: "#1A1A1A", to: "#F4F4F5" }, // 主文本
|
||||
{ from: "#6B7280", to: "#A1A1AA" }, // 次要
|
||||
{ from: "#9CA3AF", to: "#71717A" } // 三级
|
||||
]
|
||||
}
|
||||
)
|
||||
|
||||
// 9. 手动调整暗色模式阴影 (如需要)
|
||||
pencil_batch_design(
|
||||
operations: `
|
||||
U("dark-card-id", {
|
||||
shadow: {
|
||||
x: 0,
|
||||
y: 2,
|
||||
blur: 8,
|
||||
color: "rgba(0,0,0,0.24)"
|
||||
}
|
||||
})
|
||||
`
|
||||
)
|
||||
```
|
||||
|
||||
### 阶段 4: 验证
|
||||
|
||||
```typescript
|
||||
// 10. 对两种主题截图
|
||||
pencil_get_screenshot(nodeId: "light-screen-id")
|
||||
pencil_get_screenshot(nodeId: "dark-screen-id")
|
||||
|
||||
// 11. 检查布局问题
|
||||
pencil_snapshot_layout(
|
||||
parentId: "light-screen-id",
|
||||
problemsOnly: true
|
||||
)
|
||||
|
||||
// 12. 验证所有唯一属性
|
||||
pencil_search_all_unique_properties(
|
||||
parents: ["light-screen-id"],
|
||||
properties: ["fillColor", "textColor", "fontSize"]
|
||||
)
|
||||
```
|
||||
|
||||
## 代码库实际示例
|
||||
|
||||
### 示例 1: 预算卡片组件
|
||||
|
||||
```
|
||||
组件结构:
|
||||
BudgetCard (375x120px)
|
||||
├─ CardBackground (#ffffff, 16px 圆角, 阴影)
|
||||
├─ HeaderRow (水平布局)
|
||||
│ ├─ CategoryName (16px, 600 粗细)
|
||||
│ └─ PeriodLabel (12px, 次要颜色)
|
||||
├─ ProgressBar (基于比例渐变)
|
||||
│ └─ ProgressFill (高度: 8px, 圆角: 4px)
|
||||
├─ AmountRow (水平布局, 两端对齐)
|
||||
│ ├─ CurrentAmount (DIN, 18px, 危险色)
|
||||
│ ├─ LimitAmount (DIN, 14px, 次要)
|
||||
│ └─ RemainingAmount (DIN, 14px, 成功色)
|
||||
└─ FooterActions (可选, 储蓄按钮)
|
||||
```
|
||||
|
||||
**pancli 实现:**
|
||||
```typescript
|
||||
card=I(parent, {
|
||||
type: "frame",
|
||||
name: "BudgetCard",
|
||||
width: "fill_container",
|
||||
height: 120,
|
||||
fill: "#ffffff",
|
||||
cornerRadius: [16, 16, 16, 16],
|
||||
shadow: { x: 0, y: 2, blur: 12, color: "rgba(0,0,0,0.08)" },
|
||||
stroke: { color: "#ebedf0", thickness: 1 },
|
||||
padding: [16, 16, 16, 16],
|
||||
layout: "vertical",
|
||||
gap: 12,
|
||||
placeholder: true
|
||||
})
|
||||
|
||||
header=I(card, {
|
||||
type: "frame",
|
||||
layout: "horizontal",
|
||||
width: "fill_container",
|
||||
height: "hug_contents"
|
||||
})
|
||||
|
||||
categoryName=I(header, {
|
||||
type: "text",
|
||||
content: "日常开销",
|
||||
fontSize: 16,
|
||||
fontWeight: "600",
|
||||
textColor: "#323233"
|
||||
})
|
||||
|
||||
// 带渐变的进度条
|
||||
progressBar=I(card, {
|
||||
type: "frame",
|
||||
width: "fill_container",
|
||||
height: 8,
|
||||
fill: "#f0f0f0",
|
||||
cornerRadius: [4, 4, 4, 4]
|
||||
})
|
||||
|
||||
progressFill=I(progressBar, {
|
||||
type: "frame",
|
||||
width: "75%", // 75% 进度示例
|
||||
height: 8,
|
||||
fill: "linear-gradient(90deg, #40a9ff 0%, #faad14 100%)",
|
||||
cornerRadius: [4, 4, 4, 4]
|
||||
})
|
||||
```
|
||||
|
||||
### 示例 2: 带日期选择器的固定头部
|
||||
|
||||
```
|
||||
固定头部模式 (来自 BudgetView):
|
||||
├─ 位置: sticky, top: 0
|
||||
├─ 背景: var(--van-background-2)
|
||||
├─ 圆角: 12px
|
||||
├─ 阴影: 0 2px 8px rgba(0,0,0,0.04)
|
||||
├─ 内边距: 12px 16px
|
||||
├─ 内容: "2024年1月" + 下拉箭头图标
|
||||
```
|
||||
|
||||
### 示例 3: 滑动删除列表项
|
||||
|
||||
```
|
||||
van-swipe-cell 模式:
|
||||
├─ 内容: BudgetCard 组件
|
||||
├─ 右侧操作: 删除按钮
|
||||
│ ├─ 宽度: 60px
|
||||
│ ├─ 背景: var(--van-danger-color)
|
||||
│ ├─ 文本: "删除"
|
||||
│ └─ 全高 (100%)
|
||||
```
|
||||
|
||||
## 避免的反模式
|
||||
|
||||
**❌ 不要这样做:**
|
||||
```
|
||||
// 通用 AI 生成内容
|
||||
title=I(navbar, {
|
||||
type: "text",
|
||||
content: "Dashboard", // ❌ 使用 "预算管理" 代替
|
||||
fontSize: 20, // ❌ 按字号比例使用 16px
|
||||
fontWeight: "bold" // ❌ 使用数字值 600
|
||||
})
|
||||
|
||||
// 不一致的间距
|
||||
card=I(parent, {
|
||||
padding: [15, 13, 17, 14] // ❌ 使用 8px 网格: [16, 16, 16, 16]
|
||||
})
|
||||
|
||||
// 硬编码颜色而非语义
|
||||
amount=I(card, {
|
||||
textColor: "#ff0000" // ❌ 使用 var(--van-danger-color) 或 "#ee0a24"
|
||||
})
|
||||
|
||||
// 缺少暗色模式
|
||||
// ❌ 只创建亮色主题没有暗色变体
|
||||
|
||||
// 糟糕的命名
|
||||
frame=I(document, {
|
||||
name: "Frame_123" // ❌ 使用 "Budget - List View - Light"
|
||||
})
|
||||
```
|
||||
|
||||
**✅ 应该这样做:**
|
||||
```typescript
|
||||
// 真实业务术语
|
||||
title=I(navbar, {
|
||||
type: "text",
|
||||
content: "预算管理",
|
||||
fontSize: 16,
|
||||
fontWeight: "600",
|
||||
textColor: "#323233"
|
||||
})
|
||||
|
||||
// 一致的 8px 网格间距
|
||||
card=I(parent, {
|
||||
padding: [16, 16, 16, 16],
|
||||
gap: 12
|
||||
})
|
||||
|
||||
// 语义颜色变量
|
||||
amount=I(card, {
|
||||
textColor: "#ee0a24", // 一致的危险色
|
||||
fontFamily: "DIN Alternate"
|
||||
})
|
||||
|
||||
// 总是创建两种主题
|
||||
lightScreen=I(document, { name: "Budget - List - Light" })
|
||||
darkScreen=C(lightScreen, document, {
|
||||
name: "Budget - List - Dark",
|
||||
positionDirection: "right"
|
||||
})
|
||||
|
||||
// 清晰的描述性名称
|
||||
card=I(parent, {
|
||||
name: "BudgetCard",
|
||||
reusable: true
|
||||
})
|
||||
```
|
||||
|
||||
## 委派与任务管理
|
||||
|
||||
**使用此技能时:**
|
||||
|
||||
```typescript
|
||||
// 委派设计任务时加载此技能
|
||||
delegate_task(
|
||||
category: "visual-engineering",
|
||||
load_skills: ["pancli-design", "frontend-ui-ux"],
|
||||
description: "创建预算列表屏幕设计",
|
||||
prompt: `
|
||||
任务: 为 EmailBill 应用创建移动端预算列表屏幕设计
|
||||
|
||||
预期结果:
|
||||
- 375x812px 亮色主题设计
|
||||
- 暗色主题变体 (复制并适配)
|
||||
- 可复用的 BudgetCard 组件
|
||||
- 两种主题的截图验证
|
||||
|
||||
必需工具:
|
||||
- pencil_get_style_guide_tags
|
||||
- pencil_get_style_guide
|
||||
- pencil_batch_design
|
||||
- pencil_batch_get
|
||||
- pencil_replace_all_matching_properties
|
||||
- pencil_get_screenshot
|
||||
|
||||
必须做:
|
||||
- 严格遵循 pancli-design 技能指南
|
||||
- 使用真实中文业务术语 (预算, 账单, 分类)
|
||||
- 创建亮色和暗色两种主题
|
||||
- 使用 8px 网格间距系统
|
||||
- 遵循 Vant UI 组件模式
|
||||
- 使用 模块-屏幕-变体 格式命名帧
|
||||
- 使用语义颜色变量
|
||||
- 数字显示应用 DIN Alternate
|
||||
- 导航栏背景必须设置为透明 (:deep(.van-nav-bar) { background: transparent !important; })
|
||||
- 截图验证
|
||||
|
||||
不得做:
|
||||
- 使用 Lorem Ipsum 或占位文本
|
||||
- 只创建亮色主题没有暗色变体
|
||||
- 使用任意间距 (必须遵循 8px 网格)
|
||||
- 硬编码颜色 (使用语义变量)
|
||||
- 使用通用 "Dashboard" 标签
|
||||
- 跳过截图验证
|
||||
- 创建名为 "Frame_1", "Copy" 等的帧
|
||||
|
||||
上下文:
|
||||
- 移动视口: 375px 宽度
|
||||
- 设计系统: 基于 Vant UI
|
||||
- 配色方案: #1989fa 主色, #ee0a24 危险, #07c160 成功
|
||||
- 字体: 中文系统默认, 数字 DIN Alternate
|
||||
- designs/emailbill.pen 中的现有组件 (用 batch_get 检查)
|
||||
`,
|
||||
run_in_background: false
|
||||
)
|
||||
```
|
||||
|
||||
## 快速参考
|
||||
|
||||
**颜色面板 (基于实际 v2.pen 设计):**
|
||||
|
||||
| 名称 | 亮色 | 暗色 | 用途 |
|
||||
|------|------|------|------|
|
||||
| 页面背景 | #FFFFFF | #09090B | 页面背景 |
|
||||
| 卡片背景 | #F6F7F8 | #18181B | 卡片表面 |
|
||||
| 强调背景 | #F5F5F5 | #27272A | 按钮, 图标容器 |
|
||||
| 主文本 | #1A1A1A | #F4F4F5 | 主要文本 |
|
||||
| 次要文本 | #6B7280 | #A1A1AA | 次要文本 |
|
||||
| 三级文本 | #9CA3AF | #71717A | 三级文本 |
|
||||
| 主色 | #3B82F6 | #3B82F6 | 操作, FAB |
|
||||
| 红色 | #FF6B6B | #FF6B6B | 支出, 警告 |
|
||||
| 黄色 | #FCD34D | #FCD34D | 警告 |
|
||||
| 绿色 | #F0FDF4 | #064E3B | 收入标签 |
|
||||
| 蓝色 | #E0E7FF | #312E81 | 信息标签 |
|
||||
|
||||
**排版比例:**
|
||||
|
||||
| 用途 | 字体 | 大小 | 粗细 |
|
||||
|------|------|------|------|
|
||||
| 大数值 | Bricolage Grotesque | 32px | 800 |
|
||||
| 页面标题 | DM Sans | 24px | 500 |
|
||||
| 章节标题 | Bricolage Grotesque | 18px | 700 |
|
||||
| 正文 | DM Sans | 15px | 600 |
|
||||
| 说明 | DM Sans | 13px | 500 |
|
||||
| 微型标签 | DM Sans | 12px | 600 |
|
||||
|
||||
**组件规格:**
|
||||
|
||||
- **容器内边距**: 24px (主区域), 20px (卡片), 16px (小卡片)
|
||||
- **间距比例**: 2px, 4px, 8px, 12px, 14px, 16px
|
||||
- **圆角**: 12px (标签), 16px/20px (卡片), 22px/28px (圆形按钮)
|
||||
- **图标**: 20px
|
||||
- **图标按钮**: 44x44px
|
||||
- **FAB 按钮**: 56x56px
|
||||
- **触摸目标**: 最小 44x44px
|
||||
- **设计视口**: 402px 宽度
|
||||
|
||||
---
|
||||
|
||||
**版本:** 2.0.0
|
||||
**最后更新:** 2026-02-04
|
||||
**维护者:** EmailBill 设计团队
|
||||
1197
.opencode/skills/pancli-implement/SKILL.cn.md
Normal file
1197
.opencode/skills/pancli-implement/SKILL.cn.md
Normal file
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user