analyze-func-specs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Analyze Functional Specs

分析功能规格

Always use the skill

load-plain-reference

to retrieve the ***plain syntax rules — but only if you haven't done so yet.

请始终使用技能

load-plain-reference

来获取***纯语法规则——但仅在尚未获取过的情况下执行此操作。

Input

输入

A set of two or more functional specs to check against each other. Callers typically supply one of:

A whole
```
***functional specs***
```
section to self-check.
A new spec (or batch of new specs) plus the existing specs from the same file and any
```
requires
```
modules.
An explicit list of spec snippets the user wants compared.

Each spec must be identifiable. If the caller didn't label them, assign stable identifiers in order of appearance:

S1

S2

S3

, …. Use those identifiers in the output. If the caller provided their own IDs or quoted snippets, use those instead and keep them verbatim.

The skill also needs the

***definitions***

section (and any imported definitions) so referenced

:Concepts:

can be resolved.

一组两个或更多的功能规格，用于相互检查。调用者通常会提供以下内容之一：

完整的
```
***functional specs***
```
部分，用于自我检查。
一个新规格（或一批新规格）加上同一文件中的现有规格以及所有
```
requires
```
模块中的规格。
用户想要对比的规格片段的明确列表。

每个规格必须可识别。如果调用者未给它们添加标签，请按照出现顺序分配稳定标识符：

S1

、

S2

、

S3

……并在输出中使用这些标识符。如果调用者提供了自己的ID或引用片段，请直接使用这些内容，不要修改。

该技能还需要

***definitions***

部分（以及所有导入的定义），以便解析引用的

:Concept:

。

Workflow

工作流程

Read all input specs and the relevant
***definitions***
so every
```
:Concept:
```
is understood.
Establish chronological order across the batch. Earlier specs are considered to have been rendered first; later specs are evaluated with the earlier ones in context. If the caller already provided an order, preserve it.
Generate the pair list. Enumerate every unordered pair
```
(Sᵢ, Sⱼ)
```
with
```
i < j
```
. Skip pairs where the two specs share no
```
:Concept:
```
and no overlapping subject — they are trivially compatible and listing them adds noise.
Run the conflict analysis below on each remaining pair. Use the same checklist that the legacy
```
analyze-2-func-specs
```
skill used, but apply it pair by pair across the batch in a single pass — do not require the caller to invoke the analyzer once per pair.
Record every CONFLICTING pair. Compatible pairs are not listed individually; only the conflicts are emitted.
Output the verdict in the format below. No reasoning, no category labels, no resolution suggestions.

读取所有输入规格和相关的
***definitions***
，确保理解每个
```
:Concept:
```
。
确定批次内的时间顺序。较早的规格视为先被呈现；较晚的规格需结合较早的规格进行评估。如果调用者已指定顺序，请保留该顺序。
生成规格对列表。枚举所有无序对
```
(Sᵢ, Sⱼ)
```
，其中
```
i < j
```
。跳过那些既不共享
```
:Concept:
```
也没有重叠主题的规格对——它们显然兼容，列出它们只会增加干扰。
对剩余的每个规格对执行以下冲突分析。使用与旧版
```
analyze-2-func-specs
```
技能相同的检查清单，但在单次处理中逐对应用于整个批次——无需调用者为每个规格对单独调用分析器。
记录所有冲突的规格对。兼容的规格对无需单独列出；仅输出冲突的规格对。
按照以下格式输出结论。无需提供推理、类别标签或解决建议。

Conflict Analysis Checklist (applied per pair)

冲突分析检查清单（逐对应用）

Work through each question for the pair under inspection. If any answer is "yes", that pair is CONFLICTING.

针对当前检查的规格对，逐一回答以下问题。如果任何问题的答案为“是”，则该规格对存在冲突。

1. Direct Contradiction

1. 直接矛盾

Do the two specs make mutually exclusive assertions about the same behavior?

Spec A: The system should return :Resource: items sorted by name in ascending order.
Spec B: The system should return :Resource: items sorted by creation date in descending order.

Verdict: CONFLICTING — both define the sort order for the same response,
but specify different fields and directions. A single implementation cannot
satisfy both unless scoped to different contexts.

两个规格是否对同一行为做出了互斥的断言？

Spec A: 系统应返回按名称升序排序的:Resource:项。
Spec B: 系统应返回按创建日期降序排序的:Resource:项。

Verdict: CONFLICTING — 两者都定义了同一响应的排序规则，但指定了不同的字段和排序方向。除非限定在不同的上下文环境中，否则单一实现无法同时满足两者。

2. State or Data Conflict

2. 状态或数据冲突

Does one spec set a state or value that the other spec assumes is different?

