Architecture · inspect by default
/arch-map
Map deployed services, data stores, external providers and their runtime relationships
Use for deployed service/store topology; map covers repository modules.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select arch-map from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv arch-map, /just-vibe arch-map and /jv:arch-map in Claude. See shortcut setup and context examples.
/just-vibe:arch-map Map our web app, workers, shared database, and external payment service./just-vibe:arch-map Map two services sharing a database but no source imports./just-vibe:arch-map Map supplied manifests without infrastructure access; distinguish intended from observed deployment.What the agent does
- Reconcile source, deployment configuration and documentation to identify services, stores, owners and protocols.
- Trace one request and one background operation, marking process, network, ownership and trust boundaries independently; label inferred edges.
Inputs
- system boundary, services/environments, and desired detail.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Existing services, stores, deployment units, trust boundaries, and external dependencies.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Inspect; system boundary, services/environments, and desired detail.
- Prerequisites
- Readable source, infrastructure/configuration definitions, and any supplied system documentation. Runtime telemetry is optional evidence, never assumed available. Architecture proposals remain plans until implementation is requested.
Expected output
- System diagram and component inventory whose edges carry protocol, owner, data classification and evidence confidence, with data/control flows and evidence gaps.
How the work is checked
- A shared database dependency appears even without source imports; a documented but undeployed service is marked uncertain.
When to stop or clarify
- Do not describe a static diagram as proof of live topology. Missing infrastructure access limits deployment conclusions.
Handling missing context
- Infer
- Trace current entry points, data owners, deployment units and documented constraints before proposing boundaries.
- Assume
- Prefer extending an existing owner while scale or organizational evidence is absent; mark capacity estimates as assumptions.
- Ask
- Ask for an unresolved consistency, compatibility or ownership requirement only if it changes the design; missing telemetry limits capacity claims, not source mapping.
Technical guidance
- Evidence
- Inspect composition roots, manifests, outbound clients, infrastructure definitions and queue registrations; associate each edge with its source.
- Method
- Separate imports, runtime calls and deployment boundaries. Follow one request into durable storage and one asynchronous continuation.
- Pitfall
- A package dependency does not prove a network call or independently deployed service; missing infrastructure leaves deployment unknown.
- Check
- Reconcile one diagram path against real entry points and consumers, including an error return; label inferred edges.
Situational decisions
When documentation disagrees with deployment configuration: Show both claims with evidence dates and leave live topology unconfirmed without observations.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.