Run any Skill in Manus with one click

adr-writer

Stars9

Forks0

UpdatedMay 15, 2026 at 01:57

Write an Architecture Decision Record (ADR) document for a technical decision. Use when documenting a technical choice, architectural decision, or design decision.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

davila7

davila7/claude-with-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

title	adr-writer
name	adr-writer
description	Write an Architecture Decision Record (ADR) document for a technical decision. Use when documenting a technical choice, architectural decision, or design decision.

Instructions

If the user has not specified a decision topic, ask for it before proceeding. One clarifying question is sufficient — ask for the decision, the context that led to it, and any alternatives they considered.

Write an ADR using the MADR (Markdown Any Decision Records) template below. Fill in all sections based on what the user has provided. Use direct, factual language throughout.

Template

# [Short title describing the decision and its solution]

## Status

[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]

## Context

[Describe the problem, constraint, or situation that made this decision necessary.
Include any relevant technical context, business requirements, or constraints.
This section answers: what forced us to make a decision?]

## Decision

[State the decision clearly and directly.
Start with "We will..." or "We decided to..."
Explain the key reasoning in one to three sentences.]

## Alternatives considered

- **[Alternative 1]**: [Brief description]. Rejected because [reason].
- **[Alternative 2]**: [Brief description]. Rejected because [reason].

## Consequences

**Positive:**
- [What becomes easier, faster, or safer as a result]

**Negative:**
- [What becomes harder, more expensive, or constrained as a result]

**Neutral:**
- [Things that change but are neither clearly good nor bad]

Filing the ADR

After writing the document, check whether either of these directories exists:

docs/adr/
docs/decisions/

If one exists, offer to save the file there with a filename following the pattern NNNN-short-title.md where NNNN is the next sequential number (check existing files to determine the sequence). If neither directory exists, output the document to the conversation and suggest the user create docs/adr/ and save it there.

One ADR per decision

Do not combine multiple decisions into one ADR. If the user describes two distinct decisions, write two separate ADRs.

More from this repository

same repository

explain-code

davila7/claude-with-skills

Explains code in plain language for someone unfamiliar with the programming language. Use when asked to explain code, walk through logic, describe what a function does, or when the user says "explain this" or "walk me through this".

2026-05-159

summarize-changes-headless

davila7/claude-with-skills

Summarizes uncommitted git changes in a concise machine-readable format. Use in CI pipelines, scripts, or headless invocations where the output will be piped or captured.

2026-05-159

hello-skill

davila7/claude-with-skills

Explains what a skill is and demonstrates that skills are working. Use when testing skills, when asked about skills, or when asked to demonstrate how skills work.

2026-05-159

personal-greeting

davila7/claude-with-skills

Demonstrates the personal scope for Claude Code skills. Use when testing personal-scoped skills or when the user wants to understand the difference between personal and project skill scopes.

2026-05-159

project-conventions

davila7/claude-with-skills

Lists the conventions for this project and demonstrates the project scope for Claude Code skills. Use when asked about project conventions, code style, or as a demonstration of project-scoped skills.

2026-05-159

changelog-entry

davila7/claude-with-skills

Draft a CHANGELOG.md entry for the current changes in Keep a Changelog format. Use when releasing, tagging a version, or updating CHANGELOG.md.

2026-05-159

# [Short title describing the decision and its solution] ## Status [Proposed | Accepted | Deprecated | Superseded by ADR-XXX] ## Context [Describe the problem, constraint, or situation that made this decision necessary. Include any relevant technical context, business requirements, or constraints. This section answers: what forced us to make a decision?] ## Decision [State the decision clearly and directly. Start with "We will..." or "We decided to..." Explain the key reasoning in one to three sentences.] ## Alternatives considered - **[Alternative 1]**: [Brief description]. Rejected because [reason]. - **[Alternative 2]**: [Brief description]. Rejected because [reason]. ## Consequences **Positive:** - [What becomes easier, faster, or safer as a result] **Negative:** - [What becomes harder, more expensive, or constrained as a result] **Neutral:** - [Things that change but are neither clearly good nor bad]