decisive-action

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Decisive Action

果断行动

Guidance on when to ask clarifying questions versus proceeding autonomously.

关于何时提出澄清问题、何时自主推进工作的指导方针。

When To Use

适用场景

Reducing unnecessary clarifying questions
Taking autonomous action when intent is clear

减少不必要的澄清提问
在意图明确时自主采取行动

When NOT To Use

不适用场景

High-stakes irreversible operations requiring explicit confirmation
Ambiguous requirements where clarification prevents wasted work

高风险、不可逆转的操作，需要明确确认
需求模糊，澄清提问可避免无效工作

Core Principle

核心原则

Ask questions only when ambiguity would materially impair correctness or capacity to fulfill the request precisely.

仅当歧义会实质性影响正确性或精准完成请求的能力时，才提出问题。

When to Ask (High Impact Ambiguity)

何时需要询问（高影响歧义场景）

Always Ask For

必须询问的场景

Scenario	Why	Example
Destructive Operations	Irreversible, high cost of error	"Delete which files?"
Multiple Valid Approaches	Materially different tradeoffs	"Add index vs cache vs denormalize?"
Security-Critical	Wrong choice = vulnerability	"Which auth method?"
Data Migration	Data loss risk	"Preserve or transform?"
Breaking Changes	Affects downstream users	"Deprecate or remove?"

场景	原因	示例
破坏性操作	不可逆转，错误成本高	"请问要删除哪些文件？"
多种可行方案	不同方案的取舍差异显著	"请问是添加索引、使用缓存还是采用反规范化？"
安全关键操作	错误选择会导致漏洞	"请问使用哪种认证方法？"
数据迁移	存在数据丢失风险	"请问是保留原数据还是进行转换？"
破坏性变更	会影响下游用户	"请问是弃用还是直接移除？"

Ask Threshold Checklist

询问判定 Checklist

Before asking, verify:

>30% chance of wrong interpretation
Error cost > correction cost
No clear standard approach exists
User context doesn't clarify intent

提问前，请确认：

错误解读的概率>30%
错误成本高于修正成本
不存在明确的标准解决方案
用户上下文无法明确意图

When to Proceed Without Asking

何时无需询问直接推进

Default to Action For

默认直接推进的场景

Scenario	Why	Assumption
Standard Approach Exists	Industry convention	Use conventional pattern
Easily Reversible	Low cost of error	Can undo via git/backup
Clear from Context	Intent is obvious	Proceed with stated goal
User Can Review	PR/dry-run available	Changes are inspectable

场景	原因	假设
存在标准解决方案	行业通用惯例	采用常规模式
操作可轻松撤销	错误成本低	可通过git/备份撤销操作
上下文已明确意图	意图显而易见	按既定目标推进
用户可进行审核	提供PR/预执行预览	变更可被检查

Proceed Threshold Checklist

推进判定 Checklist

Decision Matrix

决策矩阵

Reversibility	Ambiguity	Action
Reversible	Low	Proceed
Reversible	High	Proceed with preview
Irreversible	Low	Proceed with confirmation
Irreversible	High	Ask

可撤销性	歧义程度	行动
可撤销	低	直接推进
可撤销	高	带预览推进
不可撤销	低	带确认推进
不可撤销	高	询问确认

Safety Mechanisms

安全机制

Before Proceeding Autonomously

自主推进前的准备

Dry-run/Preview: Show proposed action before executing
Backup First: Create git branch, backup directory
Incremental Changes: Commit small, reviewable chunks
Document Assumptions: In commit message or PR description

预执行/预览：在执行前展示拟采取的行动
先做备份：创建Git分支、备份目录
增量变更：提交小而可审核的变更片段
记录假设：在提交信息或PR描述中记录所做假设

Undo Capability

撤销能力

Always ensure rollback is possible:

Git operations:
```
git stash
```
, backup branches
File operations: Copy before modify
Data operations: Transaction rollback

始终确保可回滚：

Git操作：
```
git stash
```
、备份分支
文件操作：修改前先复制
数据操作：支持事务回滚

Examples

示例

Example: Should Ask

示例：需要询问

User: "Delete the old files"

Analysis:

Destructive operation ✗
Multiple interpretations ✗
No clear standard ✗

Response:

