AI for Project Documentation: Prompts, Inputs, and a Workflow That Avoids Spec Garbage

By the Smartym Pro team | July 2026

Series: Discovery & documentation (3 parts):

1. Requirements package — what artifacts are and why they matter
2. Discovery process and D1–D11 — how you get there
3. AI for drafts (this article) — prompts, workflow, consistency

---

Introduction

Part 1 describes discovery artifacts — what they are and why. Part 2 covers the process and phased estimation. Here we focus on how to draft that package faster during discovery with AI — without turning your specification into a hallucinated wall of text.

AI works when the model gets structured context and a narrow output task. Garbage appears when you ask for "a full spec from two sentences." Supply facts and format — validate assumptions with humans.

For CTOs, PMs, BAs, and hands-on founders: discovery is underway or done, and you need to speed up packaging — not replace workshops and sign-off.

Series rule: AI accelerates drafts; product owners, BAs, and engineers own validation.

---

Why AI produces "garbage" requirements

Problem	What happens
Vague input	"Build a CRM" with no users, metrics, or integrations
"Full 50-page spec" request	Model invents modules, APIs, integrations
No output format	Prose instead of stories, NFR tables, or MoSCoW
No explicit out of scope	Backlog swells with "just in case" features
Copy-paste without review	Conflicts with compliance, legacy, meeting decisions
One mega-prompt	Scope + stories + NFR + risks at once — quality drops

AI does not replace workshops, stakeholder alignment, or an assumptions register. It removes formatting drudgery after you have facts — or helps surface gaps through clarifying questions.

---

Input checklist (before any prompt)

Prepare a short bullet doc (Notion, Google Doc, paste into chat). Richer input means fewer inventions on output.

#	What to describe
I1	Product one-liner + problem you solve
I2	Target users (2–3 personas, briefly)
I3	Business goals / success metrics
I4	Must-have workflows (list, even raw)
I5	Out of scope (explicit)
I6	Constraints: budget band, timeline, regions, stack (if any)
I7	Integrations: known / unknown
I8	Compliance flags (GDPR, PCI, etc.) — no legal conclusions
I9	Meeting notes or transcript (sanitized, no PII/prod data)
I10	Reference products (UX expectations, not scope copy)

You do not need perfection. If something is missing, the next step is questions from the model, not a finished spec.

---

How to task AI correctly

1. Context as a bundle. Paste I1–I8 in one block; do not make the model guess integrations and NFRs.

2. One artifact at a time. Scope brief first, then stories, then NFR, then risks — not everything in one reply.

3. Fixed output format. Table, user story template, MoSCoW list — state it in the prompt.

4. No inventions. Instructions like: "mark unknowns as [ASSUMPTION]", "do not invent integrations or APIs".

5. Iterate. Draft → gap questions → refine → revised draft.

6. Human gate. BA or tech lead review before client or estimators see it.

7. Security. No secrets, prod data, or PII in public models; anonymize meeting notes.

---

Let AI ask questions first (reverse prompt)

A good workflow starts in interview mode: the model asks clarifying questions until there is enough context for a narrow draft.

Base instruction:

Before producing any document, ask up to 10 clarifying questions about scope, users, integrations, and NFR priorities. Wait for answers. If information is missing, list ASSUMPTIONS.

Question categories (not all required in one prompt):

• Who is the primary user and what job are they hiring the product for?
• What is in MVP vs later phases?
• Which systems integrate on day one?
• What data is PII / regulated?
• Availability and performance expectations (order of magnitude)?
• Who approves scope and accepts releases?
• What is explicitly out of scope?
• What if timeline or budget is halved?
• Legacy: replace or extend?
• What does success look like 90 days after launch?

Capture answers — they feed P2–P6.

---

Prompt library

Prompts below are a starting point. Adapt to your tool (ChatGPT, Claude, Copilot, enterprise LLM) and policy. Placeholders in {{curlies}}. Prompt text in English tends to follow format more reliably; context can be in your team language.

P1 — Clarifying questions only

You are a senior business analyst for custom software projects.
Context: {{paste I1–I8}}
Do not write a specification yet.
Ask up to 10 clarifying questions grouped by: users, scope, integrations, NFR, risks.
Flag any contradictions you see in the context.

P2 — Scope brief (in / out / phases)

Context: {{answers from P1}}
Produce a Scope Brief with sections: Goals, In scope (MVP), Out of scope, Phase 2 ideas, Assumptions.
Use MoSCoW for MVP features. Max 800 words. Mark every assumption with [ASSUMPTION].

P3 — User stories from workflows

Context: {{scope brief from P2}}
For each MVP workflow, write user stories in format:
As a [role], I want [action], so that [outcome].
Include 3–5 acceptance criteria per story (testable).
Do not add features not listed in MVP scope.

P4 — NFR matrix draft

Context: {{scope brief from P2}}
Create an NFR matrix table: Category | Requirement | Priority (Must/Should/Could) | Notes.
Categories: Security, Performance, Availability, Compliance, Observability, i18n, DR.
Mark items needing client decision with [DECISION NEEDED].

P5 — Integration catalog

Known integrations: {{list}}
For each: system, direction (in/out), data objects, protocol (if known), owner, risks.
List [UNKNOWN] where details are missing. Do not invent APIs.

P6 — Risks and assumptions for estimation

