# Requirements Elicitation Skill

## Purpose
This skill defines the requirements template fields and the rules for filling them.
It governs what each field means, what a valid answer looks like, and how fields
transition between states. Completion logic and the dialogue loop are defined in the
system prompt.

## Template Fields

### BUSINESS_PROBLEM (mandatory)
What business problem or opportunity does this address?
- Stated from a business perspective — not a technical one.
- One to three sentences.
- A correct answer describes a real-world problem, gap, or need.
- An incorrect answer describes a solution, deliverable, or technical artifact.
- Wrong: "We need DnAML definitions for a Gold Layer Star Schema."
- Right: "The sales team cannot currently analyze order profitability by customer region
  across different time periods in a single view."

### DECISION_SUPPORTED (mandatory)
Which business decisions will this result enable, and who makes them?
- Names a concrete decision and a concrete decision-maker.
- Wrong: "The output will be consumed by BI tools."
- Right: "The sales director uses monthly profitability reports to decide which customer
  segments to prioritize for the coming quarter."

### SUCCESS_CRITERIA (mandatory)
How will the user verify the result is correct and complete?
- Measurable and testable from a business perspective — without reading code or schemas.
- Wrong: "All DnAML definitions are written and syntactically valid."
- Right: "The sales team can answer questions A, B, and C from the result without
  additional data manipulation or technical assistance."

### SCOPE_OUT (mandatory)
What is explicitly NOT part of this phase?
- Even if nothing is excluded, this must be confirmed explicitly.
- Prevents scope creep in downstream agents.

### CONSTRAINTS (mandatory)
What rules, naming conventions, or limitations must be respected?
- Technical, organizational, regulatory, or timing constraints.
- Even if there are no special constraints, this must be confirmed explicitly.

### OPEN_ITEMS (optional)
What is still unclear or will be decided during the project?
- May be empty. If empty, confirm that nothing is currently open.

## Field state transitions

OPEN → EXTRACTED: Agent infers a candidate answer from user input.
EXTRACTED → CONFIRMED: User accepts the agent's paraphrase of the candidate.
OPEN → CONFIRMED: User directly answers a question and accepts the paraphrase.

## Batch confirmation — Variant B

When multiple fields are EXTRACTED from a single user message or document:
- Group them into one confirmation question.
- List each field with its extracted candidate value.
- Ask: "Does this accurately capture these points, or would you like to adjust anything?"
- On acceptance: all listed fields become CONFIRMED simultaneously.
- On partial correction: update the corrected field, confirm the corrected value separately,
  leave the others as CONFIRMED.

## What makes an answer invalid for a field

Do not mark a field as EXTRACTED if the candidate answer:
- Describes a technical artifact instead of a business reality.
- Is so vague it cannot be used to evaluate the final result.
- Describes a solution rather than a need.
- Uses undefined terms that the user has not explained.

In these cases: leave the field OPEN and ask a direct clarifying question.

## Questioning technique

- Ask one question per message.
- Start with open questions to understand the full picture, then use closed questions to
  confirm specific details.
- After each answer, paraphrase what you understood before marking a field as CONFIRMED.
- If the user introduces new topics mid-dialogue, note them as potential OPEN_ITEMS
  — do not expand scope without explicit agreement.
