/arch-feature

Make it your own.

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

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

What the agent does

1. Translate acceptance criteria and quality constraints into responsibilities, data ownership and interfaces. Trace an existing normal and failure path to locate the natural owner before proposing a new component.
2. Compare extending the current module, introducing an internal boundary and deploying a separate service. Assess data consistency, latency, independent rollout and operational ownership against demonstrated requirements.
3. Specify the chosen contract, compatibility window, failure/retry behavior and observability. Define who writes each datum and who reconciles partial effects; diagrams must distinguish observed code dependencies from proposed runtime edges.
4. Plan incremental implementation with a verification and recovery condition for each phase. Identify the smallest experiment that could overturn a material assumption before committing to an expensive boundary.

Inputs

• feature specification, current architecture, and scale/compatibility constraints.

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

Scope

Reads

Placement of one feature across modules, services, storage, and interfaces.

Writes

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

Mode

Plan; feature specification, current architecture, and scale/compatibility constraints.

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

• Requirement-to-owner map, alternatives and decisive evidence, target contracts/data ownership, phased implementation with checks and recovery limits.

How the work is checked

• Existing domain rules stay owned by one clear boundary; error and rollback paths are covered.

When to stop or clarify

• Do not introduce a service or datastore solely for stylistic separation. Flag decisions requiring workload or ownership information.

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 acceptance criteria, existing data owners, extension points and deployment constraints.

Method

Place each new behavior with the owner able to enforce its invariant; compare a module extension with a new runtime boundary using actual operational needs.

Pitfall

A new service adds network failure and consistency work even when its code is small.

Check

Walk create/read/failure paths through the proposed design and identify every consumer or schema requiring compatibility.

Situational decisions

When the feature spans two data owners: Define consistency and failure semantics before selecting synchronous calls or events.

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