WHAT — Create and maintain Architecture Decision Records (ADRs) per the agentic-workstation process. Covers when to write an ADR, required sections, review, and linking to epics/PRs. English for cross-team artifacts unless the user asks otherwise.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
WHAT — Create and maintain Architecture Decision Records (ADRs) per the agentic-workstation process. Covers when to write an ADR, required sections, review, and linking to epics/PRs. English for cross-team artifacts unless the user asks otherwise.
ADR — Architecture Decisions (WHAT)
Template:references/default-template.md — local reference for ADR structure and workflow.
Default guardrails (before any final content)
Apply dots-workstation-output-handshake: confirm where the final ADR will be recorded and that a human will review.
Then follow the steps below.
When to use
Use dots-workstation-decision-log for lightweight product/project/operational decisions and dots-workstation-agreement for explicit commitments or terms among parties. Use this ADR skill only for durable architecture or technical decisions.
A change has long-term architectural, security, data-model, or cost impact.
You need options with pros/cons and a record for future readers (and for supersession later).
The project needs decisions linked to PRDs, TRDs, tasks, PRs, diagrams, or other supporting artifacts.
Instructions
Confirm the decision qualifies (new service, tech selection, schema change, deployment change, etc.) per the agentic-workstation "When to Create an ADR" criteria.
Draft using the six-part structure: Title & status, Context, Options, Decision, Consequences, References (link PRD/TRD, tasks, PRs, diagrams as applicable).
Review with the tech lead / peers as in the workflow; keep ADRs short and actionable (clarity over completeness).
Link the ADR to the relevant epic or story and to PRs in the forge (use github-cli-workflow / gitlab-cli-workflow for PR text when applicable).
If an ADR is superseded, preserve history: update status and point to the replacement document.
What not to do
Do not use an ADR for one-line fixes with no long-term effect (use a normal task or PR description).
Do not paste the full org policy into this skill; keep a single canonical copy in the wiki.
References
dots-workstation-output-handshake — destination and review
references/default-template.md — ADR structure and workflow
references/example-001-graphql-adoption.md — example ADR for a GraphQL migration decision
dots-workstation-trd — where technical design references decisions
