القائمة
Use when choosing between competing technical approaches, recording why an architecture decision (ADR) was made, or revisiting a previous ADR
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | architecture-decision-record |
| description | Use when choosing between competing technical approaches, recording why an architecture decision (ADR) was made, or revisiting a previous ADR |
Create architecture decision records (ADRs) following the MADR (Markdown Any Decision Records) standard. ADRs capture the context, options considered, and rationale behind significant architecture decisions.
The ADR template contains the full MADR document structure ready to copy into a project. Optional sections are marked with HTML comments and can be removed for a minimal ADR. This skill describes when and how to use it.
Announce at start: "I'm using the architecture-decision-record skill to create an ADR following the MADR standard."
Ask:
Use the plan location discovery process to find the right directory. When searching for existing directories, also check for ADR-specific locations: docs/decisions/, docs/adr/, docs/ADRs/, docs/architecture/decisions/. If no ADR directory exists, default to docs/decisions/.
Announce the chosen path and wait for user confirmation before writing.
List existing ADRs in the directory and use the next sequential number. Pad with leading zeros to match existing convention (e.g., 0001, 0012). Default to 4-digit padding.
Guide the user through each section using the ADR template. Do not skip required sections. For optional sections, ask if the user wants to include them. A minimal ADR only needs the three required sections.
Required sections:
Optional sections (remove if not needed):
Copy the template and fill in each section. File naming: NNNN-title-in-kebab-case.md.
| Status | Meaning |
|---|---|
| proposed | Decision is under discussion, not yet agreed upon |
| accepted | Decision has been agreed upon and should be followed |
| rejected | Decision was considered but not adopted |
| deprecated | Decision is no longer relevant or recommended |
| superseded by ADR-NNNN | Replaced by a newer decision; link to the successor |
When superseding an ADR, update the old ADR's status to point to the new one.
Translate ambiguous natural language specifications into a formal Intermediate Verification Language (IVL). Use when users provide English specs, requirements, or descriptions of desired behavior and need unambiguous, verifiable specifications. Triggers include phrases like "specify this", "formalize this", "make this unambiguous", "write a spec for", "write specs", "formal specs", "formal specification", "specify this project", "specify this codebase", or when reviewing English specs like SPEC.md files for ambiguities. Also use when asked to create formal specifications for an existing codebase by first exploring it to understand its behavior, then formalizing that behavior into IVL.
Review and improve prompts for Claude using Claude 4 best practices. Use when writing system prompts, optimizing agent instructions, or when the user asks to review/improve prompts with /prompting.
Analyze and fix code quality issues (KISS, YAGNI, DRY, SOLID, etc.). Use when reviewing code quality, refactoring, or checking for code smells.
ALWAYS use when creating git commits. Formats commit messages using Conventional Commits standard with gitmoji emojis.
Use when implementing any feature or bugfix, before writing implementation code
Creates, installs, validates, and formats Agent Skills. Use when developing skills from templates, installing skills from git repositories, linting against the specification, or managing skills across AI coding agents.
