decision-evaluation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Decision Evaluation

决策评估

Overview

概述

This skill evaluates one explicit design decision at a time.

It does not discover the whole design. It does not validate overall readiness. Its job is to compare real options for a bounded decision node and produce a recommendation with reasons.

本Skill每次评估一个明确的设计决策。

它不负责探索整体设计，也不验证整体就绪状态。其职责是针对有限范围的决策节点对比实际选项，并给出带有理由的推荐。

When to Use

使用场景

Use this skill when:

the design already contains a concrete decision node
the user is effectively asking "which of these approaches should we choose?"
the decision will materially affect architecture, implementation path, compatibility, cost, or operational risk

Typical examples include:

auth model
coordination pattern
storage strategy
sync model
state management approach
retry or execution model
workflow rollback policy
workflow approval strategy
methodology stop condition
methodology evidence threshold
framework routing rule
framework handoff contract
language or runtime selection
UI framework selection
data-layer library (ORM, query builder, validation) selection
tooling selection (bundler, linter, test runner, CI platform)

Do not use this skill when:

the design tree is not formed yet
the task is still broad design discovery
the main need is deeper refinement rather than bounded comparison
the task is a final readiness gate

在以下场景中使用本Skill：

设计中已包含具体的决策节点
用户实际询问的是“我们应该选择这些方案中的哪一个？”
该决策将对架构、实现路径、兼容性、成本或运营风险产生实质性影响

典型示例包括：

认证模型
协调模式
存储策略
同步模型
状态管理方案
重试或执行模型
工作流回滚策略
工作流审批策略
方法论终止条件
方法论证据阈值
框架路由规则
框架切换契约
语言或运行时选择
UI框架选择
数据层库（ORM、查询构建器、验证工具）选择
工具选型（打包器、代码检查器、测试运行器、CI平台）

请勿在以下场景中使用本Skill：

设计树尚未形成
任务仍处于宽泛的设计探索阶段
主要需求是深度细化而非有限范围对比
任务是最终就绪检查

Constraint Gathering

约束收集

When the decision involves technology selection (language, framework, library, or tooling), perform this step before the formal comparison.

Ask the user to confirm:

Hard constraints: existing tech stack, license requirements, budget limits, deployment environment restrictions.
Preferences or already-excluded options.
Priority of evaluation dimensions (e.g., performance > ecosystem > learning curve).
Must-have requirements (TypeScript support, SSR capability, plugin system, etc.).

Filter the candidate list based on confirmed constraints. Only feasible options proceed to formal comparison.

Output: confirmed constraints + filtered candidate list.

When the decision is non-technical but still bounded, do not force technology-selection questions. Instead confirm the decision boundary, real alternatives, and the dimensions that matter for this workflow, methodology, or framework choice.

当决策涉及技术选型（语言、框架、库或工具）时，在正式对比前执行此步骤。

请用户确认：

硬性约束：现有技术栈、许可证要求、预算限制、部署环境限制。
偏好或已排除的选项。
评估维度的优先级（例如：性能 > 生态系统 > 学习曲线）。
必备需求（TypeScript支持、SSR能力、插件系统等）。

根据确认的约束过滤候选列表。仅保留可行选项进入正式对比。

输出：确认的约束 + 过滤后的候选列表。

当决策为非技术性但仍属于有限范围时，请勿强制询问技术选型相关问题。而是确认决策边界、实际替代方案，以及对该工作流、方法论或框架选择至关重要的评估维度。

Core Responsibilities

核心职责

Your responsibilities are:

Frame the exact decision question. For technology selections, frame the question based on constraints confirmed in the Constraint Gathering step.
Keep the work bounded to one explicit decision node.
Present 3 to 4 real options when real options exist.
Compare trade-offs clearly and concretely.
Recommend one option or a justified combination when appropriate.
Explain why the rejected options are not preferred in this context.
Record the result in a reusable decision record.

你的职责包括：

明确决策问题。对于技术选型，基于约束收集步骤中确认的约束来构建问题。
确保工作范围限定在单个明确的决策节点内。
当存在实际选项时，列出3至4个真实选项。
清晰、具体地对比各选项的权衡关系。
推荐一个选项，或在合适情况下推荐合理的组合方案。
解释为何在当前场景下不优先考虑被否决的选项。
将结果记录在可复用的决策记录中。

Comparison Standard

对比标准

Compare options using the dimensions that matter to the decision. These often include:

implementation complexity
compatibility with the current system
operational risk
performance
maintainability
future flexibility
debugging and observability implications

Do not force every dimension into every decision. Use only the ones that actually matter.

使用与决策相关的维度对比选项，这些维度通常包括：

实现复杂度
与当前系统的兼容性
运营风险
性能
可维护性
未来灵活性
调试与可观测性影响

无需在每个决策中都覆盖所有维度，仅使用实际相关的维度即可。

Expected Outputs

预期输出

Produce or update a

design_state

that includes:

```
design_target_type
```
```
decision_nodes
```
```
decisions
```
```
risks
```
optional downstream impact notes for the design tree

生成或更新包含以下内容的

design_state

：

```
design_target_type
```
```
decision_nodes
```
```
decisions
```
```
risks
```
可选的设计树下游影响说明

Diagram Conventions

图表规范

Use character diagrams inside code blocks (no language tag) to visualize trade-offs and architecture topology.

在代码块（无语言标签）中使用字符图表可视化权衡关系和架构拓扑。

Star Ratings

星级评分

Use when comparing 3+ options across 2+ quantitative dimensions.

Overall Rating:

Auth0:      ★★★★☆  4/5
Keycloak:   ★★★☆☆  3/5
Self-build: ★☆☆☆☆  1/5

