Architektúra és döntési feljegyzések
Valódi rendszerhatárokat és jelentős technikai döntések indokait teszi érthető, karbantartható dokumentációvá.
documentation-and-adrs
Nézd meg, miben segítMikor hasznos?
Akkor használd, ha tudni kell, hová tartozik egy működés vagy miért született egy döntés.
Miben segít neked?
- Tényleges fájlokhoz köti a folyamatokat, modulokat és adatáramlást.
- Rögzíti az állapottulajdonost és sérthetetlen működési szabályokat.
- Leírja az alternatívákat, kompromisszumokat és döntési állapotot.
Például ezt kérheted
Dokumentáld a háttérfeladat életciklusát, majd indokold döntési feljegyzésben az állapot tárolásának felelősét. Kövess sorfeladatot sikeres futáson, újrapróbáláson és megszakításon át. A döntési feljegyzés nevezze meg a tartós állapot gazdáját és az elvetett alternatívák okát.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
Architecture & Decision Records
Explain the system's structure, data flow and invariants so a developer knows where new behavior belongs, which boundaries must hold, and why significant technical decisions were made.
1. Architecture overviews that trace real boundaries
- System map: name the runtime processes, packages or services (
server,ui,workers,database, external providers) and state the single responsibility of each. - Data and control flow: walk through the main end-to-end flows (such as an incoming HTTP request, a background job lifecycle or a real-time event stream) from entry point to storage and back.
- State and ownership: state where each kind of state lives (database tables, in-memory caches, URL/client state, filesystem artifacts) and which module is allowed to mutate it.
- Invariants and constraints: highlight the rules that must never be violated (security invariants, transaction boundaries, tenant isolation, idempotency, ordering guarantees).
- Ground every diagram or module list in actual directory paths and entry files; never draw boxes for layers that do not exist in the repository.
2. Architecture Decision Records (ADRs)
Record an ADR whenever a choice has lasting consequences across modules, data models, dependencies, security or operations. Each ADR must state:
- Title and status:
Proposed,Accepted,Superseded by ADR-NNNorDeprecated, with the date or change context. - Context and problem: the technical, product and operational forces at play, stated neutrally without pre-judging the answer.
- Alternatives considered: the realistic options evaluated (including doing nothing or extending an existing pattern) and their trade-offs.
- Decision: the chosen approach and the concrete reason it won over the alternatives.
- Consequences: what becomes easier, what becomes harder, what risks or limits remain, and how the decision is enforced or verified.
3. Keep architecture docs alive
- When a new ADR supersedes an earlier decision, keep the old ADR for historical context, mark its status as
Superseded by ..., and update the active architecture overview to reflect current reality. - Never present an unaccepted proposal or future target architecture as the system that runs today.
Before you finish
- Every module, package and boundary named in the overview points to real paths in the repo.
- End-to-end data flow and state ownership are clear.
- Each ADR records status, context, alternatives considered, decision and consequences.
- Accepted decisions, open proposals and superseded historical records are clearly distinguished.
Csomagban lévő fájlok 2
LICENSE.txtSKILL.md
A skillcsomag bemutatása
documentation-and-adrs
documentation-and-adrs: Pontos, használható és a kódhoz kapcsolódó fejlesztői dokumentációt, API-útmutatókat és üzemeltetési leírásokat készít és tart karban.
Összecsukás
documentation-and-adrs
documentation-and-adrs: Pontos, használható és a kódhoz kapcsolódó fejlesztői dokumentációt, API-útmutatókat és üzemeltetési leírásokat készít és tart karban.
A teljes skillt és a hozzá tartozó fájlokat tartalmazza (2 fájl). Az alábbi eredeti leírás rögzíti a pontos alkalmazási területét.
A skill eredeti leírása (a forrás nyelvén)
Use when writing or updating architecture overviews, system design documents, module boundary guides or Architecture Decision Records (ADRs) that explain how components fit together, why key decisions were made, what alternatives were rejected and what consequences follow.
Telepítsd a skillt, nézd át a forrását és a megbízhatósági beállításait, majd engedélyezd a megfelelő projektben vagy ügynöknél.
Előfeltételek
- A számítógépedre telepített Orqestria.
