just-vibeGeneral · inspect by default
/map
Map module and package imports inside a repository, including cycles and dynamic edges
Use for module dependencies inside a repository; arch-map covers deployed services and stores.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select map from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv map, /just-vibe map and /jv:map in Claude. See shortcut setup and context examples.
/just-vibe:map Map dependencies between the billing modules; include cycles./just-vibe:map Map modules including a plugin loaded from configuration./just-vibe:map Map this partial source snapshot without claiming complete dependency coverage.What the agent does
- Identify public entry points, nodes and dependency direction; collapse generated/vendor code to keep a readable level of detail.
- For a first pass run atlas map --root PROJECT --stdin with {paths}; treat its edges as lexical candidates, resolve specifiers, verify representative and cycle edges in source, and report partial coverage.
- Distinguish imports, calls and data sharing, and separate declared from observed dependencies.
Inputs
- repository/subsystem and desired map depth. Requires source and manifests.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Existing modules and dependencies; deeper distributed architecture questions belong to `arch-map`.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Inspect; repository/subsystem and desired map depth. Requires source and manifests.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Diagram or adjacency table with a legend, entry points, representative dependency paths, cycles, evidence links, and uncertain or unresolved dynamic edges.
How the work is checked
- Detects a real dependency cycle; generated/vendor directories do not overwhelm the map.
When to stop or clarify
- Cap graph expansion at the requested boundary and summarize external nodes. Do not present the diagram as an approved future architecture.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Inspect imports, composition roots, schemas, network clients and deployment metadata.
- Method
- Choose a diagram level that answers the request and label source coupling separately from runtime topology.
- Pitfall
- A large unlabeled graph hides ownership and can imply nonexistent deployed services.
- Check
- Validate representative edges and data owners against source evidence; flag inferred external components.
Situational decisions
When static analysis cannot resolve dynamic loading: Mark the edge inferred and inspect registration/configuration sites instead of inventing a dependency.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.