From memoryrelay
Use when making architectural choices, evaluating alternatives, revisiting past decisions, or needing to check whether a decision already exists before committing to a direction.
How this skill is triggered — by the user, by Claude, or both
Slash command
/memoryrelay:decision-trackingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Decisions are **choices with rationale and alternatives considered**. Plain facts, findings, or information are memories — use `memory_store` for those (see `memory-workflow` skill).
Decisions are choices with rationale and alternatives considered. Plain facts, findings, or information are memories — use memory_store for those (see memory-workflow skill).
| Tool | Signature | Purpose |
|---|---|---|
decision_record | decision_record(title, rationale, alternatives?, project?, tags?, status?) | Record a new decision with reasoning |
decision_list | decision_list(project?, status?, tags?, limit?) | List decisions, optionally filtered |
decision_supersede | decision_supersede(old_id, new_title, new_rationale, tags?) | Replace an outdated decision |
decision_check | decision_check(query, project?, limit?, threshold?) | Semantic search for conflicting decisions |
decision_check(query, project) before making an architectural choice. This surfaces existing decisions that may conflict or already cover the topic.decision_record(title, rationale, alternatives, project, tags). Include why this option was chosen, what alternatives were rejected, and tags for categorization.decision_supersede(old_id, new_title, new_rationale). This preserves history while marking the old decision as replaced.decision_list(project, status) to audit active decisions during planning or refactoring. Filter by status: "active" to see current decisions only.Decisions must be scoped to the relevant project (see project-orchestration skill for project setup):
defaultProject in plugin config to avoid passing project on every call.project explicitly when working across multiple projects.| Store as Decision | Store as Memory |
|---|---|
| "Use PostgreSQL over MongoDB for user data" | "PostgreSQL supports JSONB columns" |
| "Adopt ESM modules, drop CommonJS" | "Node 20 supports ESM natively" |
| "API versioning via URL path, not headers" | "Team prefers REST over GraphQL" |
| Mistake | Fix |
|---|---|
Recording decisions with memory_store | Use decision_record — decisions need rationale tracking and conflict detection |
Making choices without decision_check | Always check first; conflicting decisions cause inconsistent architecture |
| Adding a new decision when one already exists | Use decision_supersede to replace the old decision, preserving history |
Omitting the project parameter | Scope every decision to a project via parameter or defaultProject config |
| Storing facts as decisions | Only choices with rationale belong in decisions; use memory_store for information |
Not using tags | Tags enable filtering with decision_list(project, tags: "api,auth") |
npx claudepluginhub memoryrelay/memory-relay-skills --plugin memoryrelayRecords significant architectural decisions like database choices, frameworks, or core patterns in docs/decisions.md. Activates on major decisions, explicit requests, or proactively at session ends.
Guides creation of decision records with full context, alternatives, rationale, and revisit conditions. Auto-links related PRDs, strategy docs, OKRs. Useful for product decision documentation.
Guides structured decision-making interviews for architectural and technical choices, evaluating options with pros/cons tables, recommending, confirming, and recording decisions.