Work-type skill
Architecture and Refactor
Change architecture or module boundaries while preserving required behavior.
Skill orientation
Use this panel to select and sequence the skill. The canonical source follows below.
- Purpose
- Change architecture or module boundaries while preserving required behavior.
- Category and sequence
- Work type; sequence 4
- Primary use
- Architecture, Refactor, Migration, Technical Debt
- Required gates
- Classification, Foundation, Code Intelligence, Production, Proof
- Conditional gates
- No additional conditional gates are declared
- Red Zone triggers
- Breaking Contract, Production Migration
- Next route
- Return to the active lifecycle route
- Source identifier
skills/valdris-architecture-refactor/SKILL.md
Valdris Architecture And Refactor
- Run GitNexus-backed code intelligence; disclose any fallback.
- Validate the bound
run/workload-classification.json, then requirefoundation/assessment.jsonto pass the Layer 0 foundation gate before implementation. The foundation assessment must resolve the required capabilities, effective assurance tier, workload and stakes profiles, and proof contract for the architecture work. - Identify current boundaries, entrypoints, dependencies, invariants, and change pressure.
- Produce at least two viable designs when the decision is consequential.
- Prefer deep modules, narrow interfaces, explicit ownership, and reversible migration paths.
- Record the decision in
design/system_design.mdor an ADR with alternatives and trade-offs. - Define expand-migrate-contract steps for changes that cannot land as one green vertical slice.
- Map production-domain, security, data, deploy, and rollback impact. The 13 canonical production domains are a shared baseline, not an exhaustive list of literal layers; asynchronous orchestration is cross-cutting and must be traced through every affected domain.
- Establish proof seams before implementation.
Use $codebase-design for module quality and $code-review after implementation when available.
Do not implement during an audit or design-only request. Do not approve a refactor whose behavior cannot be proven equivalent or intentionally changed.