← ClaudeAtlas

architecture-doc-writerlisted

How to write and maintain EITR's architecture documentation (docs/architecture/) - arc42-lite structure for the living system description, Nygard-format ADRs for individual decisions. Load before editing anything under docs/architecture/, or when asked to document a new architectural decision.
ivanestar/eitr · ★ 4 · AI & Automation · score 77
Install: claude install-skill ivanestar/eitr
# Architecture Documentation Standard `docs/architecture/` is EITR's living architecture description. It follows two established, industry-standard formats rather than an invented one - [arc42](https://arc42.org/documentation/) for the overall document structure and [Nygard-format ADRs](https://adr.github.io/) for individual decisions - because both are well-understood, and reusing an established format means a reader already knows how to navigate it. ## The hard rule: describe the system, don't narrate its history `docs/architecture/` documents **what the system is and why it is shaped this way, in the present tense.** It is not a log of who decided what on which date. Every one of these patterns is disallowed in `docs/architecture/`: - `"Confirmed with the user after..."`, `"Decided on 2026-08-29..."`, `"Status: PIVOTED..."` - `"SUPERSEDED by the pivot above"`, `"(HARDENED)"` - stale-marking prose instead of just deleting the stale content or writing a new ADR that supersedes the old one - `"Env note (settled this session): ..."` - session/environment trivia that belongs in a commit message or `TODO.md`, not the architecture description That kind of narrative belongs in `CHANGELOG.md` (what shipped, when) or `git log` (who changed what and why, at the time). If you're tempted to write a date or "the user decided" into `docs/architecture/`, stop - either the content is a decision (write an ADR) or it's just the current state (write it as a plain, dateless fact). ##