---
name: seviaflow-app-discovery
description: "Use when someone has a new or unclear application idea and needs an interactive, beginner-friendly interview to define the problem, users, workflows, data, rules, and a buildable MVP before coding."
---

# SeviaFlow App Discovery

Turn an initial idea into a shared application brief. Interview the user in small steps, uncover missing requirements, and write down decisions so the next planning or implementation step does not have to guess.

## How to work

1. Read the conversation first. Reuse details the user has already given; do not ask them again.
2. If a code repository is open, inspect its README, existing product docs, composer.json, composer.lock, and relevant existing features before asking questions that the code can answer.
3. Start with the user's goal and the people who need the application. If the goal is unclear, ask one short question such as: What should someone be able to accomplish with this app that they cannot do easily today?
4. Ask no more than three related questions in one message. Prefer one question when the user is new to product design. Explain unfamiliar terms in everyday language.
5. Use follow-up questions to resolve ambiguity, contradictions, important edge cases, and assumptions. Do not deliver a large generic questionnaire.
6. Offer a small example or choices when that makes a question easier to answer. Make clear when a choice is only a suggestion.
7. Keep interviewing until the core behaviors and important risks are understood. If a detail is low-impact, propose a clearly labeled default instead of blocking progress.
8. Do not edit code during discovery unless the user asks you to implement. If the user has already asked for implementation, ask only the questions that could materially change the design, then continue with reasonable explicit assumptions.

## Topics to discover

Explore these topics as they apply to the idea. Follow the user's answers; do not force every topic into every project.

- The problem, intended outcome, and how success will be recognized.
- People and roles: who uses the app, what each person can see or change, and whether customers or external systems also interact with it.
- Everyday scenarios: the main task from start to finish, including alternate and failure paths.
- Business data: records, important fields, relationships, ownership, status, and which system is the source of truth.
- Rules: validation, approvals, calculations, state changes, audit needs, and notifications.
- Surfaces: operator screens, forms, lists, search, filters, dashboards, reports, imports, exports, and API integrations.
- Access and privacy: sensitive data, tenant boundaries, retention, and operations that must be restricted.
- Constraints: existing Laravel application or greenfield project, installed SeviaFlow packages and version, database, hosting, integrations, deadline, and what is explicitly out of scope.

## Keep the interview useful

Ask for concrete examples. Instead of asking only “What fields do you need?”, ask what information an operator must see to complete a real task. Instead of asking only “Do you need workflows?”, ask what happens after a record is submitted, who decides the next step, and what states the record can have.

Probe a requirement with a short scenario when needed:

- What happens when two people edit the same record?
- Can a user see records belonging to another customer or organization?
- What should happen when a payment, email, import, or external API call fails?
- Which changes need approval or an audit trail?

Separate facts supplied by the user from assumptions and suggestions. Do not turn a possible future feature into an MVP requirement without asking.

## Final deliverable

When there is enough information, produce a concise application brief with:

1. Goal and intended users.
2. Main user scenarios and acceptance criteria.
3. Roles and access boundaries.
4. Proposed data records, fields, relationships, and lifecycle.
5. Required screens and integrations.
6. MVP scope and explicit non-goals.
7. Important risks, unanswered questions, and any assumptions.

State which points come directly from the user and which are recommendations. This brief should be detailed enough for the SeviaFlow App Planner to map it into Resources and implementation stages.