project-management

Plugin project-management from marketplace metapowers in bromso/metapowers. Commands read from the repo's manifest — 18 days ago.

Skills (32)

• backlog-creation

  Create the initial product backlog from the charter and roadmap — epics, user stories, MoSCoW or WSJF priority, an MVP cut and labels. Use when the user has scope or a roadmap and needs a first prioritized backlog to plan sprints from. Not for detailed acceptance criteria, or implementing one featur

• blocker-resolution

  Analyze current blockers with root cause, two to three resolution options, escalation paths, sprint goal impact, owners and deadlines. Use when work is stuck on something the team cannot clear itself and the user wants options and who to escalate to. Not for mapping dependencies before work starts;

• capacity-planning

  Plan capacity over the next 3-6 sprints from availability, holidays, leave and focus factor, with risks and suggested commitments. Use when leave, holidays or team changes are coming and the user asks how many people-days the coming sprints have. Not for past velocity or choosing this sprint's stori

• decision-log

  Document a project decision — question, constraints, alternatives with pros, cons and reversibility, the choice and rationale, and when to revisit. Use when the team has made or is making a project, technical or process call and wants a record of why. Not for a legal call and its accepted risk, or c

• definition-of-done

  Establish a Definition of Done at story, sprint and release level, with quality criteria for testing, performance, accessibility and security calibrated to team maturity. Use when the team disagrees about when work is finished or wants a shared done checklist before sprints start.

• demo-prep

  Create a demo script — audience framing, narrative flow, talking points per feature, likely questions with answers, timing and a fallback if the live demo fails. Use when the user has a demo coming up and wants to rehearse what to show and say. Not for assessing what the sprint delivered; see /proje

• dependency-map

  Identify story-to-story, cross-team and external dependencies in a dependency matrix with the critical path and a recommended start order. Use when stories rely on each other, other teams or vendors and the user wants to know what to start first. Not for a blocker that is already stopping work; see

• estimation

  Estimate a backlog with story points, T-shirt sizes or planning poker against reference stories, flag stories to split and project how many sprints the work will take. Use when the user has stories that need sizing or asks how long the backlog will take to deliver. Not for this sprint's capacity or

• meeting-facilitator

  Plan any meeting — purpose, format, time-boxed agenda, roles, attendees, outcomes and pre-reads. Use when the user has a meeting to run, like a decision meeting, working session or kickoff, and wants an agenda that ends in decisions. Not for a 1:1 or sprint ceremonies; see /leadership:one-on-one, /p

• post-mortem

  Conduct a blameless post-mortem of an incident or project event — timeline, 5 Whys root cause, contributing factors and corrective actions with owners. Use when something went wrong on a project, like a missed launch or outage, and the user wants to know why. Not for a security incident or a sprint

• process-improvement

  Analyze process bottlenecks across sprints — recurring retro themes, flow bottlenecks, a value stream map with flow efficiency — into a prioritized improvement backlog. Use when the same problems keep coming up sprint after sprint and the user wants to find the constraint and decide what to change.

• product-vision

  Craft a product vision statement, 3-5 measurable product goals, a North Star metric and success criteria at 30, 60 and 90 days. Use when the user needs to say what the product is for and how they will know it is working before building a roadmap. Not for a team's purpose and values; see /leadership:

• project-charter

  Define a project charter — purpose, vision, SMART objectives, in- and out-of-scope items, constraints, milestones and initial risks. Use when a project is starting and the user needs its purpose, scope boundaries and milestones agreed before planning the work. Not for breaking one feature into codin

• release-notes

  Draft user-facing release notes — new features, improvements, bug fixes, breaking changes with migration steps and known issues — under a version and date. Use when a release or sprint has shipped and the user needs to tell users what changed. Not for merging the branch or opening the pull request;

• retrospective

  Facilitate a sprint retrospective — pick a format, review last sprint's actions, gather items, group themes, dot-vote and commit to 1-3 owned action items. Use when a sprint has ended and the team is holding its retro ceremony. Not for an incident review or a leader's team-development reflection; se

• risk-assessment

  Identify delivery risks — technical, people, schedule, scope, external — and score and mitigate them in a risk register with a likelihood-impact matrix and owners. Use when the user worries about what could derail the project's timeline or scope and wants the risks tracked. Not for legal exposure or

