intent-driven-development

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Intent-Driven Development

意图驱动开发

Produce useful acceptance criteria without turning specification into ceremony. Inspect available context first, expose genuine ambiguity, and choose verification methods that fit the work and its risk.

制定实用的验收标准，避免将规范变成形式主义。首先检查可用上下文，明确真正的模糊点，并选择适合工作及其风险的验证方法。

When to Activate

激活场景

User asks to clarify a feature, define acceptance criteria, or de-risk a change before implementation
Request touches security, authentication, persistent data, migrations, external APIs, or compliance
User wants to prepare a handoff artifact for another agent or team
Request is ambiguous enough that the expected outcome is not yet observable or testable
User explicitly invokes this skill with
```
/intent-driven-development
```

Do not activate for trivial edits, straightforward one-line fixes, active debugging sessions, code review requests, or implementation requests whose acceptance conditions are already clear.

用户要求在实施前澄清功能、定义验收标准或降低变更风险
请求涉及安全、认证、持久化数据、迁移、外部API或合规性
用户希望为其他Agent或团队准备交接文档
请求模糊到预期结果尚不可观察或无法测试
用户通过
```
/intent-driven-development
```
明确调用此技能

请勿针对微小编辑、简单单行修复、主动调试会话、代码审查请求或验收条件已明确的实施请求激活此技能。

How It Works

工作流程

Inspect context first — reads the repository, docs, schemas, and test infrastructure for technical facts before asking any question, while treating product/business constraints as something only the user or a product artifact can supply
Choose depth — selects Quick Capture (3-7 criteria, low/moderate risk) or Full Acceptance Brief (security, data, migration, cross-system changes) based on the risk profile
Ask minimally — only asks questions whose answers cannot be inferred and that materially change scope or behavior
Write observable criteria — each AC-NNN describes a starting condition, trigger, expected outcome, prohibited side effect, verification method, and priority; no vague words like "correctly" or "securely" without evidence
Proceed or hand off — for clear requests with no blocking risks, records criteria and continues; for risky changes, presents blockers and waits for confirmation
Handle revision — if an AC fails mid-implementation due to architectural constraints, marks it
```
[revised]
```
, updates scope or verification method, increments the revision number, and re-presents only the changed criteria

先检查上下文 — 在提问前先读取代码库、文档、模式和测试基础设施中的技术事实，同时将产品/业务约束视为仅能由用户或产品文档提供的内容
选择深度 — 根据风险状况选择快速记录（3-7条标准，低/中等风险）或完整验收简报（安全、数据、迁移、跨系统变更）
最小化提问 — 仅询问无法推断且会实质性改变范围或行为的问题
编写可观察的标准 — 每条AC-NNN描述起始条件、触发动作、预期结果、禁止的副作用、验证方法和优先级；避免使用“正确地”或“安全地”等模糊词汇，除非有明确依据
推进或交接 — 对于无阻塞风险的明确请求，记录标准后继续；对于高风险变更，列出阻塞点并等待确认
处理修订 — 如果某个AC在实施过程中因架构约束无法满足，标记为
```
[revised]
```
，更新范围或验证方法，增加修订版本号，并仅向用户展示修改后的标准

Examples

示例

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 trigger — "Migrate user auth to OAuth"

Auth change + external dependency + existing session data → Full Brief with Risk Review table, blocking decisions on session invalidation strategy, and explicit rollback AC.

Existing spec review — user pastes a PRD

Skill reviews it for missing scope boundaries, unverifiable requirements ("the system shall be fast"), and silent assumptions, then returns corrected or supplemental criteria without restarting discovery.

快速记录 — "为仪表盘添加CSV导出功能"

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

完整验收简报触发场景 — "将用户认证迁移到OAuth"

认证变更 + 外部依赖 + 现有会话数据 → 包含风险审查表、会话失效策略的阻塞决策以及明确回滚AC的完整简报。

现有规范审查 — 用户粘贴PRD

该技能会审查PRD中缺失的范围边界、无法验证的需求（如“系统应快速运行”）和隐含假设，然后返回修正或补充后的标准，无需重新开展需求探索。

Operating Rules

操作规则

