Install
$ agentstack add skill-daaa1k-skills-create-adr-from-conversation ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo 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.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Create ADR from conversation
Goal
Produce a new Markdown ADR file that matches this repository’s ADR rules and template, using information from the ongoing conversation (or the user’s explicit summary if the conversation lacks detail).
Source of truth (read before writing)
- Structure and section order —
docs/adr/template.md
Copy its headings and section layout. Remove HTML comment placeholders from the final file; replace them with real content.
- Operating rules —
docs/adr/README.md
Follow lifecycle, status definitions, naming, alternatives rules, scope, and anti-patterns. If anything in this skill conflicts with README.md, README wins.
If either file is missing or path differs, ask the user or search the repo for the current ADR docs location.
Workflow
- Confirm scope — Per
README.md, ADRs cover technology choices, architectural policy, API design, and other long‑impact decisions—not one-off implementation details or purely local/temporary choices. If the topic is out of scope, say so briefly and suggest a lighter doc (issue, PR description) instead.
- Resolve the next filename — List
docs/adr/*.mdand pick the next four-digit prefix after the highest existingNNNN-*.md. Use kebab-case after the number, perREADME.mdnaming (0001-use-rest-api.mdstyle).
- Extract from the conversation — Infer or ask for:
- Problem / background (Context)
- The adopted conclusion (Decision) and final
Status(Accepted,Rejected,Deprecated, orSuperseded) - Tradeoffs and operational impact (Consequences: real pros and cons)
- Options that were considered, each with summary and reason not adopted (required for alternatives that matter)
- Write the file — Fill every section the template defines. Do not leave instructional comments from the template in the committed ADR.
Status and lifecycle (from README)
- No
Proposed. The ADR is written with a terminal status from the start. Rejected— Still record when a serious option was not adopted; rejection rationale is valuable.Superseded/Deprecated— Use as defined in README; link related ADRs when replacing or obsoleting a decision.
Tone: objective judgment (required)
ADR text should help future readers reconstruct a fair picture of the decision, not sell the outcome.
- Decision — State what was chosen in clear, neutral language. Avoid superlatives (“best,” “ideal,” “obvious”) unless the conversation established measurable criteria.
- Consequences → Pros — List real benefits without stacking adjectives or repeating the same point. One honest line beats three promotional ones.
- Consequences → Cons — Always include genuine downsides, constraints, or risks. If the chosen path has no meaningful downside, say what was traded off (e.g. complexity elsewhere, narrower option space) or note “limited downside in current scope” and why.
- Alternatives — For each option not adopted, give a factual summary and a concrete reason it was not chosen. Do not straw-man alternatives to make the picked option look better.
If the conversation only contains enthusiasm for one option, still add a short “what we give up” or “what we did not pick and why” so the ADR stays balanced.
Output
- Path:
docs/adr/NNNN-short-description.md(new file; do not overwrite existing ADRs unless the user explicitly asks to amend a draft before merge). - Format: Valid Markdown matching
template.mdsections. - Links: Add
## Linksentries when issues, PRs, or external references exist.
Checklist before finishing
- [ ] Filename and numbering follow
README.md - [ ]
Statusis one of the allowed final states; noProposed - [ ]
Alternatives Consideredentries that matter include both summary and reason not adopted - [ ] Consequences include both pros and cons (or explicit statement when tradeoff is negligible)
- [ ] Wording is factual and proportionate—not advocacy for the chosen path
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: daaa1k
- Source: daaa1k/skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.