What is The Story Architect?

The Story Architect is a 3-step prompt flow for product owners who need to turn a feature idea into a development-ready user story — with the scenario context and acceptance criteria that prevent dev teams from building the wrong thing. It chains Role Prompting to set a senior PO writing standard, COAST to structure the story within its full scenario context, and CLEAR to generate the logic, expectations, and restrictions that become testable acceptance criteria.

The flow addresses the two most common user story failures: stories that lack scenario context (so devs make assumptions that diverge from intent) and acceptance criteria that are too vague to be testable ("the feature should work as expected"). COAST prevents the first by forcing scenario grounding. CLEAR prevents the second by requiring explicit logic, expected behaviour, and explicit restrictions.

When to Use The Story Architect

🆕

New Feature Stories

Turning a product idea or stakeholder request into a well-scoped, scenario-grounded story ready for sprint planning.

♻️

Refining Existing Stories

Improving vague backlog items that lack scenario context or have insufficient acceptance criteria before they enter a sprint.

🔀

Epic Decomposition

Breaking a large epic into individual stories by running COAST multiple times with different scenario values for each user path.

🐛

Bug Reports as Stories

Structuring a bug report as a formal story with reproduction scenario, expected behaviour, and explicit fix restrictions.

🏗️

Technical Debt Stories

Writing tech debt stories with a business-justified Logic component that explains why prioritisation is warranted.

🤝

Stakeholder Alignment

Using the COAST output as a structured format for stakeholder review before acceptance criteria are finalised.

The Flow Algorithm

1

Role Prompting — Set the PO Standard

Assign a specific senior PO persona with named quality values before writing any story content. The persona should specify the writing standard you expect: stories written in standard "As a… I want… so that…" format, acceptance criteria written as testable Given/When/Then conditions, explicit edge cases, and scope restrictions on every story. Reference a benchmark if useful — "the standard of stories that never come back from dev with clarification questions."

Produces:

A writing persona that applies a consistent, high-quality standard to every story generated in this session — preventing the vague, one-liner stories that cause sprint friction.

2

COAST — Structure the Story

Apply COAST to structure the feature as a fully contextualised user story: Context (product background, user type, current state — what is true before this story), Objective (what the user is trying to achieve — the "so that" clause), Actions (what the user does to achieve it — the "I want to" clause, broken into discrete steps), Scenario (the specific situation that triggered this story — the concrete use case, not the abstract capability), Task (the development work in scope — what engineering will build). Ask the model to output a formatted story with these components explicit.

Produces:

A user story grounded in a real scenario, with the user's objective, actions, and development scope all explicit — no room for dev interpretation of intent.

3

CLEAR — Write the Acceptance Criteria

Feed the COAST story into a CLEAR prompt to generate complete acceptance criteria: Context (re-ground in the scenario from Step 2), Logic (the reasoning behind each criterion — why this specific behaviour is required), Expectations (the specific, testable conditions that must be true — Given/When/Then per criterion), Action (what the system must do for each expectation to pass), Restrictions (what must NOT happen, what is explicitly out of scope for this story). The Restrictions component is critical — it defines the story's boundary and prevents scope creep during development.

Produces:

Complete, testable acceptance criteria with explicit restrictions. Every criterion has a reason (Logic), a test (Expectations), and a boundary (Restrictions) — the full definition of done.

Example Prompt Sequence

Step 1 — Role Prompting

You are a senior product owner with 10 years of experience writing user stories for agile software teams. Your stories are known for never coming back from dev with clarification questions.

Your standards:
- Every story uses the format: "As a [user type], I want [action], so that [outcome]."
- Acceptance criteria are written as testable Given/When/Then conditions — never vague statements like "should work correctly."
- Every story includes at least one edge case and one explicit out-of-scope restriction.
- Scenario context is always specific — a concrete situation, not an abstract capability description.

With these standards, help me write a user story for the following feature.

Step 2 — COAST Story Structure

Using the COAST framework, write a user story for this feature:

Feature idea: Allow users to save a prompt template as a favourite so they can find it quickly.
Product: A macOS app for managing reusable AI prompt templates.
User: A daily AI user who has 30+ templates saved and struggles to find the ones they use most.

