rvo-documentation

Reviews arc42 architecture documentation (AsciiDoc/.adoc) and gives concrete, prioritized suggestions to make it shorter, more precise, and diagram-first. Use this any time the user shares or references an .adoc architecture chapter/subchapter, an arc42 section, a cross-cutting concept, or asks for feedback, review, or a quality check on architecture documentation — even if they don't say "arc42" explicitly. Also use when the user wants to know if a chapter answers the right questions, has too much prose, or is missing diagrams, or wants a rewritten/shortened draft of a specific section. Triggers on requests like "review this chapter", "is this building block view any good", "check my cross-cutting concept doc", "this arc42 section feels bloated".

Use this skill when the user wants to wrap up, close out, or end a working session in a repo-backed project (e.g. "let's wrap up", "close out for today", "bye", "done for now", or explicitly invoking /document-knowledge-gained, optionally with a topic like "/document-knowledge-gained about the CI/CD" to scope it). Captures durable, project-specific knowledge that surfaced during the conversation — architecture decisions, gotchas, non-obvious behavior, naming conventions, system boundaries — and folds it into the project's existing documentation (as structured by AGENTS.md) rather than losing it when the chat ends. Always trigger this at explicit session-end signals in a git repo context, even if the user doesn't mention documentation directly — that's the whole point of the skill.

Triage feedback after an externally maintained skill, agent, or MCP run and produce a safe, copy-ready issue template for its maintainer.

Define, adjust, and maintain Structurizr DSL (*.dsl) workspaces and C4 views. Use when the user asks to create/update architecture models, fix DSL syntax/identifier issues, add containers/components/relationships, update dynamic/deployment views, refactor with archetypes/expressions, or validate/inspect a workspace.

Keeps requirements bi-directionally traceable to code, architecture docs, and tests. Use whenever the user creates or edits code, architecture documentation, or tests that implement or verify a requirement, whenever a requirements source (requirements management tool or in-repo requirements doc) is read, or whenever the agent encounters code/docs/tests that plausibly realize a requirement but carry no reference to it. Also use when asked to check, report on, or clean up traceability/coverage between requirements and the codebase.