• roadmap

  Build a release roadmap — time horizon, themes and epics, dated milestones, dependencies, critical path and confidence levels. Use when the user is asked what will ship when over the next 3 to 12 months or needs release milestones to share. Not for breaking one feature into coding tasks; see /develo

• sprint-goal

  Define or refine one sprint goal — an outcome-based statement, 3-5 success criteria, committed versus stretch work and a rallying phrase. Use when the sprint's work is roughly chosen but the goal is vague or reads like a task list. Not for selecting the stories; see /project-management:sprint-planni

• sprint-metrics

  Calculate one sprint's metrics — velocity committed versus done, burndown pattern, cycle time, commitment ratio and outlier stories. Use when a sprint has just ended and the user wants its numbers and what they say about the team. Not for multi-sprint forecasts or a stakeholder update; see /project-

• sprint-planning

  Plan a sprint end to end — capacity, velocity target, stories pulled from the backlog, sprint goal, task breakdown and risks. Use when a new sprint is about to start and the user needs to decide what the team will commit to. Not for only the goal, or capacity over several sprints; see /project-manag

• sprint-review

  Prepare a sprint review — completed and unfinished stories, whether the sprint goal was met, commitment ratio, a demo agenda, stakeholder questions and backlog feedback. Use when a sprint is ending and the user is preparing the review meeting where stakeholders see what got done. Not for a full demo

• stakeholder-map

  Map a project's stakeholders on a power and interest grid with a communication plan per group, RACI for key decisions and escalation paths. Use when the user needs to work out who to keep informed, who approves what and how often to talk to each group. Not for writing a specific update; see /project

• stakeholder-update

  Generate an end-of-sprint stakeholder update — RAG status, progress, risks, decisions needed and milestones. Use when a sprint has finished and the user needs a written update for stakeholders on how it went. Not for the review meeting, sprint numbers or a leadership report; see /project-management:

• standup

  Facilitate a daily standup — each person's yesterday, today and blockers, cross-team patterns, burndown status and sprint goal risk. Use when the team is doing its daily check-in and the user wants the updates captured and the sprint's pace checked. Not for working a stuck blocker through to resolut

• status-report

  Generate a project status report for leadership in RAG format — progress against milestones, top risks and issues, timeline confidence, asks and capacity. Use when leadership or a steering group wants to know where the project stands and what it needs from them. Not for a sprint-by-sprint update to

• story-mapping

  Create a user story map — activities along the user journey, tasks beneath them, stories ranked under each task, release lines and the MVP slice. Use when the user wants the backlog laid out along the user's journey to decide release slices or find gaps. Not for building the backlog itself; see /pro

• team-health

  Assess a delivery team's health on eight dimensions, from mission clarity and pace to collaboration and delivery confidence, with ratings, trend and interventions. Use when the user senses morale, pace or collaboration slipping on a delivery team and wants a structured check. Not for assessing your

• team-setup

  Define a delivery team's Scrum roles, skills matrix and gaps, working agreements and Definition of Ready. Use when a new project team is forming and the user needs to settle who plays which role and what skills are missing. Not for the ceremony schedule and tool stack, or decision rights in a team y

• user-stories

  Write user stories in As a / I want / So that form with Given/When/Then acceptance criteria, checked against INVEST and split when too large. Use when the user needs stories written or rewritten with testable acceptance criteria, or stories are too big or vague to estimate. Not for planning how to c

• velocity-analysis

  Analyze velocity over the last 5-10 sprints — average, variability, trend and causes — and forecast a delivery range for the next three. Use when the user has several sprints of history and asks how fast or how predictably the team delivers. Not for one sprint's results or choosing this sprint's sto

• ways-of-working

  Define how a delivery team works — sprint cadence, ceremonies, channels and norms, tools, escalation paths and rituals. Use when a team is starting a project and wants agreed meeting times, channels and tools before the first sprint. Not for roles and skills, or a leader's 1:1 and review rhythm; see

• wip-review

  Review the sprint board mid-sprint — items by status, WIP limits per person, bottlenecks, idle capacity and progress against burndown — and recommend adjustments. Use when work seems stuck in progress or review and the user wants to know if the sprint is on track and how to recover. Not for each per

Hooks (1)

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}"/hooks/phase-gate.sh

Similar plugins