Docs Architecture

Edit architecture documentation to reflect how the system actually behaves, not how it was intended to behave.

Treat runtime behavior, system boundaries, and enforced constraints as the source of truth. Assume existing architecture prose may be outdated until verified.

When To Use

• Use for architecture-facing documents such as ADRs, technical design notes, architecture diagrams, system overviews, boundary docs, and integration-flow docs.
• Use when a task requires verifying actual architecture before making decisions or changes, even if the user did not explicitly ask for a doc rewrite.
• Use when code, docs, or review feedback suggest the current mental model may be stale or aspirational.

Prefer docs-editor when the task is mainly about public-facing or operational documentation such as README, contributor docs, feature docs, or runbooks and the main goal is clarity of usage rather than architectural accuracy.

Prefer finish-review when the user wants an end-of-branch production-readiness review rather than architecture-document verification.

Objective

Enable correct decisions and safe system changes.