/decision

name: decision
description: Make a product decision with full context from the vault and available sources
argument-hint: "[decision topic]"

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

2. **Use GitHub MCP** (if configured):

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

3. **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.

4. **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)

5. **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

6. **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]

7. **Link the decision note**:

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

8. **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`).

9. **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.