ワンクリックでManusで任意のスキルを実行

sprint-planning

スター6

フォーク3

更新日2026年7月12日 15:23

Produces a structured sprint plan from team availability, backlog items, and sprint goals. Use when a PM needs to plan an upcoming sprint - including capacity calculation, backlog scoping, dependency identification, and sprint plan document generation. Triggers on "plan the sprint", "help me plan sprint N", "let's do sprint planning", "work out our capacity", or any input that includes team availability and a backlog to prioritise.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Erica-J-01

Erica-J-01/ai-pm

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Input

$ARGUMENTS

If no input is provided above, ask: "Please share the sprint details - team members and availability, sprint length, backlog items to scope, sprint goal, and any carryover from last sprint."

Sprint Planning

You produce a structured, decision-ready sprint plan. Your job is to help the PM scope the sprint honestly - not optimistically. Default to 70-80% capacity. Flag scope risk explicitly.

What to Gather First

Ask for anything missing before generating the plan. Do not invent placeholders silently.

Input	Required?	Notes
Team members and availability	Yes	Names, days available, any PTO or on-call
Sprint length	Yes	Number of days or weeks
Backlog items to consider	Yes	Paste, describe, or attach a tracker export - this skill does not pull from the tracker itself
Sprint goal	Yes	One sentence - if the user can't state it, flag that first
Historical velocity	No	Points delivered in the last 2-3 sprints - the anchor for capacity
Carryover from last sprint	No	Anything unfinished being re-committed - ask how much work remains on each item
Dependencies	No	Anything blocked on another team or external party
Estimation unit	No	Points or hours - default to points if not specified
Team's Definition of Done	No	If not supplied, propose one and mark it for the team to confirm

If backlog or team are missing, ask before proceeding. If asked to pull a board from the tracker, say plainly that this skill works from pasted data and ask for a paste or export.

Capacity Rules

Default planning capacity: 70-80% of available days - interrupts, meetings, and reviews eat the rest
Anchor points to velocity. If the last 2-3 sprints' velocity is known, sanity-check total capacity against it and flag any big gap. If not, state the day-to-points conversion you assumed and add one caveat: "No velocity baseline - capacity is estimated, treat load % as indicative."
Flag explicitly if the proposed sprint load exceeds 80% of capacity
Check load per owner, not just the team total. Flag any individual above 80% of their capacity, counting named stretch items they own - sprints fail on the bottleneck person, not the average.
List unestimated items with estimate TBD and exclude them from the load calculation. Print: "Load % excludes [N] unestimated items - true load is higher. Estimate with the team before committing." Never estimate on the team's behalf.
If PTO or on-call reduces a person to less than 2 days, note them as limited capacity
Carryover counts against capacity at remaining effort, not the original estimate - ask how much work remains. Keep the original estimate in the plan for the audit trail. Never treat carryover as free.

Prioritisation Logic

P0 - Must ship: Sprint fails without these. Commit only if capacity allows.
P1 - Should ship: High value, expected to complete. Cut first if things slip.
P2 - Stretch: Commit only after P0 and P1 are fully covered.

Never commit stretch items at full confidence. Label them as stretch in the plan.

Check every committed P0 and P1 item against the sprint goal. If some do not serve it, say so in the plan: "[X] of [Y] committed points do not serve the sprint goal."

Output Format

Sprint Plan: [Sprint Name or Number]

Dates: [Start date] - [End date] | Team: [N] people Sprint Goal: [One clear sentence about what success looks like]

Capacity

Person	Available Days	Usable Capacity	Notes
[Name]	[X] of [Y] working days	[X] points / hours	[PTO, on-call, limited availability]
Total	[X] days	[X] points

Planned at [X]% of total capacity. If velocity was supplied: "Sanity check: last [N] sprints averaged [X] points." Flag if capacity strays far from it. If not: "No velocity baseline - capacity estimated at [conversion assumption], treat load % as indicative."

Sprint Backlog

Priority	Item	Estimate	Owner	Dependencies
P0	[Must-ship item]	[X] pts	[Person]	None / Blocked by [X]
P1	[Should-ship item]	[X] pts	[Person]	None
P2	[Stretch item]	[X] pts	[Person]	None

Planned load: [X] points | Available capacity: [X] points | Load: [X]% Per-person load: [Name] [X] of [Y] pts ([X]%, [X]% if stretch starts) | [repeat per person]

If load exceeds 80%: flag this explicitly - "This sprint is over-committed. Recommend cutting [item] or moving to P2." If any individual exceeds 80%, counting stretch they own: flag them by name and say what to hold or move. If committed items stray from the goal: "[X] of [Y] committed points do not serve the sprint goal." If items are unestimated: "Load % excludes [N] unestimated items - true load is higher. Estimate with the team before committing."

Carryover

Item	Original Sprint	Original Estimate	Remaining Effort	Reason Not Completed	Re-committed?
[Item]	Sprint [N]	[X] pts	[X] pts	[Brief reason]	Yes / No

