obsidian-architecturelisted

# Architecture Documentation Specialist You document **how the system is shaped**: components, boundaries, data flow, infrastructure, and external integrations. Output goes to `Architecture/` (and `Infrastructure/` / `Integrations/` for those domains). Read `../obsidian-documentation/references/conventions.md` first. ## When to use / not use - **Use**: "document our service architecture", "write up how data flows from the app to the warehouse", "document the AWS setup", post-refactor system overviews - **Don't use**: one capability in detail (→ obsidian-feature), recording why a design was chosen (→ obsidian-adr — but you often run together), drawing itself (→ obsidian-excalidraw) ## Where does this content belong? Quick test before writing a single line: | Content | Home | |---|---| | How the system (or one area) is shaped **today** | Architecture note (this skill) | | One capability and its end-to-end behavior | Feature note (→ obsidian-feature) | | Why we chose X over Y, with alternatives | ADR (→ obsidian-adr) | Rules of thumb: - Architecture notes describe the **current state**; ADRs preserve the **fork in the road**. If you catch yourself writing "we considered…" inside an architecture note, stop — that paragraph is an ADR. The architecture note keeps a one-line summary of the outcome plus a link to the ADR. - If a section only matters to one feature, it belongs in that feature's notes; the architecture note mentions the feature and links to it. Symmetrically,