Help us improve
Share bugs, ideas, or general feedback.
From hugin-v0
Write, validate, and commit Architecture Decision Records in MADR 4.0.0 format. Use when user says 'write an ADR', 'create an ADR', 'document this decision', 'ADR for X', 'architecture decision record for X', 'record this decision', 'document the decision to use X', or wants to formally capture an architectural choice. Do NOT trigger on 'what ADR covers X?', 'show me the ADR for Y', 'does this violate an ADR?', or 'check ADR compliance' - those are lookup/audit tasks.
npx claudepluginhub michelve/hugin-marketplace --plugin hugin-v0How this skill is triggered — by the user, by Claude, or both
Slash command
/hugin-v0:adr-writer supersedes: NNNN (optional, when replacing an existing ADR)supersedes: NNNN (optional, when replacing an existing ADR)The summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill uses extended thinking for complex architectural trade-off analysis. ultrathink
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
Share bugs, ideas, or general feedback.
This skill uses extended thinking for complex architectural trade-off analysis. ultrathink
Writes complete, validated Architecture Decision Records in MADR 4.0.0 format and commits them to docs/decisions/. Follow write-adr.prompt.md for the full 10-step workflow.
Activate on:
check-adr-violations.prompt.md with a supersedes: NNNN parameterDo NOT activate on:
check-adr-violations.prompt.mdcheck-adr-violations.prompt.mdEvery ADR must contain all five mandatory sections. Missing any one = invalid.
| Section | Required | Notes |
|---|---|---|
| YAML frontmatter | ✅ | status + date always present |
| Context and Problem Statement | ✅ | 2–4 sentences, factual, project-specific |
| Considered Options | ✅ | 2–4 options, concise noun phrases |
| Decision Outcome | ✅ | Must start with Chosen option: "X", because |
| Consequences | ✅ | At least one Good + one Bad bullet |
Decision Outcome - exact format:
Chosen option: "{option name}", because {justification}.
Consequences bullets - exact format:
- Good, because {positive consequence}.
- Bad, because {negative consequence}.
- Neutral, because {neutral consequence}.
docs/decisions/README.md - find highest NNNNNNNN-short-title.md (lowercase kebab-case, max 5 words)docs/decisions/README.md after writing the file| Status | When to use |
|---|---|
accepted | Decision is made and implemented (most common) |
proposed | Decision under discussion, not yet implemented |
superseded | Replaced by a newer ADR - add superseded-by: NNNN - Title |
deprecated | No longer relevant, not replaced |
When replacing an existing ADR (triggered by violation checker or user intent):
supersedes: "NNNN - Old Title"status: superseded + superseded-by: "NNNN - New Title"docs/decisions/README.md status column → supersededacceptedIf the user asks for external evidence or benchmarks to support the decision, invoke the web-research-specialist agent before finalizing. Use its findings in the Consequences section or a More Information section.
When invoked with the supersedes: NNNN argument (either by user or from check-adr-violations.prompt.md), the $ARGUMENTS variable contains the ADR number to supersede.
Example invocation: /adr-writer supersedes: 0005
The argument is parsed to:
status: supersededsupersedes: "0005 - Old Title" to the new ADR frontmatterIf no arguments are provided, this is a new ADR with no supersession relationship.
This skill logs the session ID using ${CLAUDE_SESSION_ID} for correlation:
ADR creation session: ${CLAUDE_SESSION_ID}
This allows tracking which ADRs were written in the same conversation and correlating with git commits when troubleshooting.
Invoke .github/prompts/write-adr.prompt.md and follow its steps in order. Do not shortcut or skip the validation step.