Elixcit turns a business feature, even one described in a single sentence, into a measurable, quality checked work item in your project tool. It does that by interviewing you. The better you start the conversation and answer its questions, the better the ticket. This page shows what good and bad prompts look like, with real examples.
Elixcit is an AI business analyst. It interviews you about the business feature you need, turns it into a well defined, measurable requirement, and then creates the right work item plus its discipline subtasks in your ticketing tool (via MCP). It behaves like a disciplined analyst: it asks targeted questions before it builds anything. The requirement comes first, the ticket second.
Before it asks you anything, it learns from everything it can reach: the existing backlog (prior requirements, conventions, related work), the product codebase (the real modules, architecture and naming), and the business rule documents (underwriting guides, eligibility and validation tables, which is where the actual thresholds live). It asks only the questions none of those sources can answer, and it cites real values from the business rules instead of guessing. That way its output is grounded in your actual project, not in generic advice.
When the requirement is solid, it shows you a preview of the ticket exactly as it will look in your project tool. Only after you say yes does it create the work item and its discipline subtasks ([Solution Design], [BE], [FE], [Infrastructure], [Testing], [Business Sign Off]), with Gherkin acceptance criteria attached.
Never a ticket from a vague idea. The requirement is drafted and validated before anything is created.
If something is unclear, it asks you a targeted question instead of guessing. Unknowns are recorded, never made up.
A ticket is only created after the requirement passes a quality checklist and you explicitly confirm.
Backlog, codebase and business rules are read first; acceptance criteria cite the real thresholds and values.
When it proposes something, it names the source in the same breath: a business rule document ("the eligibility workbook caps this at 21"), the codebase ("the admin dashboard already has a roles table") or an existing ticket. If nothing backs it, it is labelled as an assumption for you to confirm.
Have a design link? Share it. It's used for context and attached to the ticket.
Every run yields the ticket(s) and Gherkin acceptance criteria the team reuses directly for testing.
Elixcit follows a fixed, auditable sequence. Two gates control progress: the quality check and your explicit approval. Failing a gate loops back to more questions, never forward to an unfinished ticket.
Pick a direction on the welcome screen: Business requirement (questions in business language; uses the backlog and business rules only at first — lower token use, recommended) or Technical implementation (scans the codebase from the start for tech leads — higher token use; the app asks you to confirm before selecting it). Then describe the requirement in a sentence, or paste an existing ticket link to analyse and improve it.
Before asking you anything, it searches the backlog for duplicates and related tickets and reads the business rule documents. For Technical implementation it also scans relevant parts of the product code from the start; for Business requirement the codebase is used later, when drafting the Solution Design subtask. What it finds shapes the questions, and you'll notice it citing what it found ("I see an existing roles table…", "the eligibility workbook caps this at…").
Targeted questions, a few at a time, usually as numbered options. They cover only the genuine gaps the sources couldn't answer: success criteria, edge and error cases, who's allowed to do what, scope boundaries. "I don't know" is a valid answer: it's recorded as an open question for Solution Design, never guessed. If your answers contradict each other, it surfaces the conflict openly instead of silently picking a side.
The draft is validated against a quality checklist: clear scope, testable, nothing critical missing. The acceptance criteria are written as Gherkin scenarios (Given / When / Then) covering every rule and boundary, with the real values cited from the business rules.
You get a preview of the ticket(s) exactly as they will appear in your project tool: type and summary, description, Gherkin acceptance criteria and the subtasks table. The preview is just a draft in chat, no ticket exists yet. Ask for changes as many times as you like.
The work item and its discipline subtasks are created, the acceptance criteria travel with the ticket (and as a .feature file for the test suite), and a record of the whole interview is attached as a comment so every decision is auditable. You get the ticket links back in chat.
After a business requirement: Elixcit asks whether you want the technical breakdown for the team prepared now. If yes, it scans the codebase and updates the existing subtasks — [Solution Design], [BE], [FE], [Infrastructure], [Testing] — with implementation-ready detail (preview + your approval before anything is written to the ticketing tool).
Starting with technical implementation: it first searches for an existing business requirement for the same feature. If one exists, it offers to update that ticket's subtasks instead of creating a duplicate.
[Solution Design], [BE], [FE], [Infrastructure], [Testing], [Business Sign Off]..feature file QA can bind automated tests to.You can write in Croatian or any other language and Elixcit will understand you, but it always answers in English. Tickets and acceptance criteria are always written in English.
A good opening prompt names who needs what capability and why. You don't need to know the technical details, that's what the interview is for.
[Solution Design] subtask for the tech lead.None of these are "wrong" and the interview will eventually recover, but they waste your message budget on questions you could have avoided.
[Solution Design]. (If you genuinely want an engineering task, pick the Technical implementation direction.)[Solution Design], it is never guessed.| Guideline | |
|---|---|
| Do | One requirement per conversation; start a new conversation for the next one. |
| Do | Name the actor, the capability and the business outcome in your first message. |
| Do | Paste ticket links to analyse or improve existing tickets, and name business rule documents when relevant. |
| Do | Say "I don't know" when you don't. It gets recorded, not invented. |
| Do | Review the preview critically before approving; iterate as often as needed. |
| Don't | Bundle several features into one prompt. |
| Don't | Prescribe the implementation when you mean a business requirement. |
| Don't | Paste real customer data, passwords or API keys. Ever. |
| Don't | Ask it to write code, estimate story points or deploy anything. |
| Don't | Approve a preview you haven't read. Approval is the moment tickets get created. |
| Situation | What's going on |
|---|---|
| "Message limit reached (30/hour)" | Each user can send 30 messages per hour, as a fairness and cost guard. Take a break and continue; your conversation is kept for an hour. |
| Technical direction confirmation | Choosing Technical implementation triggers a warning: scanning the codebase uses more AI tokens and costs more than Business requirement. Confirm only if you need the ticket grounded in code now. |
| "This conversation is very long" | Conversations cap at 40 messages. Approve or wrap up, then start a New conversation. Long threads produce worse tickets anyway. |
| "Daily message budget" reached | The whole service has a daily cap. Try again tomorrow, or ask the team to raise it. |
| Business then tech (or the reverse) | After a business requirement is created, Elixcit asks if you want the BE/FE/Infra subtasks filled in from the codebase. With technical implementation, it searches for an existing business ticket first and offers to update it instead of duplicating. |
| Logged out unexpectedly | Login tokens last 12 hours, and a service restart logs everyone out. Just log in again. An unfinished conversation is lost, but any created tickets are already in your project tool. |
| "Ticketing tool not connected" pill | Elixcit still works fully; instead of creating tickets it gives you markdown you can paste straight into your project tool. |
| It created something wrong | Tell it in chat and it will transition the item to Cancelled and note it (deletion is often not permitted in project tools). Every item it creates carries the agent's provenance label, so it's always identifiable. |