メニュー
Analyze two functional specs from a ***plain spec file to determine if they conflict. Use when the user wants to check whether two specific functional requirements are compatible, or when debugging a suspected conflict between two specs.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Authors and structures professional-grade agent skills following the agentskills.io spec. Use when creating new skill directories, drafting procedural instructions, or optimizing metadata for discoverability. Don't use for general documentation, non-agentic library code, or README files.
Add acceptance tests under a functional spec in a ***plain spec file. Use when the user wants to add verification criteria for a specific functional spec, or after adding a functional spec that needs testable success criteria.
Add a concept to the ***definitions*** section of a ***plain spec file. Use when the user wants to define a new concept, entity, or domain term in a .plain file.
End-to-end feature addition on an existing ***plain project: runs a short feature-intent interview, then takes the confirmed request and, one question at a time, incrementally writes ***plain specs (concepts, implementation reqs, functional specs, test reqs, acceptance tests) to disk — asking, authoring, and reviewing per functionality — then closes with a plain-healthcheck gate. Use when the user wants to add a feature to an existing project. Not for bootstrapping a new project from scratch (use forge-plain) or for editing generated code (the .plain specs are the source of truth).
Add a single functional spec to the ***functional specs*** section of a ***plain spec file. Use whenever exactly one new functional spec is being added — whether the user explicitly asks, or another skill/workflow (e.g. forge-plain, add-feature) needs to author a new functional spec. Every new entry under ***functional specs*** must go through either this skill or `add-functional-specs` (the bulk variant for adding multiple specs in one pass); hand-authoring functional specs without invoking one of these skills is forbidden.
Add multiple functional specs to the ***functional specs*** section of a ***plain spec file in a single batch. Use whenever more than one new functional spec is being added — whether the user explicitly asks, or another skill/workflow (e.g. forge-plain, add-feature) needs to author several specs in one pass. Bulk-writing or hand-authoring functional specs without invoking this skill is forbidden; for adding a single spec, use add-functional-spec instead.
| name | analyze-2-func-specs |
| description | Analyze two functional specs from a ***plain spec file to determine if they conflict. Use when the user wants to check whether two specific functional requirements are compatible, or when debugging a suspected conflict between two specs. |
Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet.
Two functional specs from a .plain file (or across requires modules). The user provides them directly or points to them by location in a file.
***definitions*** section so all referenced :Concepts: are understood.COMPATIBLE or CONFLICTING. No reasoning, no category labels, no resolution suggestions.Work through each question. If any answer is "yes", the specs likely conflict.
Do the two specs make mutually exclusive assertions about the same behavior?
Spec A: :Resource: items are returned sorted by name in ascending order.
Spec B: :Resource: items are returned 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.
Does one spec set a state or value that the other spec assumes is different?
Spec A: :TaskList: is initially empty.
Spec B: :TaskList: contains a default "Welcome" :Task: on first load.
Verdict: CONFLICTING — both define the initial state of :TaskList: differently.
Does the later spec silently replace behavior established by the earlier spec without acknowledging it?
Spec A: :User: credentials are validated using an API key.
Spec B: :User: credentials are validated using OAuth 2.0.
Verdict: CONFLICTING — both define the authentication mechanism but pick
different approaches. The later spec overrides the earlier one.
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: All :Resource: items are returned.
Spec B: Only active :Resource: items are returned.
Verdict: CONFLICTING (ambiguous) — "all" vs "only active" appear contradictory.
Could be resolved by scoping each to different conditions (e.g., filtered vs unfiltered).
Do both specs impose constraints on the same :Concept: that cannot coexist?
Spec A: :BatchSize: is 100 items.
Spec B: :BatchSize: is 50 items for :Resource: types with attachments.
Verdict: COMPATIBLE — Spec B adds a conditional refinement, not a contradiction.
The skill emits exactly one of these two strings, with no surrounding text, explanation, category label, or resolution suggestion:
COMPATIBLE
or
CONFLICTING
The internal analysis (checklist, chronological reasoning) informs the verdict but must not appear in the output. The caller decides what to do with the result — typically: act on COMPATIBLE by proceeding, or invoke resolve-spec-conflict on CONFLICTING to produce the actual fix.