| name | intent-driven-development |
| description | 在实现之前或同时，把含糊或高影响的产品和工程变更转成 scoped、可验证的验收标准。用于用户要求澄清 feature、定义验收标准、给安全/数据/迁移/集成变更降风险、为另一个智能体准备实现需求，或让复杂请求可测试的场景。不要在琐碎编辑、直接修复、活跃调试、代码审查，或验收条件已经清楚的实现请求上触发，除非用户显式调用此技能。 |
Intent-Driven Development
产出有用的验收标准，而不是把规格变成仪式。先检查可用上下文，暴露真实歧义，并选择适合工作本身及其风险的验证方法。
何时激活
- 用户要求在实现前澄清 feature、定义验收标准，或给变更降风险
- 请求触及 security、authentication、persistent data、migrations、external APIs 或 compliance
- 用户想为另一个智能体或团队准备 handoff artifact
- 请求足够含糊，期望结果尚不可观察或不可测试
- 用户用
/intent-driven-development 显式调用
不要在琐碎编辑、直接的单行修复、活跃调试会话、代码审查请求，或验收条件已清楚的实现请求上激活。
工作方式
- 先检查上下文 — 读取 repository、docs、schemas 和测试基础设施的技术事实，然后再问任何问题；但把产品/业务约束视为只能由用户或产品 artifact 提供
- 选择深度 — 按风险画像选择 Quick Capture（3-7 条标准，低/中风险）或 Full Acceptance Brief（安全、数据、迁移、跨系统变更）
- 最少提问 — 只问那些无法推断且实质改变 scope 或行为的问题
- 写可观察标准 — 每条 AC-NNN 描述起始条件、触发、期望结果、禁止的副作用、验证方法和优先级；不使用没有证据的 “correctly” 或 “securely” 等模糊词
- 继续或交接 — 对没有阻塞风险的清晰请求，记录标准并继续；对有风险的变更，呈现 blockers 并等待确认
- 处理修订 — 如果某条 AC 在实现中因架构约束失败，标记
[revised]，更新 scope 或验证方法，递增修订号，并只重新呈现变更的标准
示例
Quick Capture — “Add CSV export to the dashboard”
Goal: Authenticated users can download dashboard data as a CSV file.
In scope: Export of currently filtered rows; filename includes date.
Out of scope: Scheduled exports, email delivery, Excel format.
Assumptions: Max row count is under 10k; no PII in exported fields.
AC-001: Export generates file with correct headers
- Scenario: authenticated user, at least one data row visible
- Action: click "Export CSV"
- Expected: browser downloads file with columns [id, name, created_at]
- Must not: expose internal fields or rows belonging to other users
- Verification: automated integration test + manual schema spot-check
- Priority: Required
Full Acceptance Brief 触发 — “Migrate user auth to OAuth”
Auth 变更 + 外部依赖 + 已有 session 数据 → Full Brief，含 Risk Review 表、session invalidation 策略的 blocking decisions，以及显式 rollback AC。
现有 spec 审查 — 用户粘贴 PRD
技能审查它是否缺少 scope 边界、不可验证的要求（“the system shall be fast”）和静默假设，然后返回修正或补充的标准，无需重新开始 discovery。
运行规则
- 在询问可在本地发现的技术事实前，先检查可用 repository、文档、issue、设计和测试上下文。
- 不要从代码推断产品或业务约束。业务规则、compliance 与监管义务、合同 SLA、定价、data-retention policy、优先级和目标用户无法从 repository 读出。在用户提供它们或权威产品 artifact（PRD、合同、policy 文档）说明之前，把它们视为未知。把它们记录为待确认的假设，绝不是已发现事实。Repository 告诉你系统今天如何表现，而不是业务要求它做什么。
- 只问那些答案必需且无法安全推断的问题。把短而相关的问题分组，节省多余轮次。
- 默认不要阻塞实现。当用户要求实现一个足够清晰的变更时，简要记录关键假设和验收标准，然后继续或交给实现工作流。
- 只有当未解决的决策可能造成重大安全暴露、数据丢失、不可逆迁移、合同/API 破坏、重大成本或破坏性外部操作时，才要求用户显式确认后再继续。
- 不要把验收文档写进 repository、修改项目文件、创建 branch、commit 或调用其他技能，除非用户要求或活跃的 repository 工作流明确需要。
- 把自动化测试视为证据，不是真理。可靠且成比例时优先自动化；在自动化无法确立结果时，允许人工 UX、可访问性、安全、法律或运维验证。
- 绝不在验收标准、fixtures、示例或保存的 artifact 中包含真实 secrets、credentials、tokens、私钥、个人数据或敏感生产 payload。使用脱敏或合成值。
- 未经明确授权和已识别的安全环境，不要运行破坏性测试、迁移、安全探测、负载测试、付费外部调用，或针对生产/线上数据的操作。
- 当某条验收标准因实现中发现的架构、平台或外部约束无法满足时，不要静默丢弃或 workaround。更新受影响标准（标记
[revised]、说明约束、调整 scope 或验证方法），递增修订号，并只把变更后的标准重新呈现给用户后再继续。只有当修订改变 blocking decision 或实质降低安全或正确性保证时，才要求显式确认。
选择深度
使用最小有用输出。
Quick Capture
用于清晰但非平凡的变更，风险低或中。产出：
- Goal
- In scope / out of scope
- Assumptions
- 3-7 条带验证方法的验收标准
- Blocking questions（如有）
除非存在运行规则中的 blocking 风险，或用户特别要求先出规格，否则不要为批准而延迟实现。
Full Acceptance Brief
用于含糊、跨系统、安全敏感、改数据、迁移、compliance 或高成本变更，或用户要求 handoff artifact。产出下方完整模板，并在有风险的实现前对未解决的 blocking decisions 请求确认。
现有规格审查
当用户已提供 PRD、issue、plan 或验收标准时：
- 审查它，而不是重启 discovery。
- 识别缺少的 scope 边界、不安全假设、矛盾和不可验证要求。
- 返回修正或补充标准。
工作流
1. 确立 Goal 和风险
提取或询问：
- 用户或系统的可观察结果。
- 受影响的 actors。
- 主要失败后果。
- 实际适用的风险维度：security/privacy、persistent data、compatibility/API、migration、external dependencies、cost、concurrency、performance、usability/accessibility。
避免问关于无关风险的通用问题。
2. 发现上下文
当本地或关联 artifact 可用时，只检查所需部分：
- 现有行为和直接相关文件或接口。
- repository 约定、产品文档、API contracts、数据 schemas 或迁移历史。
- 现有验证基础设施和现实命令。
- 外部依赖以及它们是否可隔离测试。
把已发现事实与用户提供的假设分开记录。如果上下文无法检查，说明什么是未知的并提聚焦问题。
Repository 揭示技术事实——系统今天如何表现、它的约定和 contracts。它不揭示产品或业务约束：业务规则、compliance 与监管义务、合同 SLA、定价、data-retention policy、优先级和目标用户。绝不从代码或命名重建它们。只从用户或权威产品 artifact 捕获它们，并在那之前列为待确认假设。
3. 定义 scope
说明：
- Goal：一句话描述预期结果。
- In scope：此变更必须交付的行为。
- Out of scope：明确排除的诱人相邻工作。
- Assumptions：尚未证实的声明。
- Blocking decisions：实质影响安全或行为的未解决选择。
4. 写验收标准
使用 AC-001、AC-002 等。每条标准必须描述可观察行为和恰当验证方法；标准和测试不必一一对应。
对每条适用标准包含：
- Scenario 或起始条件。
- Action 或触发。
- Expected 可观察行为。
- Prohibited 副作用（有意义时）。
- Verification method：automated test、integration check、manual UX review、accessibility check、security review、operational check 或 stakeholder acceptance。
- Environment/safety 约束（当验证可能影响数据、服务、成本或 secrets 时）。
- Priority：required、important 或 optional。
不要使用 “correctly”、“securely”、“fast”、“intuitive” 或 “robust” 等词，除非定义了可观察证据或记录为人工审查判断。
5. 只覆盖相关边界
考虑这些类别，但只纳入适用的：
| 类别 | 何时纳入 | 典型证据 |
|---|
| Happy path | 新增或变更的用户可见行为 | 成功 workflow 或状态转移 |
| Validation | 变更接受输入 | 拒绝畸形或边界值且不发生 mutation |
| Authorization/privacy | 数据或操作有访问边界 | 拒绝访问且不泄漏敏感信息 |
| Persistence/migration | 存储数据或 schemas 变更 | 向后读取、迁移、rollback 或备份行为 |
| Compatibility | 公共 API、文件、事件或客户端可能破坏 | 现有 contract 或 fixture 仍有效 |
| Failure recovery | 存在网络、服务或异步失败 | 无部分状态，或有清晰 retry/degraded 行为 |
| Idempotency/concurrency | 重复或同时写入可能发生 | 无重复副作用或无效终态 |
| Performance | 某个用户或服务阈值重要 | 定义测量条件和阈值 |
| UX/accessibility | 有人与结果交互 | 键盘、反馈、错误恢复、视觉/人工审查 |
6. 呈现并继续
- 对澄清/规格请求，呈现 brief 并只对列出的 blockers 请求决策。
- 对无 blocker 的实现请求，呈现紧凑标准摘要作为工作一部分并继续实现。
- 对交接给另一个智能体或团队，包含足够上下文和验证细节，使他们无需发明需求即可行动。
- 只在请求时把 brief 保存到文件。当存在 repository 批准的路径时使用它；否则在写入前询问或说明所选目标。
输出模板
对 Full Acceptance Brief 使用此模板。Quick Capture 时省略无关 sections。
# Acceptance Brief: <Change Name>
**Status:** Draft | Approved | Implemented | Verified
**Revision:** <number>
**Prepared for:** <user/team/agent, when known>
**Approval required before risky work:** Yes | No - <reason>
## Revision Log
| Rev | Date | Changed criteria | Reason |
| --- | --- | --- | --- |
| 1 | <date> | — | Initial draft |
## Goal
<One observable outcome sentence.>
## Scope
**In scope**
- <behavior included>
**Out of scope**
- <adjacent work excluded>
## Context
**Discovered facts** (technical, verified from repository or artifact)
- <how the system behaves today, conventions, contracts>
**Product/business constraints** (supplied by user or product artifact, never inferred from code)
- < , / , , , — " ">
| Risk area | Applies? | Required handling |
| --- | --- | --- |
| Security/privacy | Yes/No | |
| Persistent data/migration | Yes/No | |
| External effects/cost | Yes/No | |
| Compatibility/API | Yes/No | |
| UX/accessibility | Yes/No | |
Required | Important | Optional
[ ]
| Criterion | Verification evidence | Status |
| --- | --- | --- |
| AC-001 | | Pending |
通过/失败示例
用这些判断技能是否真的产出了可验证 brief，而不是 planning prose。
失败的验收标准
AC-001: The export works correctly and is secure.
失败——“works correctly” 和 “secure” 不可观察，没有 scenario、trigger、expected result 或 verification method，也没有说明什么绝不能发生。读者无法判断实现是否满足了它。
通过的验收标准
AC-001: Export generates file with correct headers
- Scenario: authenticated user, at least one data row visible
- Action: click "Export CSV"
- Expected: browser downloads file with columns [id, name, created_at]
- Must not: expose internal fields or rows belonging to other users
- Verification: automated integration test + manual schema spot-check
- Priority: Required
通过——一个具体可观察结果、一个禁止副作用，以及一个命名验证方法。两个人会就是否满足达成一致。
失败的 context 条目
Discovered facts: Users on the free tier are limited to 100 exports per month.
失败——按 tier 限制是业务规则。它不能作为从代码推断的 discovered facts 出现；它属于 Product/business constraints，由用户提供，或列为待确认假设。
通过/失败 rubric
只有当每个答案是 “yes” 时 brief 才通过。任何 “no” 意味着返回前修订。
质量检查
返回 brief 前检查：
- Goal 描述结果而非实现选择。
- scope 边界和假设显式。
- 每条必需标准可观察，或清晰标记为人工判断。
- 只在相关处考虑 security、privacy、data、compatibility、external-effect 和 UX 风险，不静默忽略。
- 验证方法为有风险操作识别安全环境。
- 无 secret 或生产敏感信息被复制进输出。
- 无 repository 变更或实现阻塞在没有理由或请求的情况下被强加。
交接
当另一个 planning 或实现工作流可用时，把验收 brief 或标准 ID 传给它。当没有专用工作流时，直接把 brief 作为实现参考提供。不要假设任何命名 skill 或工具已安装。
