Creates new Architecture Decision Records (ADRs) for architectural changes using repo conventions for naming, numbering, and storage. Use when documenting decisions, rationale, and trade-offs.
From developer-kitnpx claudepluginhub giuseppe-trisciuoglio/developer-kit --plugin developer-kitThis skill is limited to using the following tools:
references/examples.mdreferences/template.mdSearches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Guides agent creation for Claude Code plugins with file templates, frontmatter specs (name, description, model), triggering examples, system prompts, and best practices.
Creates new Architecture Decision Record (ADR) documents for major architectural choices so teams can keep a clear history of why important technical decisions were made.
This skill helps create a new ADR from discovery to final markdown file. It confirms the decision details, inspects the repository for any existing ADR conventions, and drafts a new ADR with the standard sections Title, Status, Context, Decision, and Consequences.
When the repository does not already have an ADR convention, default to storing ADRs in docs/architecture/adr and use a zero-padded filename such as 0001-use-postgresql-for-primary-database.md.
See references/template.md for the default ADR template and references/examples.md for example ADRs and naming patterns.
Use this skill when a user or agent has decided on a meaningful architectural change and needs to document the rationale, chosen direction, and trade-offs in a new Architecture Decision Record. It fits requests such as creating an ADR, documenting an architecture decision, writing a decision record, or preserving the project history behind an important technical choice.
Ask the user for the minimum information needed to draft a new ADR:
Proposed by default if not yet finalized)If the user actually wants to update an existing ADR, change statuses in older ADRs, or manage supersession links, explain that this skill only drafts new ADR documents and ask whether they want to proceed with a new record instead.
Inspect the repository before drafting:
docs/architecture/adrdocs/adradrarchitecture/adrdocs/architecture/adr0001Preferred default naming when no convention exists:
docs/architecture/adrNNNN-short-kebab-title.md# ADR-NNNN: <Decision Title>Create a draft using the standard structure:
# ADR-NNNN: Decision Title
## Status
Proposed
## Context
What problem, constraints, or trade-offs led to this decision?
## Decision
What architectural choice was made?
## Consequences
What becomes easier, harder, riskier, or more expensive because of this decision?
Drafting rules:
Before writing files, present:
Ask for approval before creating the file. If the user wants adjustments, revise the draft first.
After approval:
User request: "Create an ADR for moving from SQLite to PostgreSQL"
Expected flow:
docs/architecture/adr/0001-move-to-postgresql.mdUser request: "Document the decision to split billing into a dedicated service"
Expected flow:
See references/examples.md for longer ADR examples.
Proposed unless the user confirms another statedocs/architecture/adr if the repository already uses another ADR location