Use when creating, editing, superseding, or reviewing Architecture Decision Records (ADRs) or Product Decision Records (PDRs) under `docs/decisions/` (including `docs/decisions/architecture/` and `docs/decisions/product/`); writing MADR-formatted decision documents; recording rationale for an architectural or upstream-driven choice; linking a decision to a TRaSH Guides upstream source; changing a decision's status (proposed, accepted, deprecated, superseded). Triggers on phrases like "write an ADR", "new PDR", "document this decision", "decision record", "add an architecture decision", or any edit to files matching `docs/decisions/**/*.md`. Do NOT use for general architecture documentation under `docs/architecture/`.
76
93%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Procedural knowledge for creating ADRs (Architecture Decision Records) and PDRs (Product Decision
Records) in docs/decisions/.
MANDATORY: Read the relevant template before creating or editing ANY decision document.
docs/decisions/architecture/TEMPLATE.mddocs/decisions/product/TEMPLATE.mdOne decision per record. Do not bundle multiple decisions into a single ADR/PDR. Each decision should be independently trackable, referenceable, and supersedable.
Naming: NNN-kebab-case-title.md (sequential per category)
Date accuracy: Use the date the decision was made, not when documented. For existing decisions,
verify against git history (git log --format="%ai" <commit> -1).
Reference-style links: Use reference-style links for long URLs to respect line length limits:
- **Upstream:** [Discord DM][upstream] with TRaSH Guides contributor
[upstream]: https://discordapp.com/channels/@me/...proposed - Under consideration, not yet decidedaccepted - Decision made and finalizeddeprecated - No longer applies (context changed)superseded by {ADR,PDR}-NNN - Replaced by another decisionFor accepted decisions with pending implementation details, use accepted and note the pending
aspects in the document body.
ADR - Implementation choices, patterns, internal tradeoffs:
PDR - Upstream changes, feature scope, external drivers:
PDRs MUST have upstream: linking to the external driver. Private links (DMs, gated channels) are
acceptable; the link provides provenance even if not publicly accessible. If no upstream link is
available, ask the user for one before finalizing the PDR.
No individual names in PDR body. Use roles ("TRaSH Guides contributor", "upstream maintainer") rather than personal names. Reasons:
Upstream link is the audit trail. The link provides who/when/full-context; the PDR body provides what/why synthesis. If someone questions a decision and cannot access the link, the PDR rationale SHOULD stand on its own merits.
Private links are valid. Discord DMs, private channels, or gated sources are acceptable upstream references. The link serves as:
TRaSH Guides is the authoritative upstream; Recyclarr is a downstream consumer. PDRs document Recyclarr's response to guide decisions. Focus on:
Exclude references to other sync tools - they're peers responding to the same upstream, not relevant to Recyclarr's decisions.
f0a46c2
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.