Gathering and Elaborating Requirements

After initiation (charter, contract, scope), the most substantial phase begins — requirements. In the system, it is built around the living BRD: a document that grows with the project and always reflects what is settled and what is still open.

Prerequisites: the charter and scope — see Project initiation.

Step 1. BRD kickoff: /requirements

Type /requirements. The agent:

1. Reads the charter, scope, and, if present, the contract analysis.
2. Searches the Confluence knowledge base for reusable requirements, specifications, and roadmaps of the project.
3. Proposes the BRD structure — by scope blocks, with common sections. The structure can be edited: drop blocks, add your own.
4. After your confirmation, creates the BRD as a working document: each block gets its subsections — destination, open decisions, not yet specified, out of scope, functional and non-functional requirements, acceptance criteria.

The file is not created before the structure is confirmed — the agent does not write the BRD "on a guess".

Step 2. Map of unknowns: /elicit

Requirements rarely arrive ready-made. Type /elicit — the agent builds a map of unknowns by block:

• Open decisions — sharp questions that can already be phrased ("what response latency is acceptable?").
• Not yet specified — uncertainties that cannot yet be phrased as a question.
• Out of scope — what is explicitly excluded for the block.

Everything is recorded in the BRD as review blocks. The chart is not a tracker task list: it lives in the document and updates as decisions are made.

Step 3. Decision drill-down: /question

When a question becomes sharp, type /question — the agent runs a detailed interview, one decision at a time:

• questions are asked one at a time, pausing for your answer;
• for each question the agent gives a recommended option — you confirm or adjust it;
• facts that can be found in the system (issues, pages, documents) the agent looks up itself instead of asking;
• decisions belong to you: the agent does not close a decision without your answer.

Once shared understanding is reached, the agent summarizes the agreement and lands it in the BRD: the item moves from "open decisions" to "decisions" with a one-line gist. The next decision is a new /question pass.

Step 4. Specification: /specify

When a block's requirements are sufficient, type /specify. The agent does not re-interview — it synthesizes what is already settled into an implementation specification (implementation-spec.md):

• the problem and solution from the user's perspective;
• an extensive user-story list;
• implementation decisions (modules, interfaces, architecture) — without file paths that go stale fast;
• testing decisions;
• what is explicitly out of scope;
• source references: BRD, charter, scope, Confluence pages.

If the block still lacks concrete requirements and criteria, the agent stops and offers /elicit / /question first — it does not write a template from thin air.

Step 5. Tickets: /tickets

Type /tickets — the agent breaks the specification (or a ready BRD slice) into vertical slices:

• each slice cuts a complete path through all layers (data, logic, UI, tests) and, when done, is demoable;
• each slice is sized to fit a single working session;
• every ticket has dependencies: which tickets must finish first ("blocked by");
• before publishing, the agent shows the breakdown and checks: granularity, correct dependencies, what to merge or split.

Publishing happens only through your confirmation: each ticket is created as a proposal in the tracker (you can open it in the issue editor, adjust fields, and only then create it). After creation, the agent offers a back-link from the ticket into the specification/BRD — so the document and the tracker do not drift apart.

How it becomes a cycle

/scope (done)
  → /requirements — BRD structure and skeleton
  → /elicit — map of unknowns by block
  → /question — decision by decision (until the unknowns are cleared)
  → /specify — specification for ready blocks
  → /tickets — tickets from the specification
  → (next: estimation and planning — see the next guide)

What the agent does not do

• Does not create tickets silently — every tracker publish is through your confirmation.
• Does not invent requirements — when the seeds (charter, scope, Confluence) are insufficient, the agent says what is missing instead of filling the document from memory.
• Does not mix levels — scope does not become a task list, and the BRD does not become a technical specification: each document has its own level of detail.

Where to continue

• Schedule planning — estimation, work structure, and the plan.
• Project documents: creation and upkeep — how the created documents live.