Skip to content

Workflow

Best results come from authoring atoms in this order. The cloud authoring UI surfaces this as a guided checklist; hand-authoring should follow the same shape.

  1. Vision. One paragraph in vision.problemStatement + valueProposition.
  2. Persona. 1–2 atoms with goals[] + painPoints[].
  3. Module(s). Coarse grouping. The block-tree parent for everything below.
  4. Entities. Your nouns. One entity atom + N field atoms each.
  5. Features under each module. Fill Layer 1 (userStory) first.
  6. Integrations. External APIs touched by features.
  7. Rules. Engine-executable validations. Bind via uses_rule edges later.
  8. UI views. One per screen group, with viewType (list / form / detail / dashboard / wizard / custom).
  9. Criteria. For each feature, ≥1 acceptance criterion (EARS).
  10. Fixtures. Happy path + error fixtures linked to criteria.
  11. Wire relations. verifies, rendered_by, parent_of, etc. — without these, Pattern C cannot run.
  12. Layer 2 fill. Start with Pattern C (deterministic, free) where possible; fall back to Pattern D (LLM) for features with no examples.
  13. Lock + iterate. Review, lock fields you trust, re-run for the rest.
  • Vision / persona unblock the LLM Pattern D suggester — it reads them as part of every prompt.
  • Entities before features means features can declare uses_entity from the start.
  • Layer 1 before Layer 2 means Pattern D has Intent prose to ground its suggestions.
  • Relations before Layer 2 fill means Pattern C has edges to walk.
  • Lock + iterate is the working loop — you don’t need to hand-author every step, but you need to review every step before it becomes load-bearing.

A pure-PM workflow can stop at step 9 (criteria). Layer 2 fill becomes an engineering pass — same author or different, before or after dev kickoff. The bridge codegen-senlang produces something runnable at any step via Pattern B convention defaults; later passes refine.