What it does:
Reads a forwarded email, Slack message, or vague client request and produces a structured intake summary with problem statement, requestor context, priority signals, and a recommended next step.

When to use:

• You receive a raw message and need to understand what's actually being asked
• You want to triage before committing to scope
• You need a clean summary to share with your team

Command: /triage

Example:

/triage
Here's a message from our client: "We need the reporting dashboard to show 
real-time data. The exec team is presenting to the board next month and the 
current refresh rate is embarrassing."

What it does:
Analyses a project, PRD, or feature request and produces a risk register with likelihood/impact scoring, suggested owners, and early warning signals to watch.

When to use:

• Phase gate reviews
• Before signing off on scope
• Alongside any other skill in the chain

Command: /risk-scan

What it does:
Produces a complete project charter: objectives, scope, success metrics, stakeholders, assumptions, constraints, and a high-level timeline.

When to use:

• Formalising a new project or engagement
• Getting executive sign-off
• Aligning a cross-functional team before discovery

Command: /charter

What it does:
Plans a discovery workshop or structures the output from one. Produces a facilitation guide, session agenda, or clean discovery summary depending on what you provide.

When to use:

• Planning a discovery session with stakeholders
• Synthesising notes from a workshop you've already run
• Moving from problem space to solution space

Command: /discovery

What it does:
Produces a complete PRD: problem statement, goals, non-goals, user stories, functional requirements, edge cases, and open questions.

When to use:

• Documenting requirements for a new feature or product
• Aligning engineering, design, and stakeholders before build
• Creating a source of truth for the sprint

Command: /prd

What it does:
Breaks requirements into epics and user stories following the 3 C's (Card, Conversation, Confirmation) and INVEST criteria. Each story includes a description, design notes, and testable acceptance criteria.

When to use:

• Populating a backlog from a PRD or feature description
• Preparing tickets before sprint planning
• Breaking down a large feature into shippable increments

Command: /stories

What it does:
Analyses sprint data (velocity, completion rate, carry-over, blockers) and produces a structured sprint report with insights and recommendations for the next sprint.

When to use:

• End-of-sprint review prep
• Velocity trend analysis
• Stakeholder reporting

Command: /sprint-report

What it does:
Produces a sprint SOW with sprint goal, in-scope stories, out-of-scope items, dependencies, risks, and definition of done.

When to use:

• Sprint kick-off documentation
• Client-facing sprint agreements
• Aligning stakeholders on what will and won't ship

Command: /sprint-sow

What it does:
Turns a raw meeting transcript or bullet-point notes into structured minutes: attendees, decisions made, action items with owners and due dates, and parking lot items.

When to use:

• Post-meeting documentation
• Capturing decisions before they get lost
• Sharing outcomes with stakeholders who weren't in the room

Command: /meeting-notes

What it does:
Reads a solution architect proposal, architecture doc, or integration spec and produces a PM-ready feasibility summary: delivery risks, dependency flags, and a prioritised list of questions for the tech lead.

When to use:

• Reviewing an SA proposal before committing to delivery
• Translating a technical doc into PM language
• Preparing for a feasibility conversation with engineering

Command: /tech-review

What it does: Takes team availability, a prioritised backlog, and a sprint goal and produces a structured sprint plan: capacity table, P0/P1/P2 backlog breakdown, dependency tracking, risk flags, definition of done, and key dates. Defaults to 70-80% capacity planning and flags overcommitment explicitly.

When to use:

• Planning an upcoming sprint with a defined team and backlog
• Working out realistic capacity after accounting for PTO and meetings
• Aligning stakeholders on what will and won't ship this sprint

Command: /sprint-planning

Example:

/sprint-planning
Sprint 3, 2 weeks. Team: Alice (FE, 8 days), Ben (BE, 7 days - 1 day PTO).
Goal: Ship the client dashboard with live data.
Backlog: PROJ-12 Dashboard UI (3pts), PROJ-13 Data API (5pts), PROJ-14 Export (2pts), PROJ-15 Notifications (3pts - stretch).
Carryover: PROJ-11 Auth bug (2pts, blocked last sprint by infra).

