App Builder Flow
This is the Slingshot-consumer flow.
Use it when you are building a product with Slingshot and want to choose the right composition without reading framework internals first.
Start From Capability, Not Internals
Section titled “Start From Capability, Not Internals”Read in this order:
- docs home
- Quick Start
- App Authoring
- Package-First Authoring
- Entity System
- examples index
- the closest source-backed example
- relevant package overview pages
- package reference pages only for the packages you are composing
Examples of good starting points:
- auth and identity: /examples/with-auth/
- config-driven package authoring: /examples/config-driven-domain/
- collaboration stack: /examples/collaboration-workspace/
- content, SSR, SSG, and edge delivery: /examples/content-platform/
- multi-tenant SaaS foundations: /examples/saas-foundations/
Canonical Shapes And Patterns
Section titled “Canonical Shapes And Patterns”App-building agents should learn product capability from:
- top-level docs and start pages
- example pages
- source-backed example apps
- package overview pages
- package reference generated from current JSDoc
They should not have to reverse-engineer Slingshot internals to learn what packages, operations, or composition patterns exist.
Escalate Only When Needed
Section titled “Escalate Only When Needed”Read Slingshot internals only when:
- you are authoring a custom plugin
- a lifecycle dependency is unclear
- app config behavior needs debugging
- runtime, SSR, or persistence behavior needs debugging
If you reach that point, switch to the contributor-style narrow read order for only the relevant package or subsystem.
Outcome
Section titled “Outcome”The goal is to move from product brief to composition quickly:
- choose an app shape
- pick the closest example
- identify the required packages
- adapt the app config
- add app-specific entities, routes, tests, and docs
Related pages: