flamemida/spec-dev
设计→计划→执行 skill 管线与全能验收
对功能、页面或接口执行矩阵驱动的验收，以及交互、渲染和性能故障诊断。适用于 E2E、视觉、可访问性及性能验收；不用于日常跑测试、开发中 TDD、代码或需求文档审查。
实时网页搜索、垂直领域检索、并行批量检索与 URL 正文抽取（内嵌 CLI、无需 MCP）。当需要联网搜索、查库/框架文档与最新实践、核实时效信息、多主题批量调研或抽取网页正文时使用；搜索首选入口，不可用时才降级 WebSearch/WebFetch。
共享澄清纪律（grill 式）——沿决策树一次一题逼近共识：事实自查、每个决策带推荐交用户裁决；独立会话以共识摘要 + 三出口收束（转主流程/就此结束/写入 md），不强制产出。被 requirement-analysis 与 quick-fix 引用作提问纪律。当用户想把一个想法/计划/决定逐题磨清楚时独立使用；发散式的思考陪伴用 exploring；已承诺交付的开发工作直接用 requirement-analysis / quick-fix。
DDD 全流程开发规范(语言无关):从零搭建工程的领域建模、六边形架构落地,与开发过程中的 DDD 抉择判断。当用户要开始新项目或新模块的领域建模、建立或维护统一语言(spec-dev 词汇表)、划分限界上下文(context mapping)、定义实体/值对象/聚合、设计领域事件与仓储、搭建分层/端口适配器(六边形)架构、判断某决策是否值得写 ADR、或需要评审领域模型质量(10 分制评分)时使用。适用于任何编程语言与框架。
执行已批准的书面实施计划，默认按依赖图并发派发就绪任务，支持持续补位、中断恢复、审查与交付。遵从明确串行要求，依赖或资源受限时顺序推进，不用于无计划的即兴修改。
陪伴尚未决定实施的想法探索：理解代码、比较方向，按授权进行受控实验。结晶后交接正式设计；不用于已承诺的功能实施、已决定的小修或单点事实问答。
轻量 bug 修复工作流——已决定要修、无设计空间的小修复时使用：先按证据定位根因（含 spec 反查），逐题校对，沿获批落点 TDD 修复，可选验收。跨 spec 契约、跨模块、新依赖、现行契约冲突或诊断证据不足时提议升级 requirement-analysis；偶发但可比较可继续。新功能、有设计空间的需求用 requirement-analysis；未决定要不要做用 exploring。
将已承诺且有设计空间的开发需求转化为获批 spec，再交接计划编写。适用于新功能、API、数据及行为设计；未定想法用 exploring，无设计空间小修用 quick-fix，纯问答或日常测试不适用。
通过结构化的逐步思考解决复杂问题，支持分支探索、修订和自适应深度。适用于复杂问题拆解、需要调整的规划与设计、可能修正方向的分析、初始范围不明的任务、需要保持上下文的多步骤工作，以及需要筛选无关信息、提出假设并反复验证的问题。当用户要求逐步分析、拆解问题、推敲思路、仔细思考，或问题明显需要结构化多步推理时使用。
测试驱动开发纪律——实现功能、修复 bug 或改变行为前，沿已批准的公共测试落点先写失败测试，确认有效红后最小实现转绿。批准的前置或收尾纯重构用行为测试保绿。例外按单点清单与可追溯授权处理。
测试策略纪律——按本地执行时点的三 Lane 调度（fast/final/manual）、治理顺序 flaky→时长→选择、AI Agent 模型边界测试骨架、验收矩阵对接。为 spec 设计测试与验收策略、把验收矩阵翻译为计划任务、或为项目搭测试分层时使用。
隔离工作区——开始需要与当前工作区隔离的功能开发、或执行实施计划之前使用。先检测已有隔离，优先平台原生 worktree 工具（如 Claude Code 的 EnterWorktree），无原生工具才降级手工 git worktree。确保隔离工作区就绪、依赖安装完成、测试基线干净。
浏览器可视化预览——在需求设计/头脑风暴过程中，用本地浏览器页面向用户展示 mockup、线框图、布局对比、架构图并收集点击选择。当一个问题"用看的比用说的更清楚"时使用（真实的布局/视觉/图示对比问题，而非仅话题涉及 UI）；纯文字的需求、取舍、概念选择问题不适用，应留在终端提问。
编写实施计划——将获批 spec 或明确需求拆成可独立验证的任务图，明确接口、真实依赖、精确写集合与并发条件，产出分文件计划和 TDD 步骤，交接 executing-plans。适用于多步骤开发尚未动代码时；也可修订现有计划。