/arch-boundaries

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select arch-boundaries from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv arch-boundaries, /just-vibe arch-boundaries and /jv:arch-boundaries in Claude. See shortcut setup and context examples.

What the agent does

1. Inventory current responsibilities, data owners and dependency directions from composition roots, imports, schemas, network clients and deployment definitions. Mark inferred or inaccessible edges explicitly.
2. Trace a representative change and failure across the proposed boundary. Identify shared transactions, cycles, leaked internals and callers that would need coordinated release; file count alone is not evidence of a bad boundary.
3. Propose the smallest interface or ownership correction that reduces the demonstrated coupling. Specify allowed dependencies, compatibility, error semantics and enforcement in the existing build/test architecture.
4. Verify the boundary with a consumer-facing contract check and a forbidden-dependency example when appropriate. Estimate migration impact from actual consumers and keep unmeasured organizational benefits conditional.

Inputs

• modules/services and intended responsibility rules.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Coupling, cycles, ownership leaks, and misplaced responsibilities; no automatic service extraction.

Writes

No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.

Mode

Inspect; modules/services and intended responsibility rules.

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

• Boundary findings with examples and incremental repair options.
• Concrete dependency paths, violated responsibility, demonstrated cost and incremental correction.

How the work is checked

• A dependency cycle has a concrete path; a justified shared utility is not rejected merely for having many callers.

When to stop or clarify

• Distinguish organizational preference from demonstrated architectural cost. Missing ownership rules become questions, not invented mandates.

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

Find dependency cycles, shared mutable tables, cross-module imports and repeated business rules at actual call sites.

Method

Identify which owner enforces each invariant; propose a seam that removes a specific cycle or competing writer, with transition contracts.

Pitfall

Folder moves can conceal unchanged coupling; a shared type is not inherently a boundary violation.

Check

Trace the affected invariant before and after the proposed boundary, including a consumer failure and ownership of rollback.

Situational decisions

When a cycle is intentional and isolated behind an interface: Assess change coupling and failure propagation before prescribing a split.

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