What it does:
Runs a structured readiness assessment across 7 categories - feature completeness, testing, operational readiness, communications, dependencies, approvals, and post-release readiness. Every checklist item is scored PASS / FAIL / RISK / UNCONFIRMED / N/A. Produces a categorised checklist, a blockers list, and one of three verdicts: GO, NO-GO, or CONDITIONAL GO.

When to use:

• Before any planned sprint release
• Before shipping a hotfix or emergency patch
• Coordinating a phased or feature-flagged rollout
• Running a release readiness meeting with engineering and QA
• When a stakeholder asks "are we ready to ship?"

Command: /release-checklist

Example:

/release-checklist
Release: Sprint 22 - Invoicing v2
Type: Planned sprint release
Date: Friday 30 May 2026, 6:00 PM AEST
Tickets: FIN-441, FIN-442, FIN-443, FIN-451, FIN-461, FIN-470
Team: PM Erica J, Tech lead Marcus R, QA lead Priya S, DevOps Tom W
QA sign-off received for FIN-441 and FIN-442. FIN-443 still in testing.
No load testing done. Rollback plan exists but unreviewed.

What it does:
Extracts decisions from any input - a change request, scope revision, or prior skill output - and produces a structured 11-column decision log table covering area, original plan, revised plan, reason, change owner, delivery impact, technical impact, product owner impact, cost impact, change status, and approver.

When to use:

• A timeline, scope, budget, or architecture decision has been made and needs an audit trail
• The PM Orchestrator detects a decision in a skill output and asks whether to log it
• You need a formal change record to share with stakeholders or attach to a charter

Command: /decision-log

Example:

/decision-log
We were planning a 3-month delivery but the client moved the go-live to 6 weeks.
Engineering flagged this as a scope risk. We also dropped the reporting module from MVP.

What it does:
Facilitates a retro (format, agenda, prompts) or turns raw retro notes into a structured summary: what went well, what didn't (as blameless themes), and action items each with a single owner and a date. Reviews whether the last retro's actions actually got done.

When to use:

• End of a sprint or project phase
• Turning a messy retro board into owned next steps
• Carrying improvement actions into the next /sprint-planning

Command: /retrospective

What it does:
Translates delivery detail into a concise update for a specific audience (sponsor, exec, client, or team): RAG status, progress as outcomes, what's next, risks, and any decisions needed. Drafts it as an email, Confluence page, or copy-ready text.

When to use:

• Weekly or milestone stakeholder comms
• Briefing a sponsor or client on progress
• Turning a sprint report into something a non-delivery audience will read

Command: /stakeholder-update

What it does:
Sequences initiatives into themes and time horizons with dependencies and honest confidence levels (near-term firm, later directional). Produces a Now/Next/Later or quarterly view, plus what's explicitly parked and why.

When to use:

• Communicating direction to stakeholders
• Sequencing a backlog into themes after a charter or PRD
• Quarterly or half-year planning

Command: /roadmap

What it does:
Compares spend to date against the charter budget, forecasts cost at completion, and flags overrun early with a RAG verdict, variance drivers, and recommended actions. Built to catch problems while there's still time to act.

When to use:

• Monthly or per-sprint budget check-ins
• Answering "are we on budget?"
• Spotting burn-rate risk before it becomes an overrun

Command: /budget-tracker

What it does:
Synthesises a project's existing artefacts and context into a one-page orientation for a new team member: what the project is, where it stands, who's who, what to read first, decisions already made, live risks, and a role-specific first-week checklist.

When to use:

• A new dev, QA, PM, or designer joins an in-flight project
• Bringing someone up to speed without a series of meetings
• Capturing project knowledge in one place

Command: /onboarding