Structure the story using:
Context: Who is the user, what is their current situation, and what friction exists today?
Objective: What outcome does the user want — the "so that" clause?
Actions: What specific steps does the user take — the "I want to" clause?
Scenario: The specific moment that triggered this need (e.g., "The user opens the app to quickly reuse their daily standup template but has to scroll through 30 templates to find it.")
Task: What does engineering build — scoped to this story only?

Output: A formatted user story with each COAST component labelled, followed by the one-line story sentence.

Step 3 — CLEAR Acceptance Criteria

Using the CLEAR framework, write complete acceptance criteria for the user story below.

For each acceptance criterion:
Context: Re-state the relevant part of the scenario that this criterion addresses.
Logic: One sentence explaining why this specific behaviour is required.
Expectations: Written as Given / When / Then — specific and testable, no vague language.
Action: What the system does when the expectation is met.
Restrictions: What must NOT happen, or what is explicitly out of scope for this story.

Include criteria for: the happy path, at least one edge case (e.g., favouriting a template that was already favourited), and one explicit out-of-scope restriction.

User story from Step 2:
[PASTE STEP 2 OUTPUT HERE]

Pros and Cons

Strengths

  • Scenario grounding prevents dev interpretation drift
  • CLEAR Restrictions component reduces scope creep
  • Given/When/Then format makes AC immediately testable by QA
  • Beginner-friendly — each step is straightforward
  • Scales: run COAST multiple times per epic to decompose stories

Trade-offs

  • More verbose than a one-liner story — appropriate for complex features, not trivial tasks
  • COAST scenario requires a concrete use case — needs domain knowledge to write well
  • Step 3 AC should be reviewed before adding to Jira — not a fully automated output
  • Overkill for small bug fixes or copy change tickets

Frequently Asked Questions

What is The Story Architect prompt flow?

The Story Architect chains Role Prompting, COAST, and CLEAR to turn a feature idea into a Jira-ready user story with complete acceptance criteria. Role Prompting sets the quality standard, COAST structures the story within its full scenario context, and CLEAR adds the logic and restrictions that become testable acceptance criteria.

Why use Role Prompting first instead of jumping straight to COAST?

Without a persona, the model writes user stories at a generic 'helpful assistant' standard — which typically produces structurally correct but uselessly vague acceptance criteria like 'the feature should work correctly'. A senior PO persona applies the specific standards you actually need: precise Given/When/Then logic, explicit edge cases, and scope restrictions that prevent dev interpretation drift.

How does COAST map to a user story?

COAST's five components align naturally with user story structure: Context (the product and user background), Objective (what the user is trying to achieve — the 'so that' clause), Actions (what the user does — the 'I want to' clause), Scenario (the specific usage situation that prompted this story), Task (the development task in scope). Together they produce a richly contextualised story rather than a one-liner.

What does CLEAR add that COAST doesn't already cover?

COAST produces the story and its scenario context. CLEAR adds the acceptance criteria layer: Context (re-grounds the AC in the story scenario), Logic (the reasoning behind each criterion — why this matters), Expectations (specific, testable conditions that must be true), Action (what the system must do), Restrictions (what must NOT happen, what is out of scope). The Restrictions component is particularly valuable — it prevents devs from building beyond scope.

Can this flow generate multiple user stories from a single feature?

Yes. Run Step 2 (COAST) multiple times with different Scenario values to generate stories for different user paths through the same feature. Each scenario produces a distinct story with its own context. Then run Step 3 (CLEAR) for each story. This is especially useful for features with multiple user types or happy/sad path distinctions.

How do I handle epics versus individual stories with this flow?

For an epic, run Step 1 once and Step 2 with a high-level Objective. The COAST output will naturally reveal multiple distinct Actions — each one becomes a candidate individual story. Then run Step 3 (CLEAR) on each individual story. The flow scales from epic decomposition down to single-story refinement.

Can I adapt this flow for bug reports or technical debt stories?

Yes. For bugs: in COAST, the Scenario is the reproduction steps, the Objective is the expected behaviour, and the Actions are the buggy steps. CLEAR's Restrictions then specify what the fix must not change. For technical debt: the Scenario is the current pain, the Objective is the improved state, and CLEAR's Logic explains the business justification for prioritising the work.