Architecture Discovery

Use this when you need to go from "we don't understand this system" to "we have identified services, APIs, data ownership, and an actionable backlog." This skill set chains three stages: Event Storming (discover events and boundaries), Boris Modeling (model service relationships), and SNAP Documentation (capture detailed architecture per bounded context).

This is a skill set — it orchestrates /event-storm, /boris-model, and /snap-document in sequence. Each skill also works independently.

Process

Step 1: Gather inputs

Ask the user:

1. Business domain or system — what are we discovering? (e.g., "order management," "patient records," "payments platform")
2. Goal — what's driving this? (modernization, new team onboarding, monolith decomposition, greenfield design)
3. Scope — full system or a specific subsystem/process?
4. Participants — who will be involved across all three stages?
5. Current state — any existing diagrams, docs, or architecture artifacts?
6. Session format — in-person workshops or async/virtual documentation?
7. Output destinations — where should final deliverables land? (Miro, Notion, Linear, FigJam, files)
8. How deep? Options:
   • Full discovery (default) — all three stages, complete SNAP sheets, consolidated backlog
   • Events + Boris only — skip SNAP, stop after service relationships are mapped
   • Events only — just Event Storming, stop after domain events are captured

Step 2: Event Storming

Run /event-storm with the inputs gathered in Step 1.

Key outputs to carry forward:

• Domain events (timeline)
• Bounded contexts (with key events and ubiquitous language)
• Thin slices (happy path + alternates)
• Hot spots and pain points
• Communication patterns (sync vs. async)

Step 3: Bridge — Event Storming to Boris

Before moving to Boris, confirm with the user:

• "We identified (N) bounded contexts: (list). Do these feel right?"
• "The happy path thin slice is: (path). Should we start Boris with this flow?"
• "There are (N) hot spots. Any that would block Boris modeling?"

Reshape the Event Storming output for Boris:

1. Each bounded context becomes a service node
2. Each communication pattern becomes a candidate interaction arrow
3. Each thin slice becomes a flow to walk through
4. Hot spots carry forward as open questions

Step 4: Boris Modeling

Run /boris-model using the reshaped inputs from Step 3.

Key outputs to carry forward:

• Services (with responsibilities and event ownership)
• Service interactions (sync/async, labeled)
• Flows traced through the architecture
• API candidates
• Patterns identified (orchestration, choreography, shared data)
• Open questions

Step 5: Bridge — Boris to SNAP

Before moving to SNAP, confirm with the user:

• "We identified (N) services with (N) interactions. Ready to document details?"
• "The API candidates are: (list). Do these cover the key integration points?"
• "Open questions from Boris: (list). Any to resolve before SNAP?"

Reshape the Boris output for SNAP:

1. Each service becomes a SNAP sheet
2. Each API candidate seeds the APIs category
3. Each event (produced/consumed) seeds the Pub/Sub category
4. Each interaction seeds the External Systems category
5. Open questions become Risks and Stories (investigation spikes)

Step 6: SNAP Documentation

Run /snap-document using the reshaped inputs from Step 5.

Key final outputs:

• Complete SNAP sheets per bounded context
• Gap analysis (missing APIs, data ownership conflicts, orphan events)
• Consolidated backlog with prioritization

Step 7: Synthesize final deliverables

Produce a single architecture discovery summary:

---

Architecture Discovery: (Domain/System Name)

Date: (date) Participants: (list) Goal: (what drove this discovery)

Executive Summary

(2-3 sentences: what we discovered, how many services, key architectural decisions, top risks)

Bounded Contexts → Services

Context	Service	Key Responsibilities	Events Owned
(Context)	(Service)	(Responsibilities)	(Events)

Architecture Overview

(High-level description of how services interact — orchestration style, key data flows, external integrations)

Technology Landscape

For each bounded context, catalog the technology stack and assess lifecycle status.

Context	Languages/Frameworks	Databases	Infrastructure	Lifecycle Status
(Context)	(e.g., Python 3.11, FastAPI)	(e.g., PostgreSQL 15)	(e.g., AWS ECS, RDS)	Current / Aging / End-of-life

Technology Consolidation Opportunities

Identify where multiple bounded contexts use different technologies for the same purpose. Consolidation reduces cognitive load, simplifies hiring, and lowers maintenance costs.

Capability	Technologies in Use	Contexts	Recommendation
(e.g., Message queue)	(e.g., RabbitMQ, SQS, Kafka)	(which contexts use each)	(consolidate to X / keep separate because Y)
(e.g., API framework)	(e.g., Express, FastAPI, Spring)	(which contexts use each)	(consolidate to X / keep separate because Y)

Feed consolidation opportunities into /technology-roadmap for investment planning and /build-vs-buy when evaluating replacement options.

Key Decisions Made

Decision	Rationale	Confidence	Revisit When
(Decision)	(Why)	High/Med/Low	(Trigger)

Top Risks

Risk	Impact	Mitigation	Owner
(Risk)	High/Med/Low	(Mitigation)	(Owner)

Backlog Summary

• (N) total stories across (N) bounded contexts
• Top 5 priorities: (list)
• Spikes needed: (list)

Artifacts Produced

Artifact	Location	Format
Event Storming output	(location)	(format)
Boris model	(location)	(format)
SNAP sheets	(location)	(format)
Consolidated backlog	(location)	(format)

---

Step 8: Review

Ask the user:

• Does the architecture feel right for the stated goal?
• Are there services or boundaries that need another pass?
• Is the backlog ready for team estimation, or are there too many unknowns?
• Who needs to see this? (team, leadership, client)
• Should we generate a presentation deck? → use /artium-deck

Uncertainty Policy

Topic	Tolerance	Action
Domain scope and boundaries	Low	STOP and ask — wrong domain scope wastes the entire session
Business process being modeled	Low	STOP and ask — Event Storming requires a clear process to trace
Stage transition readiness	Low	STOP and ask — skipping quality checks compounds errors across stages
Bounded context names	Medium	Assume + flag [ASSUMED] — refined during Boris modeling
Service interaction patterns (sync/async)	Medium	Assume + flag [ASSUMED] — team validates during Boris
Story priority and sizing	Medium	Assume + flag [ASSUMED] — backlog is a starting point
Participant roles and expertise	High	Best guess from context

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

Related skills

• /event-storm — Stage 1 (standalone)
• /boris-model — Stage 2 (standalone)
• /snap-document — Stage 3 (standalone)
• /artium-deck — generate a presentation from the discovery output
• /story-write — flesh out individual stories from the SNAP backlog
• /prd-draft — write PRDs for high-priority services

Output locations

Format	Location	Notes
Markdown summary	Conversation or saved file	Always produced.
Event Storming	Per /event-storm output settings	Stage 1 artifact.
Boris model	Per /boris-model output settings	Stage 2 artifact.
SNAP sheets	Per /snap-document output settings	Stage 3 artifact.
Consolidated backlog	Linear, Notion, or file	Per user preference.