decision

Name: decision
Author: aleksander-dytko

31stars4forks

How to install decision?

aleksander-dytko/ai-pm-workspace/decision

$npx -y skills add aleksander-dytko/ai-pm-workspace --skill decision

Installs into the current project.

Summary

Make a product decision with full context from the vault and available sources

Files · 1

View on GitHub

SKILL.md

1	# Make a Product Decision
2
3	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.
4
5	## Input
6
7	The user provides a decision topic via `$ARGUMENTS`. Examples:
8	- "should we support feature X in the next release"
9	- "prioritize feature A vs feature B"
10	- "should we adopt GraphQL for the new API"
11
12	## Workflow
13
14	1. Search the vault:
15	- Recent meetings in `Meetings/` that touched this topic
16	- Daily notes in `journals/` (last 2 weeks) for related context
17	- `Loose Notes/Work/` for related decisions or drafts
18	- `Dashboard/Weekly P-Tasks.md` for related priorities
19
20	2. Use GitHub MCP (if configured):
21	- Search repositories for related issues/PRs
22	- Read engineering comments and discussions
23	- Identify any blockers or concerns raised
24
25	3. Ask for additional context (before options):
26	- "Do you have a Slack thread, document, or discussion about this decision? If yes, paste it now."
27	- If provided: extract opinions, concerns, constraints.
28	- If skipped: proceed without.
29
30	4. Present context summary:
31	- Relevant notes and prior discussions
32	- Strategy alignment (if strategy docs exist)
33	- Customer data or validation (if any)
34	- Engineering discussions and feasibility (from GitHub)
35
36	5. Draft options with trade-offs:
37	- 2-3 viable options
38	- For each: pros (benefits, alignment, customer value), cons (costs, risks, complexity, timeline)
39	- Do not recommend yet - present objectively
40
41	6. Create decision note:
42	- Location: `Loose Notes/Work/YYYY-MM-DD - Decision - [Topic].md`
43	- Structure:
44
45	```markdown
46	---
47	tags: LooseNotes
48	date: YYYY-MM-DD
49	---
50	# Decision: [Topic]
51
52	Date: YYYY-MM-DD
53
54	## Context
55	[Why this decision is needed - background from notes, meetings, strategy]
56
57	## Options Considered
58	1. Option 1: [Description]
59	- Pros: ...
60	- Cons: ...
61	2. Option 2: [Description]
62	- Pros: ...
63	- Cons: ...
64
65	## Decision
66	[To be filled after review, or suggest recommendation if clear]
67
68	## Rationale
69	[Why this option, trade-offs accepted]
70
71	## Impact
72	[What changes, who is affected, timeline]
73
74	## Communication
75	[Who needs to be informed, how]
76
77	## Follow-up Tasks
78	- [ ] [Task]
79	```
80
81	7. Link the decision note:
82	- Add a link in today's journal (`journals/YYYY/MM-Month/DD-MM-YYYY.md`) under `## Notes`.
83
84	8. Draft a communication:
85	- A ready-to-post message announcing the decision.
86	- Keep it concise (under 200 words).
87	- Format: Context → Decision → Impact → Next steps.
88	- Channel-neutral by default; if the user names a channel (Slack/email), adapt to that channel's style (see `/communicate`).
89
90	9. Propose follow-up tasks (confirm before writing):
91	- Identify tasks needed to implement and communicate the decision.
92	- Show the proposed list and wait for confirmation.
93	- After confirmation, append each task to `Dashboard/tasks.md` under "This week" with format:
94
95	```
96	- [ ] Task - source: [[YYYY-MM-DD - Decision - Topic]] - due: YYYY-MM-DD - priority: P2
97	```
98
99	## Output Format
100
101	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).
102
103	Cover these beats in 3-4 sentences of prose:
104	- Where the decision note was written (backtick path to the new file in `Loose Notes/Work/`).
105	- Whether it was linked in today's journal (or "skipped - no journal for today").
106	- How much context was pulled in (rough count: N related notes, N GitHub issues/PRs).
107	- Your recommendation in one line - or "awaiting your input" if the decision genuinely could go either way.
108
109	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.
110
111	Example tone:
112
113	> 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.
114	>
115	> Draft Slack message to #billing-team:
116	> ```
117	> [message body]
118	> ```
119	>
120	> Proposed follow-up tasks for `Dashboard/tasks.md`:
121	> 1. Write spec for top-5 complaint fixes - P2, due 2026-04-28
122	> 2. Book Q3 roadmap review for the portal scope - P3
123	>
124	> Add these? (Y / N / pick numbers)
125
126	## Notes
127
128	- Always cite sources (meeting notes, GitHub issues).
129	- If options are equal/unclear, present objectively and ask for user preference.
130	- Leave the "Decision" section empty if not immediately clear.
131	- If the decision is urgent, propose tasks with P2 priority.

People who liked this also viewed