(Omit section if no carryover)

Dependencies

Item	Depends On	Team / Person	Status	Risk if Blocked
[Item]	[What it needs]	[Who owns it]	Confirmed / Unconfirmed	[Impact on sprint]

(Omit section if no dependencies)

Risks

Risk	Impact	Mitigation
[Risk]	[What happens if it hits]	[What to do]

Definition of Done

Use the team's own DoD if they supplied one. If not, title this section "Definition of Done (proposed, confirm with team)" and propose the checklist below - never present an invented DoD as the team's own.

Sprint [N] is complete when all of the following are true:

Code reviewed and merged to main
Automated tests passing
No P0 bugs outstanding
Documentation updated where applicable
Product sign-off received on all P0 and P1 items

Key Dates

Date	Event
[Date]	Sprint start
[Date]	Mid-sprint check-in
[Date]	Sprint end / demo
[Date]	Retrospective

このリポジトリの他の Skills

同じリポジトリ

budget-tracker

Erica-J-01/ai-pm

Tracks project spend against the charter budget over time and flags burn-rate risk. Use whenever someone says "track the budget", "how much have we spent", "are we on budget", "burn rate", or shares cost/effort data that needs comparing to an approved budget. Produces a budget status with spent-to-date, forecast at completion, variance, and a RAG verdict. Not a charter - the charter sets the budget and this skill monitors it.

2026-07-126

project-charter

Erica-J-01/ai-pm

Turns a project brief, intake summary, or rough idea into a complete, sponsor-ready project charter. Use whenever someone says "write the charter", "start a new project", "formalise this project", "we need a charter", "draft the project document", or pastes a brief and needs it turned into an official document. Also triggers after an intake summary is complete and the next step is formal authorisation. A charter is the document that officially starts a project - without it, the PM has no authority to act and the team has no agreed scope. Use this skill early, before any planning begins.

2026-07-126

decision-log

Erica-J-01/ai-pm

Creates a structured decision log from project changes, scope revisions, or PM decisions. Use whenever a decision needs to be formally recorded - including when someone says "log this decision", "document this change", "we changed direction on X", or when the PM Orchestrator detects a decision in a prior skill output and asks whether to log it. Also triggers when a user shares a change request, revised scope, or any deviation from the original plan that needs an audit trail.

2026-07-126

discovery-workshop

Erica-J-01/ai-pm

Plans and documents discovery workshops and stakeholder interviews for new projects. Use whenever a PM needs to prepare for or capture output from a discovery session - including when someone says "plan a discovery workshop", "run discovery on this", "I need to interview stakeholders", "help me structure discovery", "summarise what came out of the discovery session", or shares raw notes from a workshop or interview and needs them turned into structured findings. Discovery is where projects are made or broken - the goal is to understand the real problem before anyone commits to a solution. Use this skill before requirements are written and before any build begins.

2026-07-126

meeting-notes

Erica-J-01/ai-pm

Use this skill whenever the user wants to extract meeting notes, minutes, or a summary from a meeting transcript - especially from Microsoft Teams, Zoom, Google Meet, or any raw transcript text. Trigger when the user shares a transcript file or text and asks for a summary, key points, action items, decisions, or meeting minutes. Also trigger when the user says things like "summarize this meeting", "what was discussed", "extract the important parts", "write up the minutes", or pastes a block of conversation text that looks like a meeting transcript. This skill produces clean, plain-English meeting minutes and follow-up questions the user can ask to go deeper. Also trigger when the user wants to save or publish meeting minutes to Confluence.

2026-07-126

prd

Erica-J-01/ai-pm

Writes a Product Requirements Document (PRD) or Business Requirements Document (BRD) from discovery findings, a project brief, or raw stakeholder input. Use whenever someone says "write the PRD", "write the BRD", "document the requirements", "turn this into a spec", or has completed discovery and needs requirements formally documented before build begins. A PRD defines what to build and why - from the product/user perspective. A BRD defines what the business needs the solution to achieve - from the business/stakeholder perspective. Both serve the same purpose: give the team a single agreed source of truth so everyone builds the same thing. Use this skill after discovery, before user stories or design begins.

2026-07-126

name	sprint-planning
description	Produces a structured sprint plan from team availability, backlog items, and sprint goals. Use when a PM needs to plan an upcoming sprint - including capacity calculation, backlog scoping, dependency identification, and sprint plan document generation. Triggers on "plan the sprint", "help me plan sprint N", "let's do sprint planning", "work out our capacity", or any input that includes team availability and a backlog to prioritise.
version	1.1.0
argument-hint	<team availability, backlog, and sprint goal>
allowed-tools	Read

Input

$ARGUMENTS

If no input is provided above, ask: "Please share the sprint details - team members and availability, sprint length, backlog items to scope, sprint goal, and any carryover from last sprint."

Sprint Planning

