just-vibeArchitecture · plan by default
/arch-modernize
Plan an incremental transition to a target architecture
Use for staged architectural transition; refactor handles an internal structural change and migrate handles a version or platform transition.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select arch-modernize from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv arch-modernize, /just-vibe arch-modernize and /jv:arch-modernize in Claude. See shortcut setup and context examples.
/just-vibe:arch-modernize Plan an incremental extraction of billing while the old app keeps running./just-vibe:arch-modernize Modernize a monolith while old reports still query its database./just-vibe:arch-modernize Plan modernization without dependency ownership; list blocking unknowns by phase.What the agent does
- Inventory dependencies and identify a seam with separable traffic and data ownership.
- Sequence compatibility layers and data movement, and define coexistence parity checks and retirement evidence before replacing the seam.
Inputs
- current/target architecture, constraints, business continuity needs, and migration horizon.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Incremental modernization and transitional operation, not immediate replacement.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; current/target architecture, constraints, business continuity needs, and migration horizon.
- 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
- Phased migration architecture with each phase's working state, the coexistence plan, cutover conditions, irreversible boundaries and recovery checkpoints.
How the work is checked
- Each phase leaves a working system; old components are retired only after dependent traffic and data ownership move.
When to stop or clarify
- Do not assume a big-bang rewrite is necessary. Flag irreversible transitions and missing operational ownership.
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
- Inventory active consumers, supported versions, write ownership and persisted representations.
- Method
- Define expand/coexist/switch/retire phases, reconciliation and exit criteria; identify the last point at which old readers remain safe.
- Pitfall
- Dual writes without recovery can diverge; code rollback cannot recover discarded data.
- Check
- Interrupt a transition with old and new clients active, resume reconciliation, and verify fallback before retiring the old path.
Situational decisions
When old and new systems write the same records: Specify source of truth, conflict handling and reconciliation before dual operation.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.