6 picks

Type

decision

31stars4forks

View on GitHub

How to install decision?

aleksander-dytko/ai-pm-workspace/decision

$npx -y skills add aleksander-dytko/ai-pm-workspace --skill decision

Installs into the current project.

Summary

Make a product decision with full context from the vault and available sources

Files · 1

View on GitHub

SKILL.md

1	# Make a Product Decision
2
3	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.
4
5	## Input
6
7	The user provides a decision topic via `$ARGUMENTS`. Examples:
8	- "should we support feature X in the next release"
9	- "prioritize feature A vs feature B"
10	- "should we adopt GraphQL for the new API"
11
12	## Workflow
13
14	1. Search the vault:
15	- Recent meetings in `Meetings/` that touched this topic
16	- Daily notes in `journals/` (last 2 weeks) for related context
17	- `Loose Notes/Work/` for related decisions or drafts
18	- `Dashboard/Weekly P-Tasks.md` for related priorities
19
20	2. Use GitHub MCP (if configured):
21	- Search repositories for related issues/PRs
22	- Read engineering comments and discussions
23	- Identify any blockers or concerns raised
24
25	3. Ask for additional context (before options):
26	- "Do you have a Slack thread, document, or discussion about this decision? If yes, paste it now."
27	- If provided: extract opinions, concerns, constraints.
28	- If skipped: proceed without.
29
30	4. Present context summary:
31	- Relevant notes and prior discussions
32	- Strategy alignment (if strategy docs exist)
33	- Customer data or validation (if any)
34	- Engineering discussions and feasibility (from GitHub)
35
36	5. Draft options with trade-offs:
37	- 2-3 viable options
38	- For each: pros (benefits, alignment, customer value), cons (costs, risks, complexity, timeline)
39	- Do not recommend yet - present objectively
40
41	6. Create decision note:
42	- Location: `Loose Notes/Work/YYYY-MM-DD - Decision - [Topic].md`
43	- Structure:
44
45	```markdown
46	---
47	tags: LooseNotes
48	date: YYYY-MM-DD
49	---
50	# Decision: [Topic]
51
52	Date: YYYY-MM-DD
53
54	## Context
55	[Why this decision is needed - background from notes, meetings, strategy]
56
57	## Options Considered
58	1. Option 1: [Description]
59	- Pros: ...
60	- Cons: ...
61	2. Option 2: [Description]
62	- Pros: ...
63	- Cons: ...
64
65	## Decision
66	[To be filled after review, or suggest recommendation if clear]
67
68	## Rationale
69	[Why this option, trade-offs accepted]
70
71	## Impact
72	[What changes, who is affected, timeline]
73
74	## Communication
75	[Who needs to be informed, how]
76
77	## Follow-up Tasks
78	- [ ] [Task]
79	```
80
81	7. Link the decision note:
82	- Add a link in today's journal (`journals/YYYY/MM-Month/DD-MM-YYYY.md`) under `## Notes`.
83
84	8. Draft a communication:
85	- A ready-to-post message announcing the decision.
86	- Keep it concise (under 200 words).
87	- Format: Context → Decision → Impact → Next steps.
88	- Channel-neutral by default; if the user names a channel (Slack/email), adapt to that channel's style (see `/communicate`).
89
90	9. Propose follow-up tasks (confirm before writing):
91	- Identify tasks needed to implement and communicate the decision.
92	- Show the proposed list and wait for confirmation.
93	- After confirmation, append each task to `Dashboard/tasks.md` under "This week" with format:
94
95	```
96	- [ ] Task - source: [[YYYY-MM-DD - Decision - Topic]] - due: YYYY-MM-DD - priority: P2
97	```
98
99	## Output Format
100
101	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).
102
103	Cover these beats in 3-4 sentences of prose:
104	- Where the decision note was written (backtick path to the new file in `Loose Notes/Work/`).
105	- Whether it was linked in today's journal (or "skipped - no journal for today").
106	- How much context was pulled in (rough count: N related notes, N GitHub issues/PRs).
107	- Your recommendation in one line - or "awaiting your input" if the decision genuinely could go either way.
108
109	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.
110
111	Example tone:
112
113	> 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.
114	>
115	> Draft Slack message to #billing-team:
116	> ```
117	> [message body]
118	> ```
119	>
120	> Proposed follow-up tasks for `Dashboard/tasks.md`:
121	> 1. Write spec for top-5 complaint fixes - P2, due 2026-04-28
122	> 2. Book Q3 roadmap review for the portal scope - P3
123	>
124	> Add these? (Y / N / pick numbers)
125
126	## Notes
127
128	- Always cite sources (meeting notes, GitHub issues).
129	- If options are equal/unclear, present objectively and ask for user preference.
130	- Leave the "Decision" section empty if not immediately clear.
131	- If the decision is urgent, propose tasks with P2 priority.

People who liked this also viewed

6 picks

Type