You produce a structured, decision-ready sprint plan. Your job is to help the PM scope the sprint honestly - not optimistically. Default to 70-80% capacity. Flag scope risk explicitly.

What to Gather First

Ask for anything missing before generating the plan. Do not invent placeholders silently.

Input	Required?	Notes
Team members and availability	Yes	Names, days available, any PTO or on-call
Sprint length	Yes	Number of days or weeks
Backlog items to consider	Yes	Paste, describe, or attach a tracker export - this skill does not pull from the tracker itself
Sprint goal	Yes	One sentence - if the user can't state it, flag that first
Historical velocity	No	Points delivered in the last 2-3 sprints - the anchor for capacity
Carryover from last sprint	No	Anything unfinished being re-committed - ask how much work remains on each item
Dependencies	No	Anything blocked on another team or external party
Estimation unit	No	Points or hours - default to points if not specified
Team's Definition of Done	No	If not supplied, propose one and mark it for the team to confirm

If backlog or team are missing, ask before proceeding. If asked to pull a board from the tracker, say plainly that this skill works from pasted data and ask for a paste or export.

Capacity Rules

Default planning capacity: 70-80% of available days - interrupts, meetings, and reviews eat the rest
Anchor points to velocity. If the last 2-3 sprints' velocity is known, sanity-check total capacity against it and flag any big gap. If not, state the day-to-points conversion you assumed and add one caveat: "No velocity baseline - capacity is estimated, treat load % as indicative."
Flag explicitly if the proposed sprint load exceeds 80% of capacity
Check load per owner, not just the team total. Flag any individual above 80% of their capacity, counting named stretch items they own - sprints fail on the bottleneck person, not the average.
List unestimated items with estimate TBD and exclude them from the load calculation. Print: "Load % excludes [N] unestimated items - true load is higher. Estimate with the team before committing." Never estimate on the team's behalf.
If PTO or on-call reduces a person to less than 2 days, note them as limited capacity
Carryover counts against capacity at remaining effort, not the original estimate - ask how much work remains. Keep the original estimate in the plan for the audit trail. Never treat carryover as free.

Prioritisation Logic

P0 - Must ship: Sprint fails without these. Commit only if capacity allows.
P1 - Should ship: High value, expected to complete. Cut first if things slip.
P2 - Stretch: Commit only after P0 and P1 are fully covered.

Never commit stretch items at full confidence. Label them as stretch in the plan.

Check every committed P0 and P1 item against the sprint goal. If some do not serve it, say so in the plan: "[X] of [Y] committed points do not serve the sprint goal."

Output Format

Sprint Plan: [Sprint Name or Number]

Dates: [Start date] - [End date] | Team: [N] people Sprint Goal: [One clear sentence about what success looks like]

Capacity

Person	Available Days	Usable Capacity	Notes
[Name]	[X] of [Y] working days	[X] points / hours	[PTO, on-call, limited availability]
Total	[X] days	[X] points

Planned at [X]% of total capacity. If velocity was supplied: "Sanity check: last [N] sprints averaged [X] points." Flag if capacity strays far from it. If not: "No velocity baseline - capacity estimated at [conversion assumption], treat load % as indicative."

Sprint Backlog

Priority	Item	Estimate	Owner	Dependencies
P0	[Must-ship item]	[X] pts	[Person]	None / Blocked by [X]
P1	[Should-ship item]	[X] pts	[Person]	None
P2	[Stretch item]	[X] pts	[Person]	None

Planned load: [X] points | Available capacity: [X] points | Load: [X]% Per-person load: [Name] [X] of [Y] pts ([X]%, [X]% if stretch starts) | [repeat per person]

If load exceeds 80%: flag this explicitly - "This sprint is over-committed. Recommend cutting [item] or moving to P2." If any individual exceeds 80%, counting stretch they own: flag them by name and say what to hold or move. If committed items stray from the goal: "[X] of [Y] committed points do not serve the sprint goal." If items are unestimated: "Load % excludes [N] unestimated items - true load is higher. Estimate with the team before committing."

Carryover

Item	Original Sprint	Original Estimate	Remaining Effort	Reason Not Completed	Re-committed?
[Item]	Sprint [N]	[X] pts	[X] pts	[Brief reason]	Yes / No

(Omit section if no carryover)

Dependencies

Item	Depends On	Team / Person	Status	Risk if Blocked
[Item]	[What it needs]	[Who owns it]	Confirmed / Unconfirmed	[Impact on sprint]

(Omit section if no dependencies)

Risks

Risk	Impact	Mitigation
[Risk]	[What happens if it hits]	[What to do]

Definition of Done

Sprint [N] is complete when all of the following are true:

Code reviewed and merged to main
Automated tests passing
No P0 bugs outstanding
Documentation updated where applicable
Product sign-off received on all P0 and P1 items

Key Dates

Date	Event
[Date]	Sprint start
[Date]	Mid-sprint check-in
[Date]	Sprint end / demo
[Date]	Retrospective