Based on: {{scope brief, stories, NFR, integrations}}
Output: Risk register (risk, impact, mitigation) and Assumptions list for estimators.
Separate facts from assumptions. Highlight top 5 estimation risks.

P7 — Meeting notes → structured backlog

Sanitized meeting notes: {{notes}}
Extract: decisions, action items, open questions, candidate user stories.
Do not invent decisions not present in notes. Quote ambiguous phrases as [UNCLEAR].

Prompts do not replace legal compliance review or fixed price without human review.

---

AI for consistency and requirement impact

After drafts (P1–P7), AI is especially useful not for blind test-case generation, but for keeping the package from part 1 consistent.

Consistency across artifacts

The package is several linked files. Typical gaps:

Where	Example
SRS vs flows	Step order differs
Roles vs SRS	Matrix says "manager: all"; story limits access
NFR vs scope	Must-have performance with no load in MVP scope
Integrations vs SRS	API listed but no story for error handling

With full context, the model can compare documents and list contradictions and gaps — humans decide what to change.

What else a requirement affects

When one story, NFR, or integration changes, AI can suggest affected areas: other stories, flows, roles, NFRs, phase estimate. This is impact analysis across artifacts — not a substitute for architecture review.

Example: new profile field → check GDPR/consent, admin panel, API, data migration, related AC.

What does not work: "generate tests and do not read"

Asking AI to dump test cases from a raw spec without review is a weak path: tests will repeat spec hallucinations, and the team will not catch scope drift.

A workable path:

1. Drafts and P8 — consistency and impact.
2. Human review (R1–R8) — you read and decide.
3. Refine test cases / AC after agreed scope — manually or with AI as editor, not sole author.

P8 — Consistency and impact review

You are a senior BA reviewing discovery artifacts for consistency and cross-impact.
Artifacts: {{paste 2+ documents: scope brief, SRS excerpt, flows, roles, NFR, integrations}}
Do not rewrite documents. Do not generate a full test suite.
Output:
1) Table: Issue | Artifact A | Artifact B | Severity | Suggested fix
2) For each major requirement change area: what other artifacts/stories/NFR/integrations may be affected
3) List: ambiguous phrases, untestable acceptance criteria, flows without matching stories
Mark inferred items as [ASSUMPTION].

---

Review checklist after AI

Before sending to client, estimators, or contract:

#	Check
R1	No conflict with business goals or meeting decisions
R2	No features outside agreed MVP
R3	No invented integrations / APIs / protocols
R4	NFR items with [DECISION NEEDED] have owner and plan
R5	Acceptance criteria are testable, not "fast and convenient"
R6	Compliance claims are not treated as legal advice
R7	No duplicate stories; merge similar ones
R8	All [ASSUMPTION] items in assumptions register

Review is done by someone who knows the domain and can say "we did not promise that" — usually BA, PM, or tech lead.

---

Workflow: from notes to estimate

flowchart LR
  A[Notes / I1–I10] --> B[P1: questions]
  B --> C[Team answers]
  C --> D[P2: scope brief]
  D --> E[P3: stories]
  D --> F[P4: NFR]
  D --> G[P5: integrations]
  E --> H[P6: risks]
  F --> H
  G --> H
  H --> I[P8: consistency and impact]
  I --> J[Human review R1–R8]
  J --> K[Package from part 1]
  K --> L[Phased estimate — part 2]

Run P7 after each meeting in parallel. Output aligns with the package in part 1 and D1–D11 from part 2.

---

What still requires a dev partner

AI does not remove:

• Feasibility — can MVP ship in time and budget with chosen stack;
• Architecture — options, trade-offs, integration risks;
• Estimation — ranges, assumptions, phased plan;
• Workshops — priorities, disputed decisions, scope sign-off.

Drafts speed up talks with engineers; they do not replace them. After coding phase see AI in SDLC and code quality in SDLC.

---

How we use AI in discovery (Smartym Pro)

• P1–P7 inside workshops and between sessions, not instead of them.
• Engineers validate feasibility and join estimation.
• Clients own business decisions; we structure artifacts toward phase-one estimate.

For AI in products and process — AI development; for delivery discipline — our approach and web application development.

---

What not to promise

• Fixed price from raw AI output without review
• Legally binding compliance opinion
• "Replace your BA with ChatGPT"
• Publishing internal client prompts with secrets

---

FAQ

Can we ship AI output as the final spec?
No. Only after review and agreed assumptions.

How many prompts for one MVP?
Usually P1 → P2 → P3 + P4 + P5 → P6; P7 as meetings happen.

Should we auto-generate test cases with AI?
Only as a draft after P8 and human review — and you must read them. Blind generation from raw spec does not work.

Does this replace discovery?
No. See part 2. AI speeds drafts; sign-off and the part 1 package remain.

Corporate policy blocks cloud LLMs?
Same workflow on on-prem / private endpoint; still anonymize inputs.

---

Conclusion

AI for project documentation works when you supply structured input, request one artifact at a time, run P8 and human review — then rely on the part 1 package for phased estimation. Drafts in hours, not days; consistency with reading — not vacuum-generated tests.

For a discovery workshop, AI draft validation, or SDLC AI adoption — contact us.

---

General guidance on software delivery and LLM use — not legal advice. Do not upload confidential data to public models.