Skip to content
Story creation
AutoXXS (320px)XS (375px)SM (640px)MD (768px)LG (1024px)XL (1280px)XXL (1536px)
SketchMaterialiOSTamagui
DataInjectionKeyPatternsServiceTransactionProcessResearchProductQualityPerformanceSpecDomainFunctionTechnologyArchitectureConfigMiddlewareDataDatabaseDrizzleMigrationModelop-sqliteSchemaSQLState ManagementDraftKeystoneMergePatchPatchesPersistenceReactiveRedoStoreUndoTestingDeviceFactoryIsolationTypeScriptZodTopicsCommunicationBidsNVCDesignDesign ImplicationsEducationPedagogyFoundationsPsychologyAttachmentFloodingRelatingAuthentic RelatingUIEditorReact Native

Story creation

Workflow Story creation
agent starscribe
tags
workflowstory

A story is a narrative walkthrough of a user journey across one or more features. It bridges abstract features and concrete user experience. Stories are read by humans and agents alike to understand the “feels like” of the product.

A story does NOT define requirements — it illustrates them. All referenced features and the role must already exist.

Dependency Check

Before starting, verify:

  • The primary role exists in content/roles/ — if not, run starspec/agents/starscribe/role.create first
  • All referenced features exist in content/features/ — if not, run starspec/agents/starscribe/feature.create first

Phase 1 — Journey Arc

Ask:

  1. Which role is the primary actor?
  2. Which features does this story move through? (ordered by the user’s path, not by feature id)
  3. What is the single goal the actor is trying to achieve from start to finish?
  4. What emotional state or situation does the actor start in? What changes by the end?

One story = one coherent journey. If two goals emerge, create two stories.

Phase 2 — Narrative Draft

Write the story body as continuous prose in first person from the actor’s perspective:

  • Start: what triggers the journey (the actor’s motivation or situation)
  • Middle: step through each feature interaction in natural sequence
  • End: what the actor has achieved and how the experience felt

Keep it concrete. Name screens, actions, and outcomes. Avoid implementation detail (no component names, no API calls).

Phase 3 — Coverage Check

Before confirming the draft, verify:

  • Every referenced feature is listed in the features attribute
  • The narrative does not introduce requirements not already in those features (if it does, add them to the feature first)
  • The story has a clear beginning, complication, and resolution

Output: content/stories/{id}.story.mdoc


Do’s and Don’ts

Do:

  • Verify the primary role and all referenced features exist before starting
  • Write in first person from the actor’s perspective with concrete screen and action names
  • Ensure the story has a clear beginning, complication, and resolution arc
  • Check that the narrative does not introduce requirements not already in the referenced features
  • Keep one story per coherent journey — split if two goals emerge

Don’t:

  • Don’t define new requirements in a story; stories illustrate, they do not define
  • Don’t use implementation details (component names, API calls) in the narrative
  • Don’t create a story referencing features that do not yet exist in content/
  • Don’t write abstract or generic journeys; use concrete screens, actions, and outcomes
  • Don’t combine multiple unrelated goals into a single story

Definition of Done

  • Draft presented to user for confirmation
  • Document written as content/stories/{id}.story.mdoc with correct frontmatter and root tag
  • Primary role and all referenced features exist in content/
  • Narrative does not introduce requirements absent from referenced features
  • Story has a clear beginning, complication, and resolution
  • All cross-references resolve to existing documents
  • pnpm compile succeeds