oac-approach

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan Before You Code

编码先规划

Overview

概述

Understand the request, discover relevant context, propose a concise plan, get approval. Keep it fast — the goal is alignment, not a design workshop.

<HARD-GATE> Do NOT write any code or make any file changes until the user has approved your proposed approach. </HARD-GATE>

理解需求、发掘相关上下文、提出简洁方案、获得批准。保持流程高效——目标是达成共识，而非开展设计研讨会。

<HARD-GATE> 在用户批准你提出的方案前，请勿编写任何代码或修改任何文件。 </HARD-GATE>

The Process

流程步骤

Step 1: Understand the Request

步骤1：理解需求

Read the user's message. You already have the "what" — don't ask a series of questions up front. Only ask clarifying questions if:

The request is genuinely ambiguous (two different valid interpretations)
You discover during context check that key details are missing (e.g. which framework, which database)

In those cases, ask the specific questions you need — not a blanket "tell me more". Be explicit about what you need and why.

阅读用户的消息。你已经知道了“要做什么”——不要一开始就问一连串问题。仅在以下情况提出澄清问题：

需求确实存在歧义（有两种不同的合理解释）
在检查上下文时发现关键细节缺失（例如，使用哪个框架、哪个数据库）

在这些情况下，提出你需要的具体问题——不要笼统地说“告诉我更多信息”。明确说明你需要什么以及原因。

Step 2: Discover Context

步骤2：发掘上下文

Invoke

oac:context-discovery

with the task topic to find relevant project standards and patterns.

If context-discovery reports no context installed: proceed anyway — note it as "none" in the proposal and include the context hint (see Step 4). Do not pause or ask the user before proposing.

If context found: note the key files returned — reference them in your proposal.

调用

oac:context-discovery

工具，根据任务主题查找相关的项目标准和模式。

如果context-discovery显示未安装上下文： 继续执行——在方案中注明“无”，并添加上下文提示（见步骤4）。不要暂停或在提出方案前询问用户。

如果找到上下文： 记录返回的关键文件——在方案中引用它们。

Step 3: Ask Clarifying Questions (if needed)

步骤3：提出澄清问题（如有需要）

After reviewing the context and the request, if there are still gaps that would significantly change the approach, ask them now — explicitly and concisely:

Before I propose an approach, I need a couple of details:

1. {specific question} — because {why it matters to the approach}
2. {specific question} — because {why it matters to the approach}

Keep it to the minimum needed. If you can make a reasonable assumption, state it in the proposal instead of asking.

在审查上下文和需求后，如果仍存在会显著改变方案的信息缺口，现在就明确、简洁地提出：

在我提出方案前，我需要几个细节：

1. {具体问题} —— 因为 {它对方案的重要性}
2. {具体问题} —— 因为 {它对方案的重要性}

尽量减少问题数量。如果可以做出合理假设，在方案中说明即可，无需询问。

Step 4: Propose

步骤4：提出方案

Present a lightweight plan. Short — not a full spec:

undefined

呈现一个轻量化的计划。简短——无需完整规格：

undefined

Proposed Approach

拟议方案

What: {1-2 sentence description of what we're building/changing} How: {brief description of approach — key decisions only} Assumptions: {any assumptions made where questions weren't asked} Files: {list of files to create or modify} Context loaded: {key standards files found, or "none — using general best practices"} External docs needed: {any library docs to fetch first, or "none"}

Approve or let me know what to adjust.


**If context was missing or minimal**, append this hint at the end of the proposal — do not replace or interrupt the proposal, just add it after:

💡 Tip: For better results tailored to your project's standards, run /install-context to set up context files. This helps me follow your coding conventions automatically.

undefined

内容: {1-2句话描述我们要构建/修改的内容} 方式: {简要描述方案——仅关键决策} 假设: {未询问问题时做出的任何假设} 文件: {要创建或修改的文件列表} 加载的上下文: {找到的关键标准文件，或“无——采用通用最佳实践”} 所需外部文档: {需要先获取的库文档，或“无”}

请批准或告知我需要调整的内容。


**如果上下文缺失或极少**，在方案末尾添加以下提示——不要替换或打断方案，只需追加在后面：

💡 提示：为了获得更贴合你项目标准的结果，请运行/install-context来设置上下文文件。这有助于我自动遵循你的编码规范。

undefined

Step 5: Get Approval

步骤5：获得批准

Wait for the user to approve or adjust. If they adjust, update the proposal and ask again. Do not start implementation until explicitly approved.

等待用户批准或调整方案。如果用户提出调整，更新方案后再次询问。在获得明确批准前，请勿开始实现。

Step 6: Hand Off to Implementation

步骤6：移交至实现环节

Once approved:

Simple (1–3 files, straightforward): implement directly
Complex (4+ files, multiple components): invoke
```
oac:task-breakdown
```
to create subtasks first

获得批准后：

简单任务（1-3个文件，流程直接）：直接实现
复杂任务（4个及以上文件，涉及多个组件）：先调用
```
oac:task-breakdown
```
创建子任务

Key Principles

核心原则

Fast — Understand from the message, don't interrogate the user up front
Context first — Always attempt discovery before proposing
No context = hint, not block — Show the install tip at the bottom of the proposal, never before it
Explicit questions — If you must ask, say what you need and why — not "tell me more"
Assumptions over questions — State assumptions in proposal rather than asking for every detail
Concise proposal — A paragraph, not a doc; enough for yes/no/adjust
YAGNI — Propose the minimum that satisfies the requirement

高效——从消息中理解需求，不要一开始就追问用户
上下文优先——提出方案前始终尝试发掘上下文
无上下文=提示，而非阻塞——在方案底部显示安装提示，不要提前显示
明确问题——如果必须询问，说明你需要什么以及原因——不要说“告诉我更多”
假设优先于询问——在方案中说明假设，而非询问每个细节
简洁方案——一段内容即可，无需完整文档；足够用于批准/拒绝/调整
YAGNI——提出满足需求的最小方案