需求值得被认真理解，实现不需要被流程接管。
面向强编码 Agent 的轻量开发闭环：先聊透，再实现，用证据收尾。
v0.8.0 ISSUE-DRIVEN EVIDENCE-BACKED LESS CEREMONY
Thinloop 不接管开发过程，只守住容易在长任务里丢失的结果：
需求不被误解，体验与架构有据可循，完成声明有真实证据，仓库漂移能被主动发现。
大多数开发任务只需要调用 scd-quickdev 并说明目标：
使用 scd-quickdev 修复登录后偶发白屏，并补回归验证。
使用 scd-quickdev 增加 CSV 导出，完成后提 PR 并合并 main。
QuickDev 会先判断任务是否足够清楚，而不是要求用户选择流程：
| 当前情况 | 默认路径 |
|---|---|
| Bug 或清晰、局部的新功能 | 建立或确认 Issue，直接诊断、实现和验证 |
| 多个产品决定仍未明确 | 调用 Discovery 逐项澄清，批准后把结论写入 Issue |
| 一个项目包含多个可独立验收的交付 | 调用 Project 拆成 Initiative、Delivery Issues 和依赖图 |
| UI 或系统边界会显著影响实现 | 按需组合 UIUX 或 Architecture |
| 工程验证通过 | Agent 自审、提交、推送、提 PR，并在工程闸门通过后合并 |
| 工程验证完成 | 独立验收 Agent 按需执行真实环境验证，只在 PASS 后关闭 Issue |
| 生产部署、认证支付、破坏性数据等高风险工作 | 在高风险动作前停下并请求明确批准 |
GitHub Issue 仍是需求和验收真值源：单交付由一个 Delivery Issue 负责；多交付 项目由 Initiative 负责项目拓扑、各 Delivery Issue 负责自身切片。PR 是实现 证据、工程审阅和回滚边界。简单任务不会先写本地 Spec，也不强制创建 worktree。
把模糊想法收敛为明确批准、可以验收的 GitHub Issue。 适合：新产品、复杂功能、多个产品决定相互依赖。 |
把稳定的产品行为设计成可审阅、可实现的 Web 体验。 适合：复杂用户流、页面状态、交互与视觉设计。 |
把产品行为翻译为领域、系统边界和共享机器契约。 适合：新系统、公共接口和高影响技术边界。 |
把多交付项目拆成 Initiative、独立 Issue 和可验证依赖图。 适合：多个交付切片、跨 Issue 前置依赖和集成闸门。 |
从 Issue 开始完成诊断、开发、验证、PR 和可自动合并的交付。 适合：Bug、清晰功能、已批准 Issue 和跨会话实现。 |
把已证实的开发经验沉淀为短知识，并在需要时找回。 适合：主动沉淀、查找或维护开发经验。 |
主动审计并小批修复技术债和代码—文档漂移。 适合：主动扫描、清理、对齐或维护现有仓库。 |
从一次开发互动中诊断 Skill 问题，经用户批准后做可回滚试验。 适合：主动复盘并优化本次真正使用过的 Thinloop Skill。 |
能力卡直达各 Skill 的权威说明；更细的契约和模板沿其
Resources按需读取，不在 README 重复维护。
清晰任务直接开发；不清晰的需求先讨论；多交付项目才增加 Project 拆解。默认不强制 TDD、角色系统、额外子代理、固定阶段或本地 Spec；Project 不执行工程 loop， QuickDev 只固定使用一个独立验收 Agent。完整的路由、状态与契约说明见 工作流与项目状态。
每张图只保留该 Skill 的五个关键节点；完整触发条件、分支和安全边界仍以对应
SKILL.md 为准。
| 文档 | 内容 |
|---|---|
| 工作流与项目状态 | 路由原则、Issue/PR 边界、最小状态与契约入口 |
| 安装与更新指南 | 五类 Agent 的安装、升级、调用与 Evolve 源码配置 |
| 验证指南 | 仓库校验命令、各 Agent 的运行时证据与已知边界 |
| 评测说明 | 评测方法、历史证据与限制 |
DEEPER UNDERSTANDING · LESS CEREMONY · STRONGER EVIDENCE
MIT License · 2026 mindcarver