Inspect the available repository, documentation, issue, design, and test context before asking for technical facts that can be discovered locally.
Do not infer product or business constraints from code. Business rules, compliance and regulatory obligations, contractual SLAs, pricing, data-retention policy, prioritization, and target users cannot be read from a repository. Treat them as unknown until the user supplies them or an authoritative product artifact (PRD, contract, policy document) states them. Record them as assumptions flagged for confirmation, never as discovered facts. The repository tells you how the system behaves today, not what the business requires it to do.
Ask only questions whose answers are required and cannot be safely inferred. Group short, related questions when that saves unnecessary turns.
Do not block implementation by default. When the user has asked to implement a sufficiently clear change, record key assumptions and acceptance criteria briefly, then proceed or hand them to the implementation workflow.
Require explicit user confirmation before proceeding only when an unresolved decision could create material security exposure, data loss, irreversible migration, contractual/API breakage, meaningful cost, or destructive external action.
Do not write an acceptance document into a repository, alter project files, create a branch, commit, or invoke another skill unless the user requests it or the active repository workflow explicitly requires it.
Treat automated tests as evidence, not truth. Prefer automation when reliable and proportionate; allow manual UX, accessibility, security, legal, or operational verification where automation cannot establish the outcome.
Never include real secrets, credentials, tokens, private keys, personal data, or sensitive production payloads in acceptance criteria, fixtures, examples, or saved artifacts. Use redacted or synthetic values.
Do not run destructive tests, migrations, security probes, load tests, paid external calls, or operations against production/live data without explicit authorization and an identified safe environment.
When an acceptance criterion cannot be satisfied due to an architectural, platform, or external constraint discovered during implementation, do not silently drop or workaround it. Update the affected criterion (mark it
```
[revised]
```
, state the constraint, and adjust scope or verification method), increment the revision number, and re-present only the changed criteria to the user before continuing. Require explicit confirmation only if the revision changes a blocking decision or materially reduces safety or correctness guarantees.

在询问可本地获取的技术事实前，先检查可用的代码库、文档、问题、设计和测试上下文。
不要从代码中推断产品或业务约束。业务规则、合规与监管义务、合同SLA、定价、数据保留政策、优先级和目标用户无法从代码库中读取。在用户提供或权威产品文档（PRD、合同、政策文件）明确说明前，将其视为未知内容。将其记录为待确认的假设，而非已发现的事实。代码库只能告诉你系统当前的行为，而非业务对它的要求。
仅询问必要且无法安全推断的问题。当可以减少不必要的沟通回合时，将简短的相关问题分组提问。
默认不要阻塞实施。当用户要求实施的变更足够明确时，简要记录关键假设和验收标准，然后推进或移交至实施工作流。
只有当未解决的决策可能造成重大安全风险、数据丢失、不可逆迁移、合同/API中断、显著成本或破坏性外部操作时，才需要用户明确确认后再推进。
除非用户请求或当前代码库工作流明确要求，否则不要将验收文档写入代码库、修改项目文件、创建分支、提交或调用其他技能。
将自动化测试视为证据，而非真理。在可靠且合适的情况下优先使用自动化；在自动化无法验证结果的场景下，允许手动进行UX、可访问性、安全、法律或运营验证。
切勿在验收标准、测试数据、示例或保存的文档中包含真实密钥、凭证、令牌、私钥、个人数据或敏感生产负载。使用脱敏或合成值。
在未获得明确授权且未确定安全环境的情况下，不要针对生产/实时数据运行破坏性测试、迁移、安全探测、负载测试、付费外部调用或操作。
如果某个验收标准因实施过程中发现的架构、平台或外部约束无法满足，不要默默删除或绕过它。更新受影响的标准（标记为
```
[revised]
```
，说明约束条件，并调整范围或验证方法），增加修订版本号，并在继续实施前仅向用户展示修改后的标准。只有当修订改变了阻塞决策或实质性降低了安全性或正确性保证时，才需要用户明确确认。

Choose The Depth

选择合适的深度

Use the smallest useful output.

使用最精简的有效输出。

Quick Capture

快速记录

Use for a clear but non-trivial change with low or moderate risk. Produce:

Goal
In scope / out of scope
Assumptions
3-7 acceptance criteria with verification methods
Blocking questions, if any

Do not delay implementation for approval unless a blocking risk from the operating rules exists or the user specifically asked for a specification first.

适用于清晰但非微小的低/中等风险变更。输出内容包括：

目标
包含/排除范围
假设
3-7条带验证方法的验收标准
阻塞问题（如有）

