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.

Example · inspect
/just-vibe:arch-map Map our web app, workers, shared database, and external payment service.
edge · inspect
/just-vibe:arch-map Map two services sharing a database but no source imports.
blocked · inspect
/just-vibe:arch-map Map supplied manifests without infrastructure access; distinguish intended from observed deployment.

What the agent does

  1. Reconcile source, deployment configuration and documentation to identify services, stores, owners and protocols.
  2. 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.

Keep exploring