Dimension Breakdown:

Security:       Auth0 ★★★★★  Keycloak ★★★★☆  Self ★★☆☆☆
Speed-to-MVP:   Auth0 ★★★★★  Keycloak ★★★☆☆  Self ★☆☆☆☆
Cost-at-scale:  Auth0 ★★★☆☆  Keycloak ★★★★☆  Self ★★★★★

Rules:

```
★
```
(filled, U+2605) +
```
☆
```
(empty, U+2606), 5-star scale (max = ★★★★★)
Format:
```
label ★★★★☆  4/5
```
Always show all 5 stars (e.g.
```
★★☆☆☆
```
, never
```
★★
```
)
Overall rating section first, then Dimension Breakdown
Breakdown section: one dimension per row, all options on the same row
Always state the scale explicitly

当在2个以上量化维度对比3个以上选项时使用。

Overall Rating:

Auth0:      ★★★★☆  4/5
Keycloak:   ★★★☆☆  3/5
Self-build: ★☆☆☆☆  1/5

Dimension Breakdown:

Security:       Auth0 ★★★★★  Keycloak ★★★★☆  Self ★★☆☆☆
Speed-to-MVP:   Auth0 ★★★★★  Keycloak ★★★☆☆  Self ★☆☆☆☆
Cost-at-scale:  Auth0 ★★★☆☆  Keycloak ★★★★☆  Self ★★★★★

规则：

使用
```
★
```
（实心，U+2605）和
```
☆
```
（空心，U+2606），5星制（满分=★★★★★）
格式：
```
label ★★★★☆  4/5
```
始终显示全部5颗星（例如
```
★★☆☆☆
```
，切勿只写
```
★★
```
）
先显示整体评分部分，再显示维度细分
细分部分：每个维度占一行，所有选项在同一行
始终明确说明评分标准

Architecture Topology

架构拓扑

Use when the decision changes component layout or system topology.

┌──────────────────┐
│  Load Balancer   │
└────────┬─────────┘
         │
    ┌────┴────┐
    ▼         ▼
 [API x2] [API x2]
    │         │
    └────┬────┘
         ▼
  ┌────────────┐
  │  Postgres  │
  └────────────┘

Boxes use
```
┌ ┐ └ ┘ ─ │
```
for infrastructure components
```
[brackets]
```
for application components
Vertical flow primary;
```
──→
```
for horizontal connections

当决策会改变组件布局或系统拓扑时使用。

┌──────────────────┐
│  Load Balancer   │
└────────┬─────────┘
         │
    ┌────┴────┐
    ▼         ▼
 [API x2] [API x2]
    │         │
    └────┬────┘
         ▼
  ┌────────────┐
  │  Postgres  │
  └────────────┘

基础设施组件使用
```
┌ ┐ └ ┘ ─ │
```
绘制方框
应用组件使用
```
[方括号]
```
表示
主要采用垂直流向；水平连接使用
```
──→
```

When to Add Diagrams

何时添加图表

Star ratings: 3+ options × 2+ quantitative dimensions
Topology: the decision changes the physical or logical component layout
Do NOT add diagrams for simple yes/no or qualitative comparisons — use markdown tables
Max width: 78 characters

星级评分：3个以上选项 × 2个以上量化维度
拓扑图：决策会改变物理或逻辑组件布局
简单的是/否或定性对比请勿添加图表——使用Markdown表格
最大宽度：78字符

Entry and Exit Criteria

进入与退出标准

Enter when:

the decision node is explicit and bounded
the decision has at least two meaningful alternatives

Exit when:

there is a clear recommended option
the consequences of that decision are clear enough to feed back into the design

进入条件：

决策节点明确且范围有限
决策至少有两个有意义的替代方案

退出条件：

有明确的推荐选项
该决策的影响足够清晰，可反馈到设计中

Handoff Rules

交接规则

Hand back to
```
design-refinement
```
when the chosen option affects unresolved design branches.
Hand to
```
design-readiness-check
```
when this was the last major unresolved design issue.
Hand back to
```
design-orchestrator
```
if routing should be reconsidered after the decision lands.
Do not force broad design discovery into a bounded decision just to make progress.
Do not take over general design clarification work.

当所选选项影响未解决的设计分支时，交接回
```
design-refinement
```
。
当这是最后一个未解决的重大设计问题时，交接至
```
design-readiness-check
```
。
若决策落地后需要重新考虑路由，交接回
```
design-orchestrator
```
。
请勿为了推进进度而将宽泛的设计探索强行纳入有限范围决策。
请勿接管一般性的设计澄清工作。

Journal Integration

日志集成

When operating on a task tracked under

.agents/tasks/<task-id>/

, append a journal entry at this skill's milestone.

Trigger: after a bounded decision is recommended and recorded
Reserved key(s):
```
decision
```

Entry shape:

## <ISO8601-timestamp> — decision-evaluation
decision: <decision-node-name>
[optional ≤ 15-line body; longer content goes to artifacts/]

Resolve the task id from the explicit caller argument or

.agents/tasks/.current

. If neither resolves, skip the append; do not guess.

See

task-journal

for the full convention.

当处理

.agents/tasks/<task-id>/

下跟踪的任务时，在本Skill的里程碑处追加日志条目。

触发时机： 有限范围决策已被推荐并记录后
预留键：
```
decision
```

条目格式：

## <ISO8601-timestamp> — decision-evaluation
decision: <decision-node-name>
[可选 ≤15行正文；更长内容存入artifacts/]

从明确的调用者参数或

.agents/tasks/.current

解析任务ID。若两者均无法解析，则跳过追加操作；请勿猜测。

有关完整规范，请参考

task-journal

。