silo: Skill for Claude Code

Architecture review

Review code only for architectural concerns. Code quality, naming, formatting, and test style are explicitly out of scope — pnpm lint, .agents/skills/silo-testing/SKILL.md, and ordinary code review cover those. This skill asks one question: does this code fit the architecture Silo has already decided on, and where it doesn't, is that a deliberate, recorded decision or an accident?

This skill is the review itself. The human loop around it — who runs which step in which session, how to spot-check findings before acting on them, and why the author, reviewer, and fixer are never the same session — is docs/architecture-review-workflow.md.

It runs in two modes, and step 2 picks one:

• Mode A — a change. A PR, a branch, or the working tree. Baseline is main; the change's additions are the scope.
• Mode B — standing code. A package, a bundled extension, or a subsystem that has existed for a while. Baseline is the ADRs; the scope is whatever boundary you draw and state.

1. Load the architecture of record

Silo has no C4 model, and the architecture is written down across several files. All of them are input to this review, but start here:

• docs/architecture.md — the structural map: the package table and its dependency edges, the layering inside the host, the Rust/webview process split, the persistence destinations, and which packages publish. Deliberately facts-only, and its package table is drift-checked by a unit test. Read it first to orient; it tells you which ADRs the code under review answers to.
• AGENTS.md → "Architecture boundaries — enforced, don't regress" — the package graph, the ctx/SDK-only rule for extensions, the platform ban, the CSS token tiers, the design-system kit and the chrome line, the Tooltip and focus-ring rules, host logging. This is the densest statement of the boundaries and the first thing to read.
• AGENTS.md → "Engineering principles" — simplest implementation that meets current requirements, grow in layers, no stopgaps. These are what you judge "is this the right shape" against.
• docs/decisions/ — the ADRs, the durable why. Read docs/decisions/README.md for the index and skim it for ADRs the code under review touches; open the ones that apply in full. Do not review from the index titles alone. Note each one's date: — in Mode B you need it.
• docs/proposals/ — RFCs. Code implementing a proposal must match it; code contradicting an open one is a finding.
• docs/domain-language.md — the glossary. Vocabulary in the code that isn't here, or that collides with a term that is, is an architectural finding (see .agents/skills/silo-domain-modeling/SKILL.md).
• docs/change-planning-convention.md — whether the work was big enough to have needed a proposal at all.
• Surface-specific rules when the code touches them: docs/modal-design.md, docs/side-panel-design.md, apps/docs/guide/extension-checklist.md (any new or changed extension), docs/adding-a-coding-agent.md (agent catalog changes), apps/docs/roadmap.md (public SDK surface).