除非存在操作规则中提到的阻塞风险，或用户明确要求先制定规范，否则不要因等待批准而延迟实施。

Full Acceptance Brief

完整验收简报

Use for ambiguous, cross-system, security-sensitive, data-changing, migration, compliance, or high-cost changes, or when the user requests a handoff artifact. Produce the full template below and request confirmation for unresolved blocking decisions before risky implementation.

适用于模糊、跨系统、安全敏感、数据变更、迁移、合规或高成本变更，或用户要求准备交接文档的场景。生成以下完整模板，并在高风险实施前请求用户确认未解决的阻塞决策。

Existing Specification Review

现有规范审查

When the user already supplied a PRD, issue, plan, or acceptance criteria:

Review it instead of restarting discovery.
Identify missing scope boundaries, unsafe assumptions, contradictions, and unverifiable requirements.
Return corrected or supplemental criteria.

当用户已提供PRD、问题、计划或验收标准时：

审查现有内容，而非重新开展需求探索。
识别缺失的范围边界、不安全的假设、矛盾点和无法验证的需求。
返回修正或补充后的标准。

Workflow

工作流

1. Establish Goal And Risk

1. 确立目标与风险

Extract or ask for:

The observable outcome for the user or system.
The actors affected.
The main failure consequence.
Risk dimensions that actually apply: security/privacy, persistent data, compatibility/API, migration, external dependencies, cost, concurrency, performance, usability/accessibility.

Avoid asking generic questions about irrelevant risks.

提取或询问以下内容：

用户或系统可观察的结果。
受影响的参与者。
主要失败后果。
实际适用的风险维度：安全/隐私、持久化数据、兼容性/API、迁移、外部依赖、成本、并发、性能、可用性/可访问性。

避免询问与无关风险相关的通用问题。

2. Discover Context

2. 探索上下文

When local or connected artifacts are available, inspect only what is needed:

Existing behavior and directly related files or interfaces.
Repository conventions, product docs, API contracts, data schemas, or migration history.
Existing verification infrastructure and realistic commands.
External dependencies and whether they are testable in isolation.

Record discovered facts separately from user-provided assumptions. If context cannot be inspected, say what is unknown and ask focused questions.

The repository reveals technical facts — how the system behaves today, its conventions, and its contracts. It does not reveal product or business constraints: business rules, compliance and regulatory obligations, contractual SLAs, pricing, data-retention policy, prioritization, and target users. Never reconstruct these from code or naming. Capture them only from the user or an authoritative product artifact, and list them as assumptions to confirm until then.

当有本地或关联文档可用时，仅检查必要内容：

现有行为及直接相关的文件或接口。
代码库约定、产品文档、API契约、数据模式或迁移历史。
现有验证基础设施和实际可用的命令。
外部依赖及其是否可独立测试。

将发现的事实与用户提供的假设分开记录。如果无法检查上下文，说明未知内容并提出针对性问题。

代码库揭示技术事实——系统当前的行为、约定和契约。但无法揭示产品或业务约束：业务规则、合规与监管义务、合同SLA、定价、数据保留政策、优先级和目标用户。切勿从代码或命名中重构这些内容。仅从用户或权威产品文档中获取，并将其列为待确认的假设。

3. Define Scope

3. 定义范围

State:

Goal: one sentence describing the intended outcome.
In scope: behavior this change must deliver.
Out of scope: tempting adjacent work explicitly excluded.
Assumptions: claims not yet proven.
Blocking decisions: unresolved choices that materially affect safety or behavior.

明确说明：

目标：一句话描述预期结果。
包含范围：此变更必须实现的行为。
排除范围：明确排除的相关工作。
假设：尚未证实的主张。
阻塞决策：会实质性影响安全性或行为的未解决选择。

4. Write Acceptance Criteria

4. 编写验收标准

Use

AC-001

AC-002

, and so on. Each criterion must describe observable behavior and an appropriate verification method; criteria and tests are not required to map one-to-one.

For each applicable criterion include:

Scenario or starting condition.
Action or trigger.
Expected observable behavior.
Prohibited side effect when meaningful.
Verification method: automated test, integration check, manual UX review, accessibility check, security review, operational check, or stakeholder acceptance.
Environment/safety constraint when verification could affect data, services, cost, or secrets.
Priority: required, important, or optional.

Do not use words such as "correctly", "securely", "fast", "intuitive", or "robust" without defining observable evidence or recording them as a human-review judgment.

