lvlup-sw Design — Backend Quality as Design Constraint
The design-mode entry point to axiom's dimension taxonomy. Where axiom:audit evaluates code that exists, axiom:design constrains code that's being shaped.
Triggers
Use when:
- Running
/exarchos:ideateor any pre-implementation conversation - Sketching a new module, service, or subsystem
- Reviewing a design proposal before commitment
- Pairing with a project-specific invariants skill (e.g.,
exarchos:design-invariants)
Do NOT use when:
- Auditing existing code — use
axiom:auditfor that. - Targeting one specific dimension — use the specialized review skill (
axiom:critique,axiom:harden, etc.).
Process
- Read the augmented dimension taxonomy:
@skills/backend-quality/references/dimensions.md. Each dimension has a### Design questionsblock written for design-mode use. - Discover any paired project-specific invariants skill loaded in this context (see Pairing Discovery below).
- Render the design conversation by walking the eight dimensions in order, surfacing the design questions and — if a paired skill is loaded — interleaving its project-specific invariants where they overlap.
Pairing Discovery
axiom:design looks for any loaded skill whose frontmatter declares pairs-with: axiom:design. The lookup is by frontmatter slot, not by filename or convention path. The pairing contract is documented at: @skills/backend-quality/references/pairing-contract.md.
Three operating modes:
- No paired skill loaded. Run generic-only: present DIM-1..DIM-8 design questions. End with the line
No paired invariants skill detected. Run /axiom:scaffold-invariants to create one.so the user knows the bootstrap path. - One paired skill loaded. Interleave. For each dimension, render the generic design questions first, then any project-specific invariants whose
axiom_overlap: DIM-Nmatches the current dimension. Project invariants withoutaxiom_overlapdeclarations render in a final "Project-specific only" section. - Multiple paired skills loaded. Render each under a named subsection (one per skill). The user can scope-narrow with an arg if needed.
Output Composition
The dimension is the organizing axis. Within a dimension:
- Generic axiom design questions render first.
- Project-specific invariants (matched by
axiom_overlap) render after.
This ordering is visual — generic comes first because it's the broader frame. Semantically the precedence is reversed: when project-specific guidance and generic guidance conflict, the project-specific rule wins. This mirrors ESLint's array-order override (later extends entry wins) and ATAM's utility-tree convention (leaves are authoritative for their scenarios).
The full ordering rule is documented in the pairing contract.
Failure Modes
- No paired skill loaded → generic-only output, ends with:
No paired invariants skill detected. Run /axiom:scaffold-invariants to create one. - Multiple paired skills loaded → render each under a named subsection.
- Paired skill declares
pairs-with: axiom:designbut has no invariants → generic-only with:Paired skill <name> declares pairing but has no invariants.
References
- Dimension taxonomy (dual-mode):
@skills/backend-quality/references/dimensions.md - Pairing contract:
@skills/backend-quality/references/pairing-contract.md - Foundation reference:
@skills/backend-quality/SKILL.md - Project-specific archetype:
exarchos/.claude/skills/design-invariants/SKILL.md