Use this when you have a Boris model (or at minimum, identified bounded contexts) and need to capture detailed architecture information for each context. SNAP documents the six categories that turn a conceptual model into an actionable implementation plan: APIs, Data, External Systems/UI, Pub/Sub Events, Stories, and Risks.

Full guide: See the Architecture Discovery Workshop Playbook for the complete method.

Process

Step 1: Gather inputs

Ask the user:

1. Boris model outputs — services, interactions, API candidates, and open questions. If running as part of /architecture-discovery, these carry forward automatically.
2. Bounded contexts to document — all of them, or a specific subset?
3. Depth — full SNAP (all 6 categories) or focused (APIs + Data + Risks only)?
4. Backlog destination — should stories be pushed to Linear, Jira, Notion, or kept in markdown?
5. Output destination — conversation only, Miro, Notion, or file?

Step 2: Create SNAP sheets

For each bounded context, generate a SNAP sheet by asking these questions:

APIs:

• What APIs must this context expose?
• Who are the consumers?
• What are the key operations (CRUD, search, workflow)?

Data:

• What data does this context own?
• What are the key entities and their relationships?
• What data does it NOT own but needs access to?

External Systems / UI:

• Does this context integrate with external systems?
• Does it expose a user interface?
• What protocols or standards are required?

Pub/Sub (Events):

• What events does this context publish?
• What events does it subscribe to?
• What happens if an event is missed or delayed?

Stories:

• What backlog work items emerge from this context?
• What's the first thin slice to implement?
• What spikes or investigations are needed?

Risks:

• What architectural risks exist?
• What delivery risks (skills, timeline, dependencies)?
• What unknowns need to be resolved before implementation?

Step 3: Generate SNAP sheets

Use the SNAP template to produce the deliverable:

SNAP: (Bounded Context Name)

Domain: (Parent domain) Owner: (Team or individual) Source: Boris model (date)

APIs

Data

External Systems / UI

Pub/Sub Events

Stories

Risks

Repeat the template for each bounded context.

Step 4: Identify gaps

After completing all SNAP sheets, explicitly list:

• APIs referenced by consumers but not yet defined by providers
• Data claimed by multiple contexts (ownership conflicts)
• Events published but not consumed (dead letters)
• Events consumed but not published (missing producers)
• Stories with unresolved dependencies

Step 5: Generate consolidated backlog

Collect all stories from SNAP sheets into a single prioritized backlog:

Step 6: Push to backlog tool (optional)

If the user specified a backlog destination in Step 1:

• Linear — use save_issue for each story, with labels for the bounded context
• Notion — use notion-create-pages with a database parent for structured backlog
• Miro — use table_create for the consolidated backlog table
• File — save to ./output/snap/(domain-name)-snap.md

Step 7: Review

Ask the user:

• Are there SNAP categories with too many unknowns?
• Should any bounded context be split further?
• Which stories should be tackled first?
• Are the risks acceptable, or do any need immediate spikes?
• Is this ready for team review, or do we need another pass?

Uncertainty Policy

Default: STOP and ask when a topic is not listed above.

Related skills

• /event-storm — first stage: discover domain events and bounded contexts
• /boris-model — previous stage: model service relationships
• /architecture-discovery — skill set that chains all three stages
• /story-write — flesh out individual stories from the SNAP backlog
• /api-docs-design — when API documentation needs to go beyond architecture contracts to developer-facing reference and guides

Output locations