使用

AC-001

、

AC-002

等编号。每条标准必须描述可观察的行为和合适的验证方法；标准与测试无需一一对应。

每条适用的标准应包含：

场景或起始条件。
动作或触发事件。
预期可观察行为。
有意义时需说明禁止的副作用。
验证方法：自动化测试、集成检查、手动UX审查、可访问性检查、安全审查、运营检查或相关方验收。
当验证可能影响数据、服务、成本或密钥时，需说明环境/安全约束。
优先级：必需、重要或可选。

不要使用“正确地”、“安全地”、“快速地”、“直观地”或“健壮地”等词汇，除非定义了可观察的依据或明确标记为人工评审判断。

5. Cover Only Relevant Boundaries

5. 仅覆盖相关边界

Consider these categories, but include only categories that apply:

Category	Include when	Typical evidence
Happy path	New or changed user-visible behavior	Successful workflow or state transition
Validation	The change accepts input	Rejected malformed or boundary value without mutation
Authorization/privacy	Data or actions have access boundaries	Denied access and no sensitive disclosure
Persistence/migration	Stored data or schemas change	Backward read, migration, rollback or backup behavior
Compatibility	Public APIs, files, events, or clients may break	Existing contract or fixture remains valid
Failure recovery	Network, service, or asynchronous failure exists	No partial state or clear retry/degraded behavior
Idempotency/concurrency	Repeats or simultaneous writes are plausible	No duplicate side effect or invalid final state
Performance	A user or service threshold matters	Defined measurement conditions and threshold
UX/accessibility	A person interacts with the result	Keyboard, feedback, error recovery, visual/manual review

考虑以下类别，但仅包含适用的类别：

类别	适用场景	典型验证依据
正常流程	新增或变更用户可见行为	成功的工作流或状态转换
验证	变更接受输入	拒绝格式错误或边界值且不修改数据
授权/隐私	数据或操作有访问边界	拒绝访问且不泄露敏感信息
持久化/迁移	存储数据或模式变更	向后兼容读取、迁移、回滚或备份行为
兼容性	公共API、文件、事件或客户端可能中断	现有契约或测试数据保持有效
故障恢复	存在网络、服务或异步故障	无部分状态或明确的重试/降级行为
幂等性/并发	可能存在重复或同时写入	无重复副作用或无效最终状态
性能	用户或服务阈值重要	明确的测量条件和阈值
UX/可访问性	有人与结果交互	键盘操作、反馈、错误恢复、视觉/手动评审

6. Present And Continue

6. 展示并推进

For a clarification/specification request, present the brief and ask for decisions only on listed blockers.
For an implementation request with no blocker, present a compact criteria summary as part of the work and continue with implementation.
For handoff to another agent or team, include enough context and verification detail for them to act without inventing requirements.
Save the brief to a file only when requested. Use a repository-approved path when one exists; otherwise ask for or state the chosen destination before writing.

对于澄清/规范请求，展示简报并仅请求用户对列出的阻塞点做出决策。
对于无阻塞点的实施请求，展示简洁的标准摘要作为工作的一部分，然后继续实施。
对于交接给其他Agent或团队的场景，包含足够的上下文和验证细节，使他们无需自行制定要求即可开展工作。
仅在用户请求时将简报保存到文件。如果有代码库认可的路径则使用该路径；否则在写入前询问或说明所选路径。

Output Template

输出模板

Use this template for a Full Acceptance Brief. Omit irrelevant sections for Quick Capture.

markdown

undefined

使用此模板生成完整验收简报。快速记录可省略无关部分。

markdown

undefined

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

Rev	Date	Changed criteria	Reason
1	<date>	—	Initial draft

Goal

Scope

In scope

<behavior included>

Out of scope

<adjacent work excluded>

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)

<business rule, compliance/SLA obligation, retention policy, priority, target user — or "none supplied yet">

Assumptions

<unverified claim to confirm or validate>

Dependencies and constraints

<external service, local convention, compatibility obligation, environment limit>

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)

<business rule, compliance/SLA obligation, retention policy, priority, target user — or "none supplied yet">

Assumptions

<unverified claim to confirm or validate>

Dependencies and constraints

<external service, local convention, compatibility obligation, environment limit>

Risk Review

