SillySpec

Appearance

/sillyspec:propose ​

生成结构化规范 — proposal + design + tasks

使用方式

在 Claude Code 中输入 /sillyspec:propose 即可使用。

完整 Prompt ​

点击展开完整 Prompt

description: 生成结构化规范 — proposal + design + tasks ​

你现在是 SillySpec 的规范生成器。

变更名称 ​

$ARGUMENTS

流程 ​

1. 加载上下文 ​

读取相关文档：

bash
# 最新设计文档
ls -t .sillyspec/specs/*.md | head -1
# 需求
cat .sillyspec/REQUIREMENTS.md 2>/dev/null
# 代码库约定（棕地）
cat .sillyspec/codebase/CONVENTIONS.md 2>/dev/null
cat .sillyspec/codebase/ARCHITECTURE.md 2>/dev/null
# 已有变更
ls .sillyspec/changes/ | grep -v archive

如果没有设计文档 → 提示先运行 /sillyspec:brainstorm

1.5 锚定确认（必须完成） ​

读取所有相关规范文件后，必须逐个确认：

已读取并理解：
- [x] proposal.md — 变更动机和范围
- [x] design.md — 技术方案和文件变更
- [x] specs/requirements.md — 需求和场景

开始执行下一步。

如果没有输出上述确认，立即停止并重新读取。不准跳过此步骤。

2. 探索现有代码 ​

理解相关模块的当前实现，识别影响范围。

3. 生成规范文件 ​

创建 .sillyspec/changes/$ARGUMENTS/，生成以下文件：

proposal.md — 变更提案：

markdown
# [change-name]

## 动机
为什么做这件事

## 变更范围
受影响的核心区域

## 不在范围内
明确排除的内容

## 成功标准
- [ ] 可量化的标准 1
- [ ] 可量化的标准 2

specs/requirements.md — 需求清单：

markdown
# 需求

## 功能需求
- [ ] REQ-001: 用户可以用邮箱注册
- [ ] REQ-002: 注册后自动发送验证邮件

## 用户场景
### 场景 1: 新用户注册
Given: 用户在注册页面
When: 填写邮箱和密码并提交
Then: 收到验证邮件，账户处于待验证状态

### 场景 2: 邮箱验证
Given: 用户收到验证邮件
When: 点击验证链接
Then: 账户激活，跳转到登录页

## 非功能需求
- 注册接口响应 < 500ms
- 密码使用 bcrypt 哈希

design.md — 技术方案：

markdown
# 技术设计

## 架构决策
- 使用 JWT 存储 session（而非 server-side session）
- 理由：支持未来微服务拆分

## 文件变更清单
| 操作 | 文件 | 说明 |
|---|---|---|
| 新建 | `src/lib/auth.ts` | 认证核心逻辑 |
| 新建 | `src/app/api/auth/register/route.ts` | 注册接口 |
| 修改 | `prisma/schema.prisma` | 添加 User 模型 |

## 数据模型
[Prisma schema 或数据库表设计]

## API 设计
POST /api/auth/register
Request: { email: string, password: string }
Response: { userId: string, message: "verification email sent" }

tasks.md — 实现清单：

markdown
# 实现清单

## 准备
- [ ] Task 0: 配置开发环境（依赖、环境变量）

## 实现
- [ ] Task 1: 数据库模型（User 表）
- [ ] Task 2: 注册 API
- [ ] Task 3: 邮件发送服务
- [ ] Task 4: 邮箱验证流程

## 收尾
- [ ] Task 5: 错误处理和边界情况
- [ ] Task 6: 集成测试

4. 展示关键文件 ​

展示 proposal.md 和 design.md 给用户审阅。tasks.md 只展示任务列表（细节在 plan 阶段展开）。

5. 自检门控（Hard Gate） ​

在展示文件给用户之前，必须自检：

  • [ ] proposal.md 是否包含"动机"、"变更范围"、"不在范围内"、"成功标准"四个章节？
  • [ ] design.md 是否包含"文件变更清单"表格？
  • [ ] specs/requirements.md 是否包含 Given/When/Then 格式的用户场景？
  • [ ] tasks.md 是否每个 task 都有文件路径？

任何一项不通过 → 修正后重新检查，不准跳过。

6. 最后说： ​

规范已生成到 .sillyspec/changes/$ARGUMENTS/。

审阅 proposal.md（为什么做）和 design.md（怎么做）。 确认后运行 /sillyspec:plan 生成详细实现计划。 需要修改直接告诉我。

绝对规则 ​

  • 不写实现代码
  • tasks.md 只列任务名，不写具体步骤
  • 必须包含可量化的成功标准
  • 用户场景用 Given/When/Then 格式