AgentStack
SKILL verified MIT Self-run

Adr

skill-0xrafasec-ai-workflow-adr · by 0xrafasec

Create an Architecture Decision Record (ADR) — a single numbered file capturing context, options, and the choice made. Use whenever the user wants to document a design decision, says 'record why we picked X', 'write an ADR', 'lock in this choice', or is choosing between technical options worth preserving for future contributors. Invoked as /adr <title>.

No reviews yet
0 installs
19 views
0.0% view→install

Install

$ agentstack add skill-0xrafasec-ai-workflow-adr

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Adr? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Create an Architecture Decision Record. Argument: $ARGUMENTS

Context

ADRs capture a single decision — the context, options considered, and the choice made. They're lightweight and accumulate over time. Each ADR is a separate numbered file.

Context Gathering

  1. Check docs/adr/ for existing ADRs — determine the next number. If no ADRs exist, start at 0001.
  2. Read recent ADRs (last 2-3) to match the project's style and voice.
  3. If the decision relates to architecture, read docs/ARCHITECTURE.md for context.

Interview

Use AskUserQuestion to extract the decision. Keep it focused — an ADR is one decision, not a design doc.

  1. What's the decision? — What are you deciding? What triggered this decision?
  2. Context — What constraints, requirements, or pressures led to this? What's the current state?
  3. Options considered — What alternatives did you evaluate? What are the tradeoffs of each?
  4. Decision — What did you choose and why? What was the deciding factor?
  5. Consequences — What changes as a result? What are the known downsides you're accepting?

If the decision is straightforward (user already knows what they want and why), keep the interview to 1-2 questions to fill in gaps.

Write

Write to docs/adr/NNNN-.md:

# ADR-NNNN: [Title]

**Status:** Proposed | Accepted | Deprecated | Superseded by [ADR-XXXX]
**Date:** [date]
**Deciders:** [who was involved]

## Context

[What is the issue? What forces are at play? What constraints exist?]

## Decision

[What was decided. State it clearly in one sentence, then elaborate if needed.]

## Options Considered

### Option A: [Name]
- **Pros:** [benefits]
- **Cons:** [drawbacks]

### Option B: [Name]
- **Pros:** [benefits]
- **Cons:** [drawbacks]

### Option C: [Name] (if applicable)
- **Pros:** [benefits]
- **Cons:** [drawbacks]

## Consequences

### Positive
- [What improves]

### Negative
- [What gets harder or what risks are accepted]

### Neutral
- [What changes without clear positive/negative valence]

## Related

- [Links to related ADRs, specs, issues, or documents]

After Writing

  1. Present the ADR to the user for review.
  2. Ask if the status should be "Proposed" (needs team review) or "Accepted" (decided).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.