Make a Product Decision

You help make a well-informed product decision by gathering context from all available sources and producing structured documentation, follow-up tasks, and a communication draft.

Input

The user provides a decision topic via $ARGUMENTS. Examples:

• "should we support feature X in the next release"
• "prioritize feature A vs feature B"
• "should we adopt GraphQL for the new API"

Workflow

1. Search the vault:

• Recent meetings in Meetings/ that touched this topic
• Daily notes in journals/ (last 2 weeks) for related context
• Loose Notes/Work/ for related decisions or drafts
• Dashboard/Weekly P-Tasks.md for related priorities

1. Use GitHub MCP (if configured):

• Search repositories for related issues/PRs
• Read engineering comments and discussions
• Identify any blockers or concerns raised

1. Ask for additional context (before options):

• "Do you have a Slack thread, document, or discussion about this decision? If yes, paste it now."
• If provided: extract opinions, concerns, constraints.
• If skipped: proceed without.

1. Present context summary:

• Relevant notes and prior discussions
• Strategy alignment (if strategy docs exist)
• Customer data or validation (if any)
• Engineering discussions and feasibility (from GitHub)

1. Draft options with trade-offs:

• 2-3 viable options
• For each: pros (benefits, alignment, customer value), cons (costs, risks, complexity, timeline)
• Do not recommend yet - present objectively

1. Create decision note:

• Location: Loose Notes/Work/YYYY-MM-DD - Decision - [Topic].md
• Structure:

---
tags: LooseNotes
date: YYYY-MM-DD
---
# Decision: [Topic]

**Date**: YYYY-MM-DD

## Context
[Why this decision is needed - background from notes, meetings, strategy]

## Options Considered
1. **Option 1**: [Description]
   - Pros: ...
   - Cons: ...
2. **Option 2**: [Description]
   - Pros: ...
   - Cons: ...

## Decision
[To be filled after review, or suggest recommendation if clear]

## Rationale
[Why this option, trade-offs accepted]

## Impact
[What changes, who is affected, timeline]

## Communication
[Who needs to be informed, how]

## Follow-up Tasks
- [ ] [Task]

1. Link the decision note:

• Add a link in today's journal (journals/YYYY/MM-Month/DD-MM-YYYY.md) under ## Notes.

1. Draft a communication:

• A ready-to-post message announcing the decision.
• Keep it concise (under 200 words).
• Format: Context → Decision → Impact → Next steps.
• Channel-neutral by default; if the user names a channel (Slack/email), adapt to that channel's style (see /communicate).

1. Propose follow-up tasks (confirm before writing):

• Identify tasks needed to implement and communicate the decision.
• Show the proposed list and wait for confirmation.
• After confirmation, append each task to Dashboard/tasks.md under "This week" with format:

- [ ] Task - source: [[YYYY-MM-DD - Decision - Topic]] - due: YYYY-MM-DD - priority: P2

Output Format

Report results in conversational prose, not a fenced template card. Use backtick-wrapped paths for any file references in chat (wikilinks stay inside the decision note itself, not chat output).

Cover these beats in 3-4 sentences of prose:

• Where the decision note was written (backtick path to the new file in Loose Notes/Work/).
• Whether it was linked in today's journal (or "skipped - no journal for today").
• How much context was pulled in (rough count: N related notes, N GitHub issues/PRs).
• Your recommendation in one line - or "awaiting your input" if the decision genuinely could go either way.

Then show the communication draft (this one stays fenced - it's copy-paste content) and the proposed follow-up tasks as a numbered list so the user can approve with y / n / picking numbers.

Example tone:

Decision note written to Loose Notes/Work/2026-04-21 - Decision - Invoice portal scope.md, linked in today's journal. Pulled context from 3 related meeting notes and 2 GitHub issues. My read: ship the top-5 fixes first, defer the full portal to Q3 - self-service has clearer 30-day ROI than a full portal buildout.

>

Draft Slack message to #billing-team: `` [message body] ``

>

Proposed follow-up tasks for Dashboard/tasks.md: 1. Write spec for top-5 complaint fixes - P2, due 2026-04-28 2. Book Q3 roadmap review for the portal scope - P3

>

Add these? (Y / N / pick numbers)

Notes

• Always cite sources (meeting notes, GitHub issues).
• If options are equal/unclear, present objectively and ask for user preference.
• Leave the "Decision" section empty if not immediately clear.
• If the decision is urgent, propose tasks with P2 priority.