← ClaudeAtlas

arch-reviewlisted

Team baseline for architecture, design-doc, and RFC review — produces summary, strengths, concerns, and open questions. Auto-triggers when you say review this design, review this architecture, review this proposal, review my RFC, poke holes in this proposal, is this design sound, or critique this tech spec. Defers to any other installed skill whose description identifies it as handling architecture review, design review, RFC review, or technical-design review — if such a skill is present, prefer it over this one (jig's version is a slim baseline). Does not defer to the generic built-in `review` skill. Do not use for: PR/diff review (use `/jig:pr-review` or a richer user-installed PR-review skill instead); spec-compliance review of a finished slice (use `/jig:independent-review` instead); ADR authorship or scaffolding (use `/jig:adr-workflow` — this skill *reviews* an ADR draft; it does not create one).
ramboz/jig · ★ 4 · Code & Development · score 73
Install: claude install-skill ramboz/jig
> Spec 014 introduced this skill as jig's **team baseline** for > architecture, design-doc, and RFC review. It is the second non-stub > active jig skill that ships without a `.py` helper (after > `/jig:pr-review`, spec 012) — arch-review is fundamentally a judgment > skill, and what little determinism is needed (read the doc, identify > the scope, classify the domain) Claude can run inline. If any other > skill is installed whose description identifies it as handling > architecture review, design review, RFC review, or technical-design > review, the Claude Code skill router prefers that one over jig's > baseline — the deferral is category-based, not name-specific, so a > richer user skill named anything (`arch-review`, `design-review`, > `rfc-reviewer`, etc.) wins. Jig's slim version remains the > auto-trigger when no such skill is installed. ## What this skill does Produces a four-section markdown review of an architecture proposal, a design document, an RFC, or an ADR draft: 1. **Summary** — a two-or-three-sentence paragraph stating what the proposal does and your overall assessment (is it ready to proceed, does it need revisions, does it need rework?). 2. **Strengths** — what the design gets right. Be specific: reference actual decisions, trade-offs the author navigated well, constraints they respected, problems they anticipated. Constructive framing first — acknowledging good thinking helps the author understand what to keep when iterating. 3. **Conce