Spec A: :TaskList: should initially be empty.
Spec B: :TaskList: should contain a default "Welcome" :Task: on first load.

Verdict: CONFLICTING — both define the initial state of :TaskList: differently.

一个规格设置的状态或值是否与另一个规格假设的状态或值不同？

Spec A: :TaskList:初始应为空。
Spec B: :TaskList:在首次加载时应包含默认的"Welcome":Task:。

Verdict: CONFLICTING — 两者对:TaskList:的初始状态定义不同。

3. Behavioral Override

3. 行为覆盖

Does the later spec silently replace behavior established by the earlier spec without acknowledging it?

Spec A: The system should validate :User: credentials using an API key.
Spec B: The system should validate :User: credentials using OAuth 2.0.

Verdict: CONFLICTING — both define the authentication mechanism but pick
different approaches. The later spec overrides the earlier one.

较晚的规格是否在未声明的情况下替换了较早规格确立的行为？

Spec A: 系统应使用API密钥验证:User:凭据。
Spec B: 系统应使用OAuth 2.0验证:User:凭据。

Verdict: CONFLICTING — 两者都定义了身份验证机制，但选择了不同的方式。较晚的规格覆盖了较早的规格。

4. Scope Ambiguity

4. 范围歧义

Are the two specs ambiguous enough that a renderer could interpret them as conflicting, even if the user intends them to be complementary?

Spec A: The system should return all :Resource: items.
Spec B: The system should return only active :Resource: items.

Verdict: CONFLICTING (ambiguous) — "all" vs "only active" appear contradictory.
Could be resolved by scoping each to different conditions (e.g., filtered vs unfiltered).

两个规格是否存在足够的歧义，导致呈现者可能将其解释为冲突，即使用户意图是让它们互补？

Spec A: 系统应返回所有:Resource:项。
Spec B: 系统应仅返回活跃的:Resource:项。

Verdict: CONFLICTING (ambiguous) — "所有"与"仅活跃"看似矛盾。可通过为每个规格限定不同条件（例如，过滤后与未过滤）来解决。

5. Shared Concept, Different Constraints

5. 共享概念，不同约束

Do both specs impose constraints on the same

:Concept:

that cannot coexist?

Spec A: :BatchSize: should be 100 items.
Spec B: :BatchSize: should be 50 items for :Resource: types with attachments.

Verdict: COMPATIBLE — Spec B adds a conditional refinement, not a contradiction.

两个规格是否对同一

:Concept:

施加了无法共存的约束？

Spec A: :BatchSize:应为100项。
Spec B: 对于带有附件的:Resource:类型，:BatchSize:应为50项。

Verdict: COMPATIBLE — Spec B添加了一个条件细化，而非矛盾。

Output Format

输出格式

Emit exactly one of the two shapes below, with no surrounding text, explanation, category label, or resolution suggestion.

If no pair is conflicting:

COMPATIBLE

If one or more pairs are conflicting, emit

CONFLICTING

followed by one line per conflicting pair, in

Sᵢ x Sⱼ

form (using the identifiers from the input, with

i < j

), sorted lexicographically:

CONFLICTING
S1 x S4
S2 x S3
S3 x S5

Rules for the output:

Do not list compatible pairs.
Do not include reasoning, checklist categories, or fixes — the caller decides what to do with each conflict (typically: invoke
```
resolve-spec-conflict
```
on each pair).
If the input contained fewer than two specs, emit
```
COMPATIBLE
```
(nothing to compare).
Identifiers must match exactly what the caller provided (or the
```
S1
```
,
```
S2
```
, … fallback assigned in step 1).

The internal pairwise analysis informs the verdict but must not appear in the output.

请严格输出以下两种格式之一，不要添加任何周围文本、解释、类别标签或解决建议。

如果没有规格对存在冲突：

COMPATIBLE

如果一个或多个规格对存在冲突，请输出

CONFLICTING

，后跟每一个冲突规格对的行，格式为

Sᵢ x Sⱼ

（使用输入中的标识符，且

i < j

），按字典序排序：

CONFLICTING
S1 x S4
S2 x S3
S3 x S5

输出规则：

不要列出兼容的规格对。
不要包含推理、检查清单类别或修复方案——调用者会决定如何处理每个冲突（通常是对每个冲突对调用
```
resolve-spec-conflict
```
）。
如果输入的规格数量少于两个，请输出
```
COMPATIBLE
```
（无可对比内容）。
标识符必须与调用者提供的完全一致（或使用步骤1中分配的
```
S1
```
、
```
S2
```
……作为备用）。

内部的逐对分析用于得出结论，但不得出现在输出中。