Idea Intake: ＜short title＞

Idea Intake:【免费下载链接】spec-kit Toolkit to help you get started with Spec-Driven Development项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kitSlug: ASSESS_SLUGCreated: ISO 8601 dateSource: sanitized URL, pasted text, or repo pathType: new-capability | improvement | fix | exploration | cost-saving | compliance | otherIdea (as captured)RestatedOrigin ContextFirst-Glance Unknowns完成后命令会单行报告 Slug: ASSESS_SLUG供后续阶段从会话上下文复用、intake.md 路径以及建议的下一步research或当想法已足够清晰时直接 define。 ### 2. research收集证据也必须收集反方证据 [speckit.assess.research.md](https://link.gitcode.com/i/2622f7ab887ebfcbc6cdfb015259e187) 的职责是为诚实判断想法而收集证据存在本身就是为了*挑战*想法。它**收集并引用证据但不做裁决**。 slug 解析顺序为显式 slug… → 本会话刚执行过 intake 的上下文以 intake.md 存在为确认依据→ 交互询问 → 自动化模式下恰好只有一个评估目录则使用否则停止询问。前置检查要求intake.md 缺失时只有当 $ARGUMENTS 中携带了真实的想法文本才继续——**如果输入只有一个 slug不得从 slug 脑补想法**。 调查覆盖五个视角不适用的可跳过缺口标记 [NEEDS CLARIFICATION: …] 而非猜测**每条论断必须带引用或标记为假设** 1. **Users demand**——谁真正有这个问题区分说出来的想要与观察到的行为 2. **Prior art**——内部既有功能、.specify/ 中的历史规格与决策、竞品、开源替代 3. **Market context**——趋势、用户当下如何 coping、什么都不做的代价 4. **Data constraints**——相关指标、体量、合规/法务、平台限制 5. **Evidence quality**——每条发现标注置信度 high | medium | low 及 cited / assumption。 research.md 模板包含 Users Demand、Prior Art、Market Context、Data Constraints、**Evidence Against the Idea**、Gaps Open Questions、Sources 七个部分。其中 Evidence Against the Idea 是**每次都必须存在**的章节——找不到反方证据就明确说明找不到而不允许省略。每个来源在 Sources 中记录净化后的 URL剥离 user:password 与可能携带凭据/签名的查询参数、解析出的 host 和所走的策略分支。 ### 3. define把模糊想法转成问题空间陈述 [speckit.assess.define.md](https://link.gitcode.com/i/45c70d264f1f72347bf8fe958a8f233e) 是流水线的枢纽把建 X这样的**解法**输入反向工程出 X 想解决的**问题**。它*框定问题*不塑形、不选方案。若输入本身是方案要追问这个方案解决什么问题。 执行步骤 1. 一两句话陈述问题谁受影响、今天哪里痛、什么条件下、为何现在重要留在问题空间——不出现功能、架构 2. 识别用户与干系人用户承受问题干系人做决定/出资/受影响有研究依据就引用凭空杜撰的标记 [NEEDS CLARIFICATION: …] 3. 设定**目标**解决它为何值得 4. 设定**非目标**显式划出范围边界防止范围蔓延 5. 定义**成功指标**优先可测量信号定性指标须明确标注 6. 建立**基线**——什么都不建会发生什么cost of inaction这是 decide 的对照物 7. 结转 intake/research 中必须在规格化期间解决或未解决的开放问题。 problem.md 模板含 Problem Statement、Affected Users Stakeholders、Goals、Non-Goals、Success Metrics每条附 baseline、Cost of Inaction、Open Questions。报告时给出 slug、路径、开放问题数量及下一步 shape。若问题根本无法陈述命令应明说并建议重跑 intake 或 research而不是硬凑一段陈述。 ### 4. shape概念级选项而非蓝图 [speckit.assess.shape.md](https://link.gitcode.com/i/6f70e8a12fcfa887929b3741fb1cf4a4) 是评估从问题空间跨入解法空间的地方但**只到概念层**——类比 Shape Up 的 pitch不是 blueprint。架构、数据模型、API、任务拆解都留给 specify 及后续 SDD 阶段。前置条件硬性要求 problem.md 存在。 执行要点 1. 生成 **2–3 个彼此有区分度的选项**覆盖权衡空间。必须始终包含一个能起作用的最小方案smallest thing that could work相关时包含不做/买而不是建选项。每个选项给出 - **Sketch**一段概念级描述用户体验到什么/什么发生变化不写工程实现 - **Appetite**粗略体量 small天级| medium周级| large月级——是预算而非估算 - **Trade-offs**得到什么、牺牲什么、关键风险与未知 - **Rabbit holes**最可能撑爆范围的部分让 decide 能看见 2. **推荐一个选项**理由须绑定目标与指标——或明确推荐*不推进* 3. 为推荐选项重申**显式排除项**继承 non-goals 加新排除项; 4. 列出推荐所依赖的**待验证假设**留待规格化期间校验。 推荐没有任何选项值得建是合法结果——命令明确要求直说而不是制造一个赢家。 ### 5. decide三值裁决与可审计的记分卡 [speckit.assess.decide.md](https://link.gitcode.com/i/912c34d11e0592d6ac0486b666961878) 是发现轨与交付轨之间的门禁**go** 交接给 specify**kill** 带着文档化理由终止**needs-clarification** 打回指定阶段。它*判断*不写规格、不构建。 第一步是对想法按六个显式标准打分每项取 strong | adequate | weak | unknown 并附一行来自工件的理由 | 标准 | 来源工件 | 含义 | |-----------|--------|------| | Problem validity | problem.md research.md | 问题是否真实且值得解决 | | Evidence strength | research.md | 证据支撑程度 vs 假设驱动程度 | | Value vs. cost of inaction | problem.md | 解决它是否胜过什么都不做 | | Feasibility / appetite fit | concept.md | 是否存在 appetite 合理且可信的选项 | | Strategic fit | 项目章程/目标若可知 | 是否对齐项目方向 | | Risk posture | 全部工件 | 主要风险是否已被识别且可信缓解strong 已识别并可信缓解weak 存在未缓解的重大风险 | 裁决规则严格且防过度乐观 - **go** 要求problem validity adequate**evidence strength adequate绝不接受 weak 或 unknown**且存在推荐的概念选项 - **needs-clarification**有希望但被具体未知阻塞须列出确切问题及应回退的阶段intake / research / define / shape - **kill**不值得现在建直说决定性理由问题弱、存在更好替代、成本价值、超出范围、已被取代。 decision.md 模板包含 Scorecard六行表格、Verdict Rationale须引用记分卡任何 unknown 分数必须被承认而非粉饰、If needs-clarification阻塞问题 回退阶段、If go — Handoff to /speckit.specify一行问题陈述、选定方案、范围内/外摘要、成功指标、结转的开放问题四个部分保证数月后仍可审计。 ## Slug 约定五个命令共享的路径句柄 [README](https://link.gitcode.com/i/906fcb47496de5ba8dde8f629eff3858) 将 slug 规则归纳为四类来源命令文件给出了可执行的归一化细则 - **用户提供**归一化为小写 kebab-case如 offline-mode。归一化规则小写化空白/下划线转为 -仅保留 [a-z0-9-]丢弃包括 .、/、\ 在内的一切其他字符折叠重复 -去除首尾 -。归一化后**原样保留**——不追加时间戳或编号 - **交互式询问**用户未提供时intake 会询问 slug并给出由想法派生的 2–4 词 kebab-case 候选 - **自动化生成**无人值守时 Agent 自行生成唯一 slug且**永不覆盖已存在的评估目录**必要时追加 -2、-3 … 或短日期 -20260715; - **会话复用**后续阶段复用本会话先前报告过的 slug以评估目录存在作为确认。 归一化的安全意义空结果如输入 ../..、/ 或纯非 ASCII被直接拒绝由于归一化剥掉了 .、/、\ASSESS_DIR 在构造上就不可能逃逸出 .specify/assessments/。 ## 安装、启停与典型使用流程 assess 是随 Spec Kit 捆绑的分发扩展bundled: true见下文源码证据在任意已初始化的 Spec Kit 项目中安装即可 bash specify extension add assess临时关闭与重新启用specify extension disable assess specify extension enable assess端到端的典型流程以离线模式想法为例# 1. 捕获想法粘贴文本、URL或 assess this repo /speckit.assess.intake Let users work offline and sync when they reconnect slugoffline-mode # 2. 收集证据——包括它可能不值得做的理由 /speckit.assess.research slugoffline-mode # 3. 定义真正的问题 /speckit.assess.define slugoffline-mode # 4. 塑形 2–3 个带 appetite 的概念选项 /speckit.assess.shape slugoffline-mode # 5. 裁决——go、clarify 还是 kill /speckit.assess.decide slugoffline-mode # → 若为 go将 decision.md 的 handoff 摘要交给 /speckit.specify【免费下载链接】spec-kit Toolkit to help you get started with Spec-Driven Development项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考