npx skills add https://github.com/aakash-dhar/claude-skills --skill scope-check进行范围检查时,请遵循此结构化流程。目标是在团队承诺之前,抓住那些让“2周项目”变成“3个月噩梦”的因素。
重要提示:始终将输出保存为项目根目录下 project-decisions/ 目录中的 Markdown 文件。如果目录不存在,请创建它。
# 如果 project-decisions 目录不存在,则创建它
mkdir -p project-decisions
# 文件将保存为:
# project-decisions/YYYY-MM-DD-scope-[kebab-case-topic].md
从规范、工单、PRD 或对话中,识别:
# 检查受影响区域当前系统的工作方式
grep -rn "[feature-keyword]" --include="*.ts" --include="*.js" --include="*.py" src/ app/ 2>/dev/null | grep -v "node_modules\|\.git\|test\|spec" | head -30
# 检查该区域的现有模型/模式
grep -rn "interface\|type\|class\|model\|schema" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -i "[keyword]"
# 检查该区域的现有 API 端点
grep -rn "router\.\|app\.\(get\|post\|put\|delete\)\|@app\.route\|@GetMapping" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ 2>/dev/null | grep -i "[keyword]"
# 检查该区域的现有测试
find . -name "*.test.*" -o -name "*.spec.*" -o -name "test_*" | xargs grep -l "[keyword]" 2>/dev/null
# 检查类似的过去功能(它们花了多长时间?)
git log --oneline --all --grep="[keyword]" | head -10
# 检查相关的 TODO/FIXME
grep -rn "TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -i "[keyword]"
# 检查该区域的技术债务
wc -l $(grep -rln "[keyword]" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | head -10) 2>/dev/null
When checking scope, follow this structured process. The goal is to catch the things that make a "2-week project" turn into a "3-month nightmare" — before the team commits.
IMPORTANT : Always save the output as a markdown file in the project-decisions/ directory at the project root. Create the directory if it doesn't exist.
# Create project-decisions directory if it doesn't exist
mkdir -p project-decisions
# File will be saved as:
# project-decisions/YYYY-MM-DD-scope-[kebab-case-topic].md
From the spec, ticket, PRD, or conversation, identify:
# Check how the current system works in the affected area
grep -rn "[feature-keyword]" --include="*.ts" --include="*.js" --include="*.py" src/ app/ 2>/dev/null | grep -v "node_modules\|\.git\|test\|spec" | head -30
# Check existing models/schemas in the area
grep -rn "interface\|type\|class\|model\|schema" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -i "[keyword]"
# Check existing API endpoints in the area
grep -rn "router\.\|app\.\(get\|post\|put\|delete\)\|@app\.route\|@GetMapping" --include="*.ts" --include="*.js" --include="*.py" --include="*.java" src/ 2>/dev/null | grep -i "[keyword]"
# Check existing tests in the area
find . -name "*.test.*" -o -name "*.spec.*" -o -name "test_*" | xargs grep -l "[keyword]" 2>/dev/null
# Check for similar past features (how long did they take?)
git log --oneline --all --grep="[keyword]" | head -10
# Check for related TODOs/FIXMEs
grep -rn "TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | grep -i "[keyword]"
# Check for tech debt in the area
wc -l $(grep -rln "[keyword]" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | head -10) 2>/dev/null
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
扫描规范中暗示隐藏复杂性的语言和模式:
标记这些短语:
- "简单" / "只是" / "快速" / "容易"
→ 规范中的"只是"一词是范围蔓延的头号预测指标
→ "只是添加一个按钮..." 隐藏了所有后端逻辑
- "类似于 [复杂产品]"
→ "像 Slack 但用于 X" 是 5 年的工程工作
→ 始终要问:该产品的哪个具体功能?
- "以及随之而来的一切"
→ 无限制的范围 —— "一切"是什么意思?
- "应该像现在一样工作,但同时还要..."
→ 向后兼容性 + 新行为 = 双倍工作量
- "用户应该能够..." (未指定是哪些用户)
→ 所有用户?管理员?免费层?付费层?每个都是不同的范围
- "支持 [开放式列表]"
→ "支持多种支付提供商" = 多少个?哪些?每个都是独立的集成
当规范未提及以下内容时标记:
- 出错时会发生什么?
- 空/空数据时会发生什么?
- 非常大的数据集时会发生什么?
- 用户离线时会发生什么?
- 超时时会发生什么?
- 并发时会发生什么?
- 用户返回/刷新时会发生什么?
- 现有数据怎么办?(需要迁移吗?)
- 国际化怎么办?
- 可访问性怎么办?
- 移动端/响应式怎么办?
规范说: 但实际上需要:
───────────────────────── ────────────────────────────────────
"添加搜索" 全文搜索引擎、索引、
排名、过滤器、分页、
高亮显示、拼写容错
"添加通知" 通知服务、交付
渠道(电子邮件、短信、推送)、
偏好设置、模板、调度、
退订、速率限制
"添加用户角色" 权限系统、角色管理界面、
现有用户的迁移、审计
跟踪、测试每个端点
"添加文件上传" 存储服务、病毒扫描、
文件类型验证、大小限制、
缩略图、CDN、清理/删除
"添加支付" 支付提供商集成、PCI
合规性、Webhook、重试逻辑、
退款、发票、税费计算
"添加实时更新" WebSocket 基础设施、连接
管理、重新连接、状态同步、
使用发布/订阅进行水平扩展
"添加管理面板" 每个实体的 CRUD、审计日志、
基于角色的访问、批量操作、
导出、仪表板、搜索/过滤
"添加多租户" 数据隔离、所有地方的租户感知查询、
租户管理、按租户计费、
防止跨租户访问
"添加 SSO/SAML" SAML/OIDC 集成、身份
提供商配置界面、JIT 配置、
会话管理、注销传播
"使其离线工作" 本地数据库、同步引擎、冲突
解决、待处理操作队列、
重试逻辑、缓存失效
当规范说以下内容时标记:
- "通常的流程" → 哪个流程?请记录
- "适当地处理错误" → 具体是什么?显示给用户?重试?记录日志?
- "响应式设计" → 移动端?平板电脑?哪些断点?不同的布局?
- "良好的性能" → 目标是什么?<200ms?<1s?在什么负载下?
- "安全" → 防止什么?XSS?CSRF?注入?身份验证绕过?
- "漂亮的用户界面" → 设计稿在哪里?没有设计稿 = 设计工作未包含在内
- "与 X 集成" → 哪个 API?哪个版本?有文档吗?
- "导出功能" → 什么格式?CSV?PDF?Excel?全部都要?
- "审计跟踪" → 哪些事件?保留多长时间?谁可以查看?
- "可配置" → 由谁配置?管理界面?配置文件?环境变量?
如果规范未涉及以下内容,请标记:
- 身份验证 → 谁可以访问这个?
- 授权 → 需要什么权限?
- 日志记录 → 为了调试应该记录什么?
- 监控 → 如果失败,应该触发什么警报?
- 速率限制 → 这个会被滥用吗?
- 缓存 → 这个需要缓存来提高性能吗?
- 数据验证 → 需要什么输入验证?
- 错误处理 → 错误用户体验是什么?
- 迁移 → 现有数据/用户怎么办?
- 文档 → API 文档?用户文档?内部文档?
- 测试策略 → 单元测试?集成测试?端到端测试?手动测试?
- 部署计划 → 功能标志?逐步推出?
- 回滚计划 → 如果需要回滚怎么办?
当功能需要以下内容时标记:
- 尚未开始的设计工作
- 另一个团队尚未提供的 API
- 第三方服务评估或合同
- 基础设施配置(新数据库、队列等)
- 数据迁移或回填
- 法律/合规审查
- 外部合作伙伴协调
- 新的环境变量或密钥
- CI/CD 流水线变更
- 文案/文本未最终确定(变更 = 返工)
- 未定义成功指标(我们怎么知道它在工作?)
- 没有验收标准(我们怎么知道它完成了?)
- 没有范围外部分(这是范围蔓延的邀请)
- 没有需求优先级排序(一切都感觉是 P0)
- 没有用户研究支持该功能(构建错误东西的风险)
将规范分解为具体的工作流并标记复杂性:
| 工作流 | 规定范围 | 隐藏范围 | 复杂性 |
|-------------|-------------|-------------|------------|
| 后端 API | 2 个新端点 | + 验证、错误处理、速率限制、身份验证检查、日志记录 | 中等 → 大 |
| 数据库 | 1 个新表 | + 迁移、索引、现有数据回填、与另外 3 个表的关系 | 小 → 中等 |
| 前端用户界面 | 1 个新页面 | + 表单验证、加载状态、错误状态、空状态、移动端响应式、可访问性 | 中等 → 大 |
| 集成 | 连接到 Stripe | + Webhook 处理、重试逻辑、幂等性、测试模式、错误映射、PCI 合规性审查 | 中等 → 非常大 |
| 测试 | "添加测试" | + 单元测试、集成测试、端到端测试、模拟外部服务、测试数据设置 | 中等 |
| 部署 | 未提及 | 功能标志、迁移脚本、环境变量、监控仪表板、回滚计划 | 小 → 中等 |
| 文档 | 未提及 | API 文档、README 更新、操作手册、用户指南 | 小 |
根据规范中缺失的内容应用乘数:
规范中的基础估算: 5 天
乘数:
× 1.0 清晰、详细的规范,带有设计稿 (罕见)
× 1.3 规范存在但缺少边界情况 (常见)
× 1.5 模糊的规范,"你懂我的意思" (常见)
× 2.0 一行工单,根本没有规范 (太常见)
× 1.2 团队之前做过类似的工作
× 1.5 团队有部分经验
× 2.0 团队完全陌生的领域
× 1.0 没有外部依赖项
× 1.3 一个外部依赖项
× 1.5 多个外部依赖项
× 2.0 没有文档的外部依赖项
× 1.0 没有数据库变更
× 1.3 增量的数据库变更
× 1.5 需要迁移的数据库变更
× 2.0 需要大量数据回填的数据库变更
× 1.0 没有破坏性变更
× 1.5 有已知消费者的破坏性变更
× 2.0 有未知消费者的破坏性变更
调整后的估算:基础 × (适用乘数的乘积)
评估整体复杂性:
| 因素 | 评分 (1-5) | 备注 |
|--------|-------------|-------|
| 需求清晰度 | X | [规范有多清晰?] |
| 技术复杂性 | X | [实现有多困难?] |
| 集成复杂性 | X | [有多少外部接触点?] |
| 数据复杂性 | X | [模式变更、迁移、数据质量?] |
| 用户体验复杂性 | X | [有多少状态、流程、边界情况?] |
| 测试复杂性 | X | [验证有多困难?] |
| 部署复杂性 | X | [特殊的推出需求?] |
| 依赖项风险 | X | [外部阻塞因素?] |
| 团队熟悉度 | X | [团队以前做过这个吗?] |
| 利益相关者一致性 | X | [每个人都达成共识了吗?] |
平均分:X.X / 5
1.0-2.0: 直接明了 —— 估算可能是正确的
2.1-3.0: 中等 —— 增加 30% 缓冲
3.1-4.0: 复杂 —— 增加 50-100% 缓冲,考虑分解
4.1-5.0: 非常复杂 —— 在承诺之前需要技术探索、分解或缩减范围
列出规范中明确说明的假设:
1. [来自规范的假设]
2. [来自规范的假设]
列出规范未说明但依赖的假设:
1. [假设 X 已经就位 —— 是吗?]
2. [假设团队有容量 —— 有吗?]
3. [假设 API 是稳定的 —— 是吗?]
4. [假设设计已定稿 —— 是吗?]
5. [假设数据是干净的 —— 是吗?]
6. [假设没有破坏性变更 —— 真的吗?]
7. [假设在移动端行为相同 —— 确认了吗?]
8. [假设现有身份验证覆盖了这个 —— 是吗?]
| 假设 | 如果错误,影响 | 错误可能性 | 行动 |
|-----------|-----------------|------------------|--------|
| [假设 1] | +X 天 | 高/中/低 | [如何验证] |
| [假设 2] | +X 天 | 高/中/低 | [如何验证] |
| [假设 3] | 阻塞项 | 高/中/低 | [如何验证] |
如果范围太大,建议如何削减:
必须有 (P0) —— 没有这些就无法发布
- [需求 1] —— [为什么它是必需的]
- [需求 2] —— [为什么它是必需的]
应该有 (P1) —— 重要但可以在没有的情况下发布
- [需求 3] —— [可以在 v1.1 中跟进]
- [需求 4] —— [可以在 v1.1 中跟进]
可以有 (P2) —— 锦上添花
- [需求 5] —— [未来增强]
- [需求 6] —— [未来增强]
这次不会有 —— 明确排除在范围外
- [需求 7] —— [为什么削减,何时重新审视]
- [需求 8] —— [为什么削减,何时重新审视]
阶段 1: 最小可行产品 (冲刺 1-2)
- [仅核心功能]
- [仅成功路径]
- [单一用例]
- 估算:X 天
阶段 2: 加固 (冲刺 3)
- [错误处理]
- [边界情况]
- [性能优化]
- 估算:X 天
阶段 3: 完善 (冲刺 4)
- [附加用例]
- [锦上添花的功能]
- [高级功能]
- 估算:X 天
| 需求 | 削减? | 节省 | 权衡 |
|-------------|------|---------|-----------|
| [功能 A] | 推迟到阶段 2 | 3 天 | 用户暂时使用变通方案 |
| [功能 B] | 简化 | 2 天 | 手动代替自动化 |
| [功能 C] | 移除 | 5 天 | 最小可行产品验证不需要 |
| [功能 D] | 保留 | 0 | 核心需求,不能削减 |
生成在团队承诺此范围之前应回答的问题列表:
## 需要解决的问题
### 需求问题
1. [关于不明确需求的具体问题]
2. [关于缺失行为的具体问题]
3. [关于边界情况的具体问题]
### 技术问题
4. [关于可行性的问题]
5. [关于集成的问题]
6. [关于数据迁移的问题]
### 设计问题
7. [关于缺失设计稿/流程的问题]
8. [关于移动端行为的问题]
9. [关于错误状态的问题]
### 业务问题
10. [关于优先级的问题]
11. [关于时间线灵活性的问题]
12. [关于成功指标的问题]
### 依赖项问题
13. [关于外部团队/服务的问题]
14. [关于被阻塞工作的问题]
保存到 project-decisions/YYYY-MM-DD-scope-[topic].md:
# 范围检查:[功能/工单标题]
**日期:** YYYY-MM-DD
**已审查的规范:** [指向规范/工单/PRD 的链接]
**审查人:** [姓名]
**规定估算:** [原始估算,如果有]
**调整后估算:** [范围检查后]
---
## 结论
**范围评估:** [🟢 现实 / 🟡 需要改进 / 🟠 显著低估范围 / 🔴 不现实]
**关键发现:** [一句话总结 —— 例如:"规范很好地覆盖了成功路径,但缺少身份验证、错误处理和移动端 —— 这大约使工作量翻倍。"]
---
## 发现的危险信号
### 🔴 关键(肯定会增加范围)
1. [危险信号,附解释和影响]
2. [危险信号,附解释和影响]
### 🟡 警告(可能增加范围)
3. [警告,附解释和影响]
4. [警告,附解释和影响]
### 🟢 次要(值得注意)
5. [次要信号]
6. [次要信号]
## 隐藏的复杂性
| 领域 | 规范说明 | 实际需要 | 额外工作量 |
|------|-------------------|--------------------------|-------------|
| [领域 1] | [规定范围] | [实际范围] | +X 天 |
| [领域 2] | [规定范围] | [实际范围] | +X 天 |
## 缺失的需求
[规范中未包含但完整实现所需的需求列表]
## 未说明的假设
[规范依赖但尚未验证的假设列表]
## 需要解决的问题
[在承诺之前必须回答的问题编号列表]
## 估算对比
| | 规定 | 调整后 | 备注 |
|--|--------|----------|-------|
| **总工作量** | X 天 | Y 天 | [为什么不同] |
| **复杂性** | [低/中/高] | [低/中/高] | [发生了什么变化] |
| **置信度** | — | [高/中/低] | [为什么是这个置信水平] |
| **冲刺适应性** | [Y 个冲刺] | [Z 个冲刺] | [含缓冲] |
## 范围缩减建议
### 如果需要适应原始时间线:
[要削减或推迟的内容]
### 分阶段交付建议:
[阶段 1 最小可行产品 → 阶段 2 加固 → 阶段 3 完善]
## 建议
**[按现状承诺 / 首先改进规范 / 缩减范围 / 先进行技术探索 / 拒绝时间线]**
[推理 —— 2-3 句话]
## 后续步骤
1. [ ] [行动项 —— 例如:"在冲刺计划前回答问题 1-5"]
2. [ ] [行动项 —— 例如:"获取移动端状态的设计稿"]
3. [ ] [行动项 —— 例如:"验证关于 API 可用性的假设"]
---
## 决策日志
| 日期 | 事件 | 执行人 |
|------|-------|----|
| YYYY-MM-DD | 请求范围检查 | [姓名] |
| YYYY-MM-DD | 分析完成 | [姓名] |
| YYYY-MM-DD | 问题已解决 | [姓名] |
| YYYY-MM-DD | 范围已批准/改进 | [姓名] |
保存后,更新 project-decisions 索引:
# 更新 README.md 索引
echo "# 项目决策\n" > project-decisions/README.md
echo "| 日期 | 决策 | 类型 | 状态 |" >> project-decisions/README.md
echo "|------|----------|------|--------|" >> project-decisions/README.md
for f in project-decisions/2*.md; do
date=$(basename "$f" | cut -d'-' -f1-3)
title=$(head -1 "$f" | sed 's/^# //' | sed 's/^Scope Check: //' | sed 's/^Impact Analysis: //' | sed 's/^Tech Decision: //')
type="其他"
echo "$f" | grep -q "scope" && type="范围检查"
echo "$f" | grep -q "impact" && type="影响分析"
echo "$f" | grep -q "tech-decision\|decision" && type="技术决策"
status=$(grep "^**Status:**\|^**Scope assessment:**\|^**Proceed:**" "$f" | head -1 | sed 's/.*: //' | sed 's/\*//g')
echo "| $date | [$title](./$(basename $f)) | $type | $status |" >> project-decisions/README.md
done
project-decisions/ 中每次范围检查结束时:
每周安装数
1
仓库
首次出现
1 天前
安全审计
安装于
zencoder1
amp1
cline1
openclaw1
opencode1
cursor1
Scan the spec for language and patterns that signal hidden complexity:
Flag these phrases:
- "Simple" / "Just" / "Quickly" / "Easy"
→ The word "just" in a spec is the #1 predictor of scope creep
→ "Just add a button that..." hides all the backend logic
- "Similar to [complex product]"
→ "Like Slack but for X" is 5 years of engineering
→ Always ask: which specific feature of that product?
- "And everything that goes with it"
→ Unbounded scope — what does "everything" mean?
- "Should work like it does now, but also..."
→ Backward compatibility + new behavior = double the work
- "Users should be able to..." (without specifying which users)
→ All users? Admins? Free tier? Paid? Each is different scope
- "Support for [open-ended list]"
→ "Support for multiple payment providers" = how many? Which ones? Each is a separate integration
Flag when the spec doesn't mention:
- What happens on error?
- What happens with empty/null data?
- What happens with very large data sets?
- What happens when the user is offline?
- What happens on timeout?
- What happens concurrently?
- What happens when the user goes back/refreshes?
- What about existing data? (migration needed?)
- What about internationalization?
- What about accessibility?
- What about mobile/responsive?
The spec says: But it actually requires:
───────────────────────── ────────────────────────────────────
"Add search" Full-text search engine, indexing,
ranking, filters, pagination,
highlighting, typo tolerance
"Add notifications" Notification service, delivery
channels (email, SMS, push),
preferences, templates, scheduling,
unsubscribe, rate limiting
"Add user roles" Permission system, role management UI,
migration of existing users, audit
trail, testing every endpoint
"Add file upload" Storage service, virus scanning,
file type validation, size limits,
thumbnails, CDN, cleanup/deletion
"Add payments" Payment provider integration, PCI
compliance, webhooks, retry logic,
refunds, invoicing, tax calculation
"Add real-time updates" WebSocket infrastructure, connection
management, reconnection, state sync,
horizontal scaling with pub/sub
"Add an admin panel" CRUD for every entity, audit logging,
role-based access, bulk operations,
export, dashboard, search/filter
"Add multi-tenancy" Data isolation, tenant-aware queries
everywhere, tenant management, billing
per tenant, cross-tenant prevention
"Add SSO/SAML" SAML/OIDC integration, identity
provider config UI, JIT provisioning,
session management, logout propagation
"Make it work offline" Local database, sync engine, conflict
resolution, queue for pending actions,
retry logic, cache invalidation
Flag when the spec says:
- "The usual flow" → Which flow? Document it
- "Handle errors appropriately" → What specifically? Show user? Retry? Log?
- "Responsive design" → Mobile? Tablet? Which breakpoints? Different layouts?
- "Good performance" → What's the target? <200ms? <1s? Under what load?
- "Secure" → Against what? XSS? CSRF? Injection? Auth bypass?
- "Nice UI" → Where are the mocks? No mocks = design work not included
- "Integration with X" → Which API? Which version? Is there documentation?
- "Export functionality" → What format? CSV? PDF? Excel? All of them?
- "Audit trail" → What events? How long to retain? Who can view?
- "Configurable" → By whom? Admin UI? Config file? Environment variable?
Flag if the spec doesn't address:
- Authentication → Who can access this?
- Authorization → What permissions are needed?
- Logging → What should be logged for debugging?
- Monitoring → What alerts should fire if this fails?
- Rate limiting → Can this be abused?
- Caching → Does this need caching for performance?
- Data validation → What input validation is needed?
- Error handling → What's the error UX?
- Migration → What happens to existing data/users?
- Documentation → API docs? User docs? Internal docs?
- Testing strategy → Unit? Integration? E2E? Manual?
- Deployment plan → Feature flag? Gradual rollout?
- Rollback plan → What if this needs to be reverted?
Flag when the feature requires:
- Design work that hasn't started
- API from another team that doesn't exist yet
- Third-party service evaluation or contract
- Infrastructure provisioning (new database, queue, etc.)
- Data migration or backfill
- Legal/compliance review
- External partner coordination
- New environment variables or secrets
- CI/CD pipeline changes
- Copy/text not finalized (changes = rework)
- No success metrics defined (how do we know it's working?)
- No acceptance criteria (how do we know it's done?)
- No out-of-scope section (invitation for scope creep)
- No priority ranking of requirements (everything feels P0)
- No user research backing the feature (building the wrong thing risk)
Break the spec into concrete work streams and flag complexity:
| Work Stream | Stated Scope | Hidden Scope | Complexity |
|-------------|-------------|-------------|------------|
| Backend API | 2 new endpoints | + validation, error handling, rate limiting, auth checks, logging | Medium → Large |
| Database | 1 new table | + migration, indexes, existing data backfill, relationships to 3 other tables | Small → Medium |
| Frontend UI | 1 new page | + form validation, loading states, error states, empty states, mobile responsive, accessibility | Medium → Large |
| Integration | Connect to Stripe | + webhook handling, retry logic, idempotency, test mode, error mapping, PCI compliance review | Medium → Very Large |
| Testing | "Add tests" | + unit, integration, e2e, mocking external services, test data setup | Medium |
| Deployment | Not mentioned | Feature flag, migration script, env vars, monitoring dashboard, rollback plan | Small → Medium |
| Documentation | Not mentioned | API docs, README update, runbook, user guide | Small |
Apply multipliers based on what's missing from the spec:
Base estimate from spec: 5 days
Multipliers:
× 1.0 Clear, detailed spec with mocks (rare)
× 1.3 Spec exists but missing edge cases (common)
× 1.5 Vague spec, "you know what I mean" (common)
× 2.0 One-liner ticket, no spec at all (too common)
× 1.2 Team has done similar work before
× 1.5 Team has partial experience
× 2.0 Completely new territory for the team
× 1.0 No external dependencies
× 1.3 One external dependency
× 1.5 Multiple external dependencies
× 2.0 External dependency with no documentation
× 1.0 No database changes
× 1.3 Additive database changes
× 1.5 Database changes with migration
× 2.0 Database changes with large data backfill
× 1.0 No breaking changes
× 1.5 Breaking changes with known consumers
× 2.0 Breaking changes with unknown consumers
Adjusted estimate: base × (product of applicable multipliers)
Rate the overall complexity:
| Factor | Score (1-5) | Notes |
|--------|-------------|-------|
| Requirements clarity | X | [how clear is the spec?] |
| Technical complexity | X | [how hard is the implementation?] |
| Integration complexity | X | [how many external touchpoints?] |
| Data complexity | X | [schema changes, migrations, data quality?] |
| UX complexity | X | [how many states, flows, edge cases?] |
| Testing complexity | X | [how hard to verify?] |
| Deployment complexity | X | [special rollout needs?] |
| Dependency risk | X | [external blockers?] |
| Team familiarity | X | [has team done this before?] |
| Stakeholder alignment | X | [is everyone on the same page?] |
Average: X.X / 5
1.0-2.0: Straightforward — estimate is probably right
2.1-3.0: Moderate — add 30% buffer
3.1-4.0: Complex — add 50-100% buffer, consider decomposition
4.1-5.0: Very Complex — needs spike, decomposition, or scope reduction before committing
List assumptions explicitly stated in the spec:
1. [Assumption from the spec]
2. [Assumption from the spec]
List assumptions the spec DOESN'T state but relies on:
1. [Assumed X is already in place — is it?]
2. [Assumed team has capacity — do they?]
3. [Assumed API is stable — is it?]
4. [Assumed design is finalized — is it?]
5. [Assumed data is clean — is it?]
6. [Assumed no breaking changes — really?]
7. [Assumed same behavior on mobile — confirmed?]
8. [Assumed existing auth covers this — does it?]
| Assumption | If Wrong, Impact | Likelihood Wrong | Action |
|-----------|-----------------|------------------|--------|
| [Assumption 1] | +X days | High/Med/Low | [Validate how] |
| [Assumption 2] | +X days | High/Med/Low | [Validate how] |
| [Assumption 3] | Blocker | High/Med/Low | [Validate how] |
If the scope is too large, suggest how to cut it down:
MUST HAVE (P0) — Ship doesn't sail without these
- [Requirement 1] — [why it's essential]
- [Requirement 2] — [why it's essential]
SHOULD HAVE (P1) — Important but can ship without
- [Requirement 3] — [can follow in v1.1]
- [Requirement 4] — [can follow in v1.1]
COULD HAVE (P2) — Nice to have
- [Requirement 5] — [future enhancement]
- [Requirement 6] — [future enhancement]
WON'T HAVE (this time) — Explicitly out of scope
- [Requirement 7] — [why it's cut, when to revisit]
- [Requirement 8] — [why it's cut, when to revisit]
Phase 1: MVP (Sprint 1-2)
- [Core functionality only]
- [Happy path only]
- [Single use case]
- Estimated: X days
Phase 2: Hardening (Sprint 3)
- [Error handling]
- [Edge cases]
- [Performance optimization]
- Estimated: X days
Phase 3: Polish (Sprint 4)
- [Additional use cases]
- [Nice-to-have features]
- [Advanced features]
- Estimated: X days
| Requirement | Cut? | Savings | Trade-off |
|-------------|------|---------|-----------|
| [Feature A] | Defer to Phase 2 | 3 days | Users use workaround for now |
| [Feature B] | Simplify | 2 days | Manual instead of automated |
| [Feature C] | Remove | 5 days | Not needed for MVP validation |
| [Feature D] | Keep | 0 | Core requirement, can't cut |
Generate a list of questions that should be answered before the team commits to this scope:
## Questions to Resolve
### Requirements Questions
1. [Specific question about unclear requirement]
2. [Specific question about missing behavior]
3. [Specific question about edge case]
### Technical Questions
4. [Question about feasibility]
5. [Question about integration]
6. [Question about data migration]
### Design Questions
7. [Question about missing mock/flow]
8. [Question about mobile behavior]
9. [Question about error states]
### Business Questions
10. [Question about priority]
11. [Question about timeline flexibility]
12. [Question about success metrics]
### Dependency Questions
13. [Question about external team/service]
14. [Question about blocked work]
Save to project-decisions/YYYY-MM-DD-scope-[topic].md:
# Scope Check: [Feature/Ticket Title]
**Date:** YYYY-MM-DD
**Spec reviewed:** [Link to spec/ticket/PRD]
**Reviewed by:** [Name]
**Stated estimate:** [Original estimate if any]
**Adjusted estimate:** [After scope check]
---
## Verdict
**Scope assessment: [🟢 Realistic / 🟡 Needs Refinement / 🟠 Significantly Underscoped / 🔴 Unrealistic]**
**Key finding:** [One sentence summary — e.g., "The spec covers the happy path well but misses
authentication, error handling, and mobile — which roughly doubles the effort."]
---
## Red Flags Found
### 🔴 Critical (will definitely increase scope)
1. [Red flag with explanation and impact]
2. [Red flag with explanation and impact]
### 🟡 Warning (likely to increase scope)
3. [Warning with explanation and impact]
4. [Warning with explanation and impact]
### 🟢 Minor (worth noting)
5. [Minor flag]
6. [Minor flag]
## Hidden Complexity
| Area | What the Spec Says | What It Actually Requires | Extra Effort |
|------|-------------------|--------------------------|-------------|
| [Area 1] | [Stated scope] | [Real scope] | +X days |
| [Area 2] | [Stated scope] | [Real scope] | +X days |
## Missing Requirements
[List of requirements not in the spec but needed for a complete implementation]
## Unstated Assumptions
[List of assumptions the spec relies on that haven't been validated]
## Questions to Resolve
[Numbered list of questions that must be answered before committing]
## Estimate Comparison
| | Stated | Adjusted | Notes |
|--|--------|----------|-------|
| **Total effort** | X days | Y days | [why it's different] |
| **Complexity** | [Low/Med/High] | [Low/Med/High] | [what changed] |
| **Confidence** | — | [High/Med/Low] | [why this confidence level] |
| **Sprint fit** | [Y sprints] | [Z sprints] | [with buffer] |
## Scope Reduction Recommendations
### If we need to fit the original timeline:
[What to cut or defer]
### Phased delivery suggestion:
[Phase 1 MVP → Phase 2 Hardening → Phase 3 Polish]
## Recommendation
**[Commit as-is / Refine spec first / Reduce scope / Spike first / Reject timeline]**
[Reasoning — 2-3 sentences]
## Next Steps
1. [ ] [Action item — e.g., "Answer questions 1-5 before sprint planning"]
2. [ ] [Action item — e.g., "Get design mocks for mobile states"]
3. [ ] [Action item — e.g., "Validate assumption about API availability"]
---
## Decision Log
| Date | Event | By |
|------|-------|----|
| YYYY-MM-DD | Scope check requested | [Name] |
| YYYY-MM-DD | Analysis completed | [Name] |
| YYYY-MM-DD | Questions resolved | [Name] |
| YYYY-MM-DD | Scope approved / refined | [Name] |
After saving, update the project-decisions index:
# Update README.md index
echo "# Project Decisions\n" > project-decisions/README.md
echo "| Date | Decision | Type | Status |" >> project-decisions/README.md
echo "|------|----------|------|--------|" >> project-decisions/README.md
for f in project-decisions/2*.md; do
date=$(basename "$f" | cut -d'-' -f1-3)
title=$(head -1 "$f" | sed 's/^# //' | sed 's/^Scope Check: //' | sed 's/^Impact Analysis: //' | sed 's/^Tech Decision: //')
type="Other"
echo "$f" | grep -q "scope" && type="Scope Check"
echo "$f" | grep -q "impact" && type="Impact Analysis"
echo "$f" | grep -q "tech-decision\|decision" && type="Tech Decision"
status=$(grep "^**Status:**\|^**Scope assessment:**\|^**Proceed:**" "$f" | head -1 | sed 's/.*: //' | sed 's/\*//g')
echo "| $date | [$title](./$(basename $f)) | $type | $status |" >> project-decisions/README.md
done
project-decisions/End every scope check with:
Weekly Installs
1
Repository
First Seen
1 day ago
Security Audits
Installed on
zencoder1
amp1
cline1
openclaw1
opencode1
cursor1
开源项目教练指南 - 诊断问题、制定行动计划、优化开源项目运营
29,800 周安装
specalign规范对齐工具:自动检测代码与文档差异,确保开发一致性
59 周安装
Azure PostgreSQL TypeScript 技能 - 云数据库开发与部署解决方案
1 周安装
Azure Monitor Query Python 库 - 高效查询 Azure 监控日志与指标数据
1 周安装
data-driven-testing 测试技能已弃用 | 测试最佳实践替代方案 | 0xbigboss/claude-code
59 周安装
Azure Monitor OpenTelemetry Exporter for Java - 监控Java应用性能的官方导出工具
1 周安装
1Password CLI安全使用指南:op-cli命令最佳实践与密钥管理技巧
63 周安装