Archi Full
Use this skill for full-project baseline architecture review.
Workflow
- Inspect the available architecture-analysis command shape before assuming
flags.
- Use
archi-evidence-map when deciding whether to use Architec/Hippo,
dependency graphs, architecture tests, Semgrep, CodeQL, or direct review.
- Run or read full-project architecture review evidence only when available or
requested.
- Refresh structural inputs only when the user asks for fresh evidence, the
snapshot is stale, or stale evidence is central to the question.
- Read project docs, module maps, dependency rules, and representative source
paths directly.
- Route focused findings to
archi-dependency-topology,
archi-module-boundaries, archi-fitness-functions,
archi-decision-drift, archi-change-impact, or
archi-distributed-systems when the baseline needs that method.
- Use vendored
improve-codebase-architecture when the review is looking for
deep-module, seam, adapter, leverage, locality, or interface-depth
opportunities.
- Use vendored
code-review-and-quality when the baseline needs adjacent
correctness, security, performance, or review-quality coverage.
- Read
.architec/architec-summary.md first when present.
- Use
.architec/architec-analysis.json for exact scores, concerns, signals,
hotspots, and artifact paths.
Output
Score
- overall:
- key reading:
Problems
- ...
Improvements
- ...
Verification
- ...
Do not turn full review into task-goal planning. Use archi-advice when the
user wants a refactor roadmap.
If the tool baseline is missing, produce a source-backed baseline with an
explicit "tool evidence unavailable" note.
1---2name: archi-full-23description: Run or read full-project architecture analysis and summarize structural weaknesses, hotspots, and maintainability risks.4---56# Archi Full78Use this skill for full-project baseline architecture review.910## Workflow11121. Inspect the available architecture-analysis command shape before assuming13 flags.142. Use `archi-evidence-map` when deciding whether to use Architec/Hippo,15 dependency graphs, architecture tests, Semgrep, CodeQL, or direct review.163. Run or read full-project architecture review evidence only when available or17 requested.184. Refresh structural inputs only when the user asks for fresh evidence, the19 snapshot is stale, or stale evidence is central to the question.205. Read project docs, module maps, dependency rules, and representative source21 paths directly.226. Route focused findings to `archi-dependency-topology`,23 `archi-module-boundaries`, `archi-fitness-functions`,24 `archi-decision-drift`, `archi-change-impact`, or25 `archi-distributed-systems` when the baseline needs that method.267. Use vendored `improve-codebase-architecture` when the review is looking for27 deep-module, seam, adapter, leverage, locality, or interface-depth28 opportunities.298. Use vendored `code-review-and-quality` when the baseline needs adjacent30 correctness, security, performance, or review-quality coverage.319. Read `.architec/architec-summary.md` first when present.3210. Use `.architec/architec-analysis.json` for exact scores, concerns, signals,33 hotspots, and artifact paths.3435## Output3637```text38Score39- overall:40- key reading:4142Problems43- ...4445Improvements46- ...4748Verification49- ...50```5152Do not turn full review into task-goal planning. Use `archi-advice` when the53user wants a refactor roadmap.5455If the tool baseline is missing, produce a source-backed baseline with an56explicit "tool evidence unavailable" note.
seemseam