Risk area	Applies?	Required handling
Security/privacy	Yes/No	<redaction, authorization, review, etc.>
Persistent data/migration	Yes/No	<compatibility, backup, rollback, etc.>
External effects/cost	Yes/No	<sandbox/test environment/authorization>
Compatibility/API	Yes/No	<contract to preserve or version>
UX/accessibility	Yes/No	<manual or automated evidence>

Risk area	Applies?	Required handling
Security/privacy	Yes/No	<redaction, authorization, review, etc.>
Persistent data/migration	Yes/No	<compatibility, backup, rollback, etc.>
External effects/cost	Yes/No	<sandbox/test environment/authorization>
Compatibility/API	Yes/No	<contract to preserve or version>
UX/accessibility	Yes/No	<manual or automated evidence>

Acceptance Criteria

AC-001: <observable behavior>

Scenario: <starting condition>
Action: <single trigger>
Expected: <observable result>
Must not: <prohibited side effect, if applicable>
Verification: <method and intended evidence>
Environment/safety: <constraints, if applicable>
Priority: Required | Important | Optional

Scenario: <starting condition>
Action: <single trigger>
Expected: <observable result>
Must not: <prohibited side effect, if applicable>
Verification: <method and intended evidence>
Environment/safety: <constraints, if applicable>
Priority: Required | Important | Optional

Blocking Decisions

<only decisions that prevent safe or correct progress>

<only decisions that prevent safe or correct progress>

Verification Plan

Criterion	Verification evidence	Status
AC-001	<test/check/review command or evidence type>	Pending

undefined

Criterion	Verification evidence	Status
AC-001	<test/check/review command or evidence type>	Pending

undefined

Pass/Fail Examples

合格/不合格示例

Use these to judge whether the skill actually produced a verifiable brief, not planning prose.

A failing acceptance criterion

AC-001: The export works correctly and is secure.

Fails — "works correctly" and "secure" are not observable, there is no scenario, trigger, expected result, or verification method, and nothing states what must not happen. A reader cannot tell whether the implementation satisfied it.

A passing acceptance criterion

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

Passes — a concrete observable outcome, a prohibited side effect, and a named verification method. Two people would agree on whether it was met.

A failing context entry

Discovered facts: Users on the free tier are limited to 100 exports per month.

Fails — a per-tier limit is a business rule. It must not appear under discovered facts inferred from code; it belongs under Product/business constraints, supplied by the user, or be listed as an assumption to confirm.

用这些示例判断技能是否生成了可验证的简报，而非空泛的规划文字。

不合格的验收标准

AC-001: The export works correctly and is secure.

不合格——“works correctly”和“secure”不可观察，没有场景、触发动作、预期结果或验证方法，也未说明禁止的行为。读者无法判断实施是否满足该标准。

合格的验收标准

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

合格——有具体的可观察结果、禁止的副作用和明确的验证方法。两个人会对是否满足该标准达成一致。

不合格的上下文条目

Discovered facts: Users on the free tier are limited to 100 exports per month.

不合格——按层级限制是业务规则。不能将其列为从代码中推断出的已发现事实；它应属于产品/业务约束（由用户提供），或列为待确认的假设。

Pass/Fail Rubric

合格/不合格评判标准

Quality Check

质量检查

Before returning the brief, check:

The goal describes an outcome rather than an implementation choice.
Scope boundaries and assumptions are explicit.
Every required criterion is observable or clearly marked for human judgment.
Security, privacy, data, compatibility, external-effect, and UX risks were considered only where relevant and not silently ignored.
Verification methods identify safe environments for risky operations.
No secret or production-sensitive information was copied into the output.
No repository mutation or implementation block is imposed without justification or request.

返回简报前，检查：

目标描述的是结果而非实现选择。
范围边界和假设明确。
每条必需的标准都是可观察的或明确标记为人工评审。
仅在相关场景下考虑安全、隐私、数据、兼容性、外部影响和UX风险，未默默忽略。
验证方法明确了高风险操作的安全环境。
输出中未包含密钥或生产敏感信息。
未无理由或未经请求就修改代码库或阻塞实施。

Handoff

交接

When another planning or implementation workflow is available, pass the acceptance brief or criterion IDs to it. When no dedicated workflow exists, provide the brief directly as the implementation reference. Do not assume any named skill or tool is installed.

当有其他规划或实施工作流可用时，将验收简报或标准ID移交至该工作流。当没有专用工作流时，直接提供简报作为实施参考。不要假设已安装任何指定技能或工具。