The Creators – From a Rough Idea to a Complete Artifact

In the overview of the toolkit I described why I didn't build one assistant, but rather the ability to create them. This post is about the first of the four operations: creating.

It sounds like the easiest one. It is the one I had to rework the most.

The Starting Point

A requirement comes in at cruising altitude:

Users should be able to cancel their booking.

Out of that, an artifact has to emerge that the next role can work with. Depending on the level, that is an epic, a feature, a user story, a set of acceptance criteria, a test case or a solution concept. Each has a different structure, a different audience and different rules.

That is exactly why "creating" is not one assistant, but a family. What they share is the flow. What sets them apart are schema and rules.

Anatomy of a Creation Assistant

The last item under sources is the one I underestimated at first. Handing over existing, good artifacts as examples works better than any description in the prompt. A model that has seen three real user stories from your own inventory hits the tone better than one you explain the tone to.

Take-Away: The Templates

The assistants work with Markdown throughout — input as well as output. There is a practical reason for that: what comes out is readable for humans and usable as context for the next assistant at the same time, without an intermediate step.

The following templates are deliberately generic. They follow what has become established as a structure for epics and user stories — there is nothing company-specific about them, and that is exactly why every company would have to adapt them. Take them as a starting point and adjust fields, language and conventions to whatever is common practice at your place. That is precisely the point of a toolkit.

Template: Epic

# Epic: <Title>

## Goal
<What is to be achieved — a business statement, not a proposed solution.>

## Context and Trigger
<Why now? Which problem, which opportunity, which obligation?>

## Success Indicators
<How do we recognise that this epic has reached its goal?
Phrased observably.>

| # | Indicator | How measurable |
|---|-----------|----------------|
| 1 |           |                |

## Out of Scope
<What deliberately does not belong to it. Without this section, scope
grows during decomposition.>

## Affected Areas
<Business units, systems, interfaces — as far as known.>

## Child Features
| # | Feature | Short description |
|---|---------|-------------------|

## Open Questions and Assumptions
| # | Assumption | Impact if it does not hold | Who decides |
|---|------------|----------------------------|-------------|

The Out of Scope section is the one most easily left out and most frequently missed. Without it, the next step decides for itself what belongs in.

Template: User Story

# User Story: <Title>

**As a** <role>
**I want** <goal>,
**so that** <benefit>.

## Description
<Two to four sentences of business context. No solution design.>

## Acceptance Criteria

### AC-1 · <Short title>
- **Given** <initial state>
- **When** <trigger>
- **Then** <observable result>

### AC-2 · <Short title>
- **Given** …
- **When** …
- **Then** …

## Error Cases
| # | Situation | Expected behaviour |
|---|-----------|--------------------|
| 1 |           |                    |

## Dependencies
<Other stories, systems, preconditions. "None" is a valid answer.>

## Open Questions and Assumptions
| # | Assumption | Impact if it does not hold | Who decides |
|---|------------|----------------------------|-------------|

The Rules That Go With It

The template alone is not enough — it describes the form, not the quality. What belongs with it is a second block that the assistant receives as its rulebook:

## Rules for This Assistant

**Mandatory**
- Every acceptance criterion names an observable condition, a trigger
  and an expected result.
- At least one error case per story.
- Everything that had to be assumed goes under "Open Questions and
  Assumptions" — not into the running text.

**Forbidden**
- Adding functionality that nobody asked for.
- Unverifiable phrasing: performant, user-friendly, intuitive, fast,
  modern, robust.
- Stating assumptions as facts.

**When unclear**
- Ask at most six follow-up questions, then wait for an answer.
- Do not guess and carry on.

The Open Questions and Assumptions section is the most important one in the entire template. More on that in a moment.

What Didn't Work in the First Draft

Problem 1: Beautiful criteria that nobody can verify.

The first results looked excellent. Cleanly worded, seemingly complete, in the right structure. Until somebody tried to derive a test case from them.

❌ The system shall process the cancellation performantly.
❌ The user shall understand the process intuitively.

Neither is wrong. Neither is verifiable. And because it sounds plausible, it doesn't stand out when skimming — it stands out three weeks later, when somebody asks when exactly this criterion is considered met.

What helped was not a better task description, but a structural constraint. Given/When/Then forces an observable condition, a trigger and an expected result. Where one of them is missing, it shows while filling in the template — not only during testing.

On top of that, a negative list in the schema: words such as performant, intuitive, user-friendly are forbidden in acceptance criteria. That is crude, and it works.

Problem 2: The assistant thought along.

That sounds good at first. Out of "users should be able to cancel" came an artifact with cancellation deadlines, partial cancellation, refund logic and a notification email. All sensible. None of it was asked for.

That is more dangerous than a gap. A gap is visible. An invented requirement looks like thoroughness — and travels unnoticed into implementation, where it creates effort nobody commissioned.

The rule that came out of this is, in my view, the most important one in the whole system:

An assistant must not make assumptions. It has to surface them.

Hence the mandatory Open Questions and Assumptions section — with the column "Impact if it does not hold". Whatever the assistant had to assume is written there: visible, separated from the rest, and thereby marked as a decision for a human. A hidden invention becomes an open question.

That is the same idea as the human-in-the-loop checkpoint from my Agentic Coding series: a course correction is free as long as it happens early. The only difference is that there a developer reviews, and here a business unit does.

Decomposition Is Its Own Assistant

Breaking an epic down into user stories is not a variant of creating. The creator fills an empty structure; in decomposition the content is already there and has to be distributed without anything getting lost. That is a different task with different sources and a different main risk — and therefore its own assistant. The next post is about it.

Limits

A creation assistant knows nothing about priority. It doesn't know what matters to the company this quarter, which customer is waiting, and which topic is politically off the table right now. It produces a complete artifact — not the right one.

And it is only as good as the reference examples it gets to see. Feed it poor existing artifacts as a reference, or withhold relevant information, and you get consistently poor new ones.

Conclusion

Creating is the operation that impresses fastest and needs adjusting the longest. Two rules made the difference: a structural constraint that makes unverifiable phrasing impossible — and the obligation to surface assumptions instead of making them.

The next post covers the operation that comes right after it: turning a finished artifact into the next one — from an epic to the user stories.

→ The toolkit at a glance

→ Why AI assistants fail on context in the enterprise (coming soon)