architecture-debt-visualizerlisted

Reconcile a repo's design docs against its actual code AND/OR evaluate the architecture itself like a senior/staff architect — scalability, extensibility, long-term maintainability, performance/operational cost, data/entity-model soundness, observability, and whether the implementation still serves the product's stated technical vision. Classifies the repo's system type first so requirements are judged against what it actually is, not assumed to be a production service. Produces a scored, filterable HTML report. Use when the user asks to check if docs are stale, find architecture drift, audit docs vs. code, evaluate technical architecture, review data model / entity design, assess scalability or tech debt, or run an 'architecture debt' / 'architecture review' report. Triggers on phrases like 'check if our docs are still accurate' (reconcile mode), 'evaluate our architecture' / 'is this scalable' / 'review the data model' (evaluate mode), 'run an architecture debt audit' (full mode), 'architecture debt visuali
sumeetmi2/architecture-debt-visualizer · ★ 0 · Data & Documents · score 75

Install: claude install-skill sumeetmi2/architecture-debt-visualizer

# Architecture Debt Visualizer Two independent jobs: 1. **Reconciliation** — does the code still do what the docs say it does? (textual accuracy) 2. **Evaluation** — judging as a senior architect would, is the *architecture itself* sound, and does it still serve where the product is actually headed? (engineering judgment, classified against what kind of system this actually is — see step 1.5) Job 1 catches drift. Job 2 catches debt that was never wrong on paper because no doc ever made a claim about it. **Act as an independent evaluator, not a transcription service** in job 2 — it does not wait for a doc claim to react to. A `confirmed` reconciliation result does not make a bad pattern acceptable; judge quality separately, on its own merits. Full technique detail lives in `references/` — this file is the workflow skeleton and the non-negotiable rules. Read the referenced file at the point you reach that step; don't front-load all of them. ## Non-negotiable rules 1. Every finding needs cited evidence — see `references/evidence-standard.md`. 2. Verify data-architecture claims against actual DDL/schema, never a doc's prose description of its own schema. 3. Don't invent claims or risk without evidence — speculation isn't a finding. 4. Distinguish repository evidence from runtime/externally-managed configuration explicitly (see `evidence_type`/`limitations` in `references/report-schema.md`). 5. No minimum or maximum finding count, anywhere — see the coverage rule