From role-pgm
Plan a new project end-to-end — success criteria, deliverables, task breakdown (2-8h tasks), dependencies, schedule with contingency buffer, risks, and monitoring cadence. Drafts only. Use at project kickoff or when a fuzzy initiative needs structure.
npx claudepluginhub sitloboi2012/team-marketplace --plugin role-pgmThis skill uses the workspace's default tool permissions.
**Invocation: user only.**
Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Share bugs, ideas, or general feedback.
Invocation: user only.
Turns "we should build X" into a plan someone can execute on. Different from /team-core:task-breakdown (which assumes a spec exists) and from /role-pgm:sprint-planner (which plans one iteration). This plans the whole project arc.
Run them in order, not in parallel. Each one depends on decisions from the previous.
Before any task, get agreement on:
If any of these are fuzzy, stop and ask the user. A plan built on fuzzy success criteria plans the wrong work.
What are the major outputs? Not tasks yet — outputs.
Typical project deliverables:
Each deliverable should be nameable and should align with a success criterion.
For each deliverable, break into tasks that:
Use the same rigor as /team-core:task-breakdown for each deliverable — vertical slicing, foundations first, verification every 2-3 tasks.
For each task, identify:
Produce a dependency list. For projects <30 tasks a list is enough; for bigger ones, sketch a diagram in the output.
Identify the critical path — the longest chain of hard-dependencies. Anything on the critical path slips the project; anything off it is a scheduling convenience.
For each task, estimate effort in hours (for tasks) or days (for deliverables).
Then apply a contingency buffer:
Buffer the schedule, not individual tasks. Applying per-task buffer hides slack; a project-level buffer absorbs the normal cross-task variance.
If the user has historical data (velocity from prior projects), prefer that over abstract estimates. Ask for it.
For each task, clarify:
Flag tasks with no owner — those will slip silently.
Propose a monitoring rhythm:
/role-pgm:status-report draft to stakeholders# Project plan: <name>
**Owner (overall):** <person>
**Target completion:** <date>
**Status:** Draft — pending review
## Outcome
<one sentence, measurable>
## Success criteria
- [ ] <specific + observable>
- [ ] ...
## Non-goals
- <explicit exclusion>
- ...
## Constraints
- <deadline, budget, headcount, tech, compliance, reuse>
## Deliverables
### D1: <name>
**What:** <1 line>
**Success:** <which criterion this satisfies>
**Tasks:** <count, total effort>
### D2: ...
## Task breakdown
### D1 tasks
**T1.1: <task>**
- Owner: <person>
- Effort: <hours>
- Depends on: <none | T0.3>
- Completion: <how we know it's done>
**T1.2: <task>**
...
(Repeat per deliverable)
## Dependency map
<critical-path tasks listed. If >30 tasks, ASCII diagram or link to visual.>
## Schedule
- **Total effort:** <hours>
- **Buffer:** <%> → <total with buffer>
- **Sequenced duration:** <weeks, accounting for critical path and parallelism>
- **Target completion:** <date>
- **Key checkpoints:** <dates with what's verified at each>
## Risks
| Risk | Severity | Likelihood | Mitigation |
| --- | --- | --- | --- |
| <risk> | <L/M/H/C> | <P/L/NC> | <plan> |
## Monitoring
- Daily: <format, channel>
- Weekly: <status report to whom, via what>
- At checkpoint: <what's verified>
## Open questions before we start
- [ ] <question, owner, needed by>
Show the draft. Common edits:
On approval: publish to Notion under projects path, optionally post kickoff announcement to Slack via /team-core:draft-email flow, optionally open risk log entries via /role-pgm:risk-log add.
/role-pgm:sprint-planner. This is the macro arc; sprints implement it.Methodology inspired by the shubhamsaboo "project-planner" skill.