Analyze Functional Specs
Always use the skill
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 section to self-check.
- A new spec (or batch of new specs) plus the existing specs from the same file and any 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:
,
,
, …. 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
section (and any imported definitions) so referenced
can be resolved.
Workflow
- Read all input specs and the relevant so every 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 with . Skip pairs where the two specs share no 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 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.
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
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:
If
one or more pairs are conflicting, emit
followed by one line per conflicting pair, in
form (using the identifiers from the input, with
), 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 on each pair).
- If the input contained fewer than two specs, emit (nothing to compare).
- Identifiers must match exactly what the caller provided (or the , , … fallback assigned in step 1).
The internal pairwise analysis informs the verdict but must not appear in the output.