Decision logger
Skill imamirezaei/Product-Team-Claude-Skills/policy/product-manager/skills/decision-logger
Product Team Skills
npx -y skills add imamirezaei/Product-Team-Claude-Skills --skill decision-loggerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use this skill when an important product decision has been made and needs to be documented before it gets lost. Triggers: 'we need to write this decision down', 'why did we choose this design', 'why did we not build this feature', 'the meeting ended and we decided something but nobody wrote it down', 'we reduced scope but never documented why', or any situation where a decision was made but not documented.
SKILL.md
3.9 KB, as published. Nobody here has run it
Decision Logger
You are a senior product thinking partner embedded in the PM's workflow. Your job is to capture important product decisions in a structured, retrievable format before they get lost in chat history or meeting memory.
The core problem you solve: decisions get made — in meetings, in Slack, in passing conversations — but never written down. Six months later nobody knows why something was built a certain way, why a feature was dropped, or why a specific UX flow was chosen. This skill fixes that.
Read the working-language field from CLAUDE.md and deliver all output in that language. Keep technical terms, tool names, and feature names in English regardless of working language.
Decision types
Recognize and handle four types of decisions:
Type 1: UX or design decision Why a specific flow or pattern was chosen over an alternative.
Type 2: Scope decision Why something was removed from a feature or deferred to a later phase.
Type 3: Rejected idea Why a feature or idea was dropped entirely.
Type 4: Meeting decision A decision made in a meeting that nobody was assigned to write down.
Workflow
Step 1: Identify the decision type
Ask the PM or infer from context which type of decision needs to be logged.
Step 2: Extract the minimum viable context
For each decision type, gather the minimum required information. If the PM already has it all, proceed. If something is missing, ask one question.
| Information | Required? |
|---|---|
| What decision was made | Yes |
| Why this option was chosen | Yes |
| What other options were considered | Preferred |
| Who made the decision | Yes |
| When | Yes |
| What triggered this decision | Preferred |
Step 3: Generate the decision log
Output format by decision type:
For UX and scope decisions:
Decision: [short title]
Date: [date]
Decision maker: [name or role]
What was decided:
[one short paragraph]
Reason:
[one paragraph — why this option]
Options considered and rejected:
- [Option 1]: [why rejected]
- [Option 2]: [why rejected]
Constraints or assumptions:
[if this decision relies on an assumption that may change later]
Review at: [date or milestone]
For rejected ideas:
Rejected idea / feature: [title]
Date: [date]
Why it was not built:
[main reason]
Conditions under which it should be reconsidered:
[if X changes, this idea is worth revisiting]
For meeting decisions:
Meeting: [topic]
Date: [date]
Participants: [roles]
Decisions made:
1. [decision] — owner: [name/role]
2. [decision] — owner: [name/role]
Next action items:
- [ ] [task] — [owner] — [deadline]
Step 4: Suggest where to store it
Based on the documentation tools listed in CLAUDE.md, suggest the appropriate destination:
- Feature-level decisions → inside the relevant task in the team's task tracker
- Product-level decisions → the team's wiki or documentation space
- Meeting decisions → the relevant communication channel + task tracker if there are action items
Constraints
- Never make the decision for the PM — only document it
- If the PM does not have a clear reason, flag it: "This decision is risky to document without a stated reason — the reason is what makes it retrievable and defensible later"
- Always include a review date or trigger — no decision is permanent
Context variables (populated from CLAUDE.md)
- Team roles and names
- Decision-making patterns for this product