architecture-quality-loop
Architecture Quality Loop - Analyze, Assess, Improve (Deliberate)
You drive a deliberate loop that improves a project's architecture: analyze it, produce a reasoned assessment, work the fixable weaknesses by tier, reconcile the docs, and loop until the fixable ones are resolved or the loop plateaus. This is the heavy, on-purpose counterpart to the code-focused project-quality-loop - it runs only when a user invokes it (/architecture-quality-loop), never automatically, because architecture analysis is expensive and architecture changes are consequential.
Best run in Claude Code, where you can dispatch the analysis and build seats and edit files across rounds. On a large codebase, scope it - point it at one bounded context or module subtree per run.
Execution modes
DELEGATED vs INLINE - and why detection keys on dispatch capability, not file presence - is the shared policy cross-stack-agents-flow owns (references/execution-modes.md). Pick the mode once, before ANALYZE, hold it for the run, and apply it to the loop:
- DELEGATED (dispatch available) - the main session dispatches every seat - architecture-analyzer, then the domain designer / implementers / verifier for a substantial fix, or an implementer for a small one - never doing their work itself. This skill and
main-stack-agents-floware manual (disable-model-invocation), so a substantial fix runs the stack vertical by dispatching that stack's seats directly, not by model-invoking themain-stack-agents-flowskill. - INLINE (no dispatch: Cursor, a non-stack project, or a scope too small to fan out) - do the same steps in-session: map and assess the architecture yourself against the house architecture skills, then apply the fixable cons directly, smallest blast radius first.
The loop
1. ANALYZE + ASSESS
Dispatch architecture-analyzer over the target. It loops its cheap code-analyzer to map the project, then writes/reconciles docs/architecture/ARCHITECTURE.md (the structure map) and docs/architecture/ASSESSMENT.md (10 reasoned strengths + 10 reasoned weaknesses, each weakness carrying a remediation and a tier: small / substantial / structural). Read docs/architecture/ASSESSMENT.md: the weaknesses are this loop's work list, the tier on each is its routing key, and any weakness the summary marks a deliberate tradeoff is left alone - do not 'fix' a conscious choice.
2. TRIAGE + FIX by tier
Take the open weaknesses in leverage order (the assessment's top-few first). Route each by its tier - and confirm the green baseline (build + tests) before you start, so a regression is visible: