| name | next-steps |
| description | Generate a stakeholder-aligned next-steps checklist for a multi-stakeholder project from the current conversation and connected context. Use when the user has just had a working session and now needs to align teammates (PM, design, engineering, leadership) on what happens next, who owns it, and what's blocked. Output is grouped by owner, prioritised, and pasteable into Slack/Notion/Linear. |
| user-invocable | true |
| arguments | ["scope-hint"] |
| allowed-tools | ["Read","Write","Bash","Grep","Glob","WebFetch","AskUserQuestion"] |
Next Steps — Stakeholder Alignment Checklist
What it does
Reads the current conversation (and optional connected context: Linear, Slack
thread, Notion doc, git/PR state) and produces one consolidated checklist of
next steps grouped by owner, ranked by priority, with explicit dependencies
and open questions. Designed to be pasted into a Slack thread, a Linear
comment, or a Notion update so everyone sees the same picture.
The point isn't to enumerate every possible task — it's to surface what
unblocks the next move forward, so multiple stakeholders can self-serve.
When to use
- After a working session, before posting a status update.
- When a Slack/Linear thread has multiple unresolved threads — you need to
consolidate.
- When the user says things like "so what are next steps", "align everyone
on next items", "summarise what each person owes".
Do NOT use this for: timesheet recaps (use /workday-summary), retrospective
status posts (use /project-updates), or commit-by-commit breakdowns.
Inputs
Required:
- The current Claude conversation — the primary signal. The model already
has this in context.
Optional (from the scope-hint arg or follow-up questions):
- A Linear ticket ID (e.g.
ENG-1234) — fetch via mcp__linear-server__get_issue to anchor scope and check current state/assignee.
- A PR number (e.g.
#822) — fetch via gh pr view for state, reviewers, blocking checks.
- A Slack thread permalink — read via Slack MCP to extract stakeholder asks.
- A Notion doc URL — read via WebFetch / Notion MCP for narrative context.
If the conversation already contains these references (it usually does), pull
them automatically. Only ask the user when scope is genuinely ambiguous.
Workflow
1. Anchor the scope
Identify, in one sentence, what project / piece of work this is for. Pull it
from the conversation. If multiple candidates exist, ask the user which one.
2. Identify stakeholders
List every named person and role that has appeared in the conversation or in
referenced tickets/threads. Mark each as one of:
- Owner — has work to do
- Decider — owes a call/answer that unblocks others
- FYI — needs to know but has no action
Don't invent stakeholders. Use names actually mentioned.
3. Extract candidate items
Walk the conversation and any fetched docs. For each item, capture:
- Action — concrete, verb-led, ≤ 1 line
- Owner — exactly one person
- Why / context — one short clause; cite source if non-obvious (PR #, Linear ID, "from Vineet's reply")
- Priority —
P0 (blocks demo / today), P1 (this week), P2 (next pass)
- Dependency — blocked-by note if applicable
Apply ranking ruthlessly: an item that unblocks another stakeholder outranks
an item that's purely internal polish.
4. Separate open questions
Anything that's a decision needed — not a task — goes into a separate
Open questions section, attributed to the decider. These are the things
that, once answered, generate concrete tasks. Don't merge them with action items.
5. Render
# Next steps — {project / scope}
## {Owner name or @handle}
- [ ] **P0** — {action}. _{context, source}_
- [ ] **P1** — {action}. _Blocked on: {dep}_
## {Next owner}
- [ ] **P1** — {action}.
## Open questions
- **{Decider}**: {question}. _Why it matters: {one clause}_
## Out of scope (parking lot)
- {item} — revisit when {trigger}
Hard rules:
- Owner-grouped, not priority-grouped. A stakeholder skimming for their own
name should see all their items in one block.
- Cap at 5 items per owner. If more, the user is using this skill wrong —
flag it and ask which to drop.
- Single-line items. Detail belongs in the linked source.
- Never include items already done unless explicitly asked. This is forward-only.
- Always include source citations for non-obvious items (PR #, Linear ID,
"Vineet on Apr 27", "see Notion guide §3").
6. Present and confirm
Show the rendered checklist in chat. Ask:
- Did I miss anyone?
- Did I miss any action you mentioned earlier in the session?
- Anything to bump up/down in priority?
Iterate once, then offer:
- Copy to clipboard (
pbcopy) for Slack/Notion paste
- Post as Linear comment on the anchored ticket (only with explicit user
approval — never auto-post)
- Save to a file (e.g.
~/Desktop/next-steps-{slug}.md) for sharing
Style
- Direct and operational. "Wire up Source Linkage un-merge" — not "explore
options for un-merge functionality".
- Cite the human, not the AI. "@Vineet to call IA placement" not "per
conversation, the IA placement question is open".
- Match the team's existing project-update voice: pragmatic, product-visible
outcomes, no engineering minutiae.
Anti-patterns
- Don't restate the conversation. This is a checklist, not a recap.
- Don't dump every TODO from the codebase. Only items that map to the
current scope and a real stakeholder.
- Don't invent priorities. If the conversation didn't establish urgency,
default to P1 and flag "priority unconfirmed".
- Don't pad sections. Empty sections (no open questions, no parking lot)
should be omitted, not filled with "none".