Which files should I delete? I found:
- Files unchanged >6 months: 23 files
- Files in deprecated/: 5 files
- Files marked TODO remove: 2 files

用户："删除旧文件"

分析：

属于破坏性操作 ✗
存在多种解读 ✗
无明确标准方案 ✗

回复：

请问要删除哪些文件？我找到以下几类：
- 超过6个月未修改的文件：23个
- deprecated/: 5个文件
- 标记为TODO remove的文件：2个

Example: Should Proceed

示例：直接推进

User: "Add error handling to the parser"

Analysis:

Standard approach exists ✓
Easily reversible (git) ✓
User can review PR ✓

Action: Implement try/catch with logging, create PR.

用户："为解析器添加错误处理"

分析：

存在标准解决方案 ✓
可通过Git轻松撤销 ✓
用户可审核PR ✓

行动：实现带日志的try/catch逻辑，创建PR。

Example: Proceed with Preview

示例：带预览推进

User: "Refactor the API layer"

Analysis:

Multiple valid approaches
BUT: reversible via git
AND: user can review

Action:

Refactoring API layer. Proposed changes:

1. Extract authentication middleware
2. Standardize error responses
3. Add request validation

Creating branch: refactor/api-layer
Preview diff available before merge.

用户："重构API层"

分析：

存在多种可行方案
但：可通过Git撤销
且：用户可审核

行动：

正在重构API层，拟实施以下变更：

1. 提取认证中间件
2. 标准化错误响应
3. 添加请求验证

已创建分支：refactor/api-layer
合并前可查看预览差异。

Anti-Patterns

反模式

Asking Too Much (Inefficient)

过度询问（效率低下）

Asking for every implementation detail
Seeking validation for obvious choices
Repeating questions already answered in context

对每个实现细节都提问
寻求对显而易见选择的确认
重复询问上下文已回答的问题

Asking Too Little (Risky)

询问不足（风险较高）

Proceeding with destructive actions silently
Assuming intent when multiple valid interpretations exist
Ignoring ambiguity in security-critical operations

静默执行破坏性操作
在存在多种合理解读时假设意图
忽略安全关键操作中的歧义

Integration

集成

Combine with:

```
conserve:response-compression
```
- Direct communication
```
sanctum:git-workspace-review
```
- Context gathering
```
imbue:scope-guard
```
- Scope management

可与以下工具/方法结合使用：

```
conserve:response-compression
```
- 直接沟通
```
sanctum:git-workspace-review
```
- 上下文收集
```
imbue:scope-guard
```
- 范围管理

Quick Reference

快速参考

Situation	Action
"Delete X"	Ask which X
"Add feature"	Proceed with standard approach
"Fix bug"	Proceed with obvious fix
"Choose between A/B"	Ask for preference
"Optimize query"	Ask if multiple approaches
"Format code"	Proceed with project style
"Deploy to prod"	Ask for confirmation

场景	行动
"删除X"	询问具体是哪个X
"添加功能"	直接推进，采用标准方案
"修复bug"	直接推进，采用显而易见的修复方案
"在A/B之间选择"	询问偏好
"优化查询"	若存在多种方案则询问
"格式化代码"	直接推进，采用项目风格
"部署到生产环境"	询问确认

decisive-action

Original

Translation

Table of Contents

目录

Decisive Action

果断行动

When To Use

适用场景

When NOT To Use

不适用场景

Core Principle

核心原则

When to Ask (High Impact Ambiguity)

何时需要询问（高影响歧义场景）

Always Ask For

必须询问的场景

Ask Threshold Checklist

询问判定 Checklist

When to Proceed Without Asking

何时无需询问直接推进

Default to Action For

默认直接推进的场景

Proceed Threshold Checklist

推进判定 Checklist

Decision Matrix

决策矩阵

Safety Mechanisms

安全机制

Before Proceeding Autonomously

自主推进前的准备

Undo Capability

撤销能力

Examples

示例

Example: Should Ask

示例：需要询问

Example: Should Proceed

示例：直接推进

Example: Proceed with Preview

示例：带预览推进

Anti-Patterns

反模式

Asking Too Much (Inefficient)

过度询问（效率低下）

Asking Too Little (Risky)

询问不足（风险较高）

Integration

集成

Quick Reference

快速参考