Analyze Func Specs

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.

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.

Workflow

1. Read all input specs and the relevant `definitions` so every :Concept: is understood. 2. 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. 3. 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. 4. 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. 5. Record every CONFLICTING pair. Compatible pairs are not listed individually; only the conflicts are emitted. 6. Output the verdict in the format below. No reasoning, no category labels, no resolution suggestions.

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

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.

2. State or Data Conflict

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.

3. Behavioral Override

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.

4. Scope Ambiguity

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).

5. Shared Concept, Different Constraints

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.

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.