$ loading_
Plan sprint scope, capacity, goals, and a realistic execution plan.
The material indicates this is an open-source, prompt-only sprint planning template. It requires no secrets, declares no remote endpoints, and shows no inherent local code execution or data write capability. Overall risk is low; the main caveat is that the README mentions optional connected tools, which could introduce external system access in extended use, but that is not directly enabled by the current material itself.
The material explicitly states that no keys or environment variables are required. As a prompt-only skill, it does not request tokens and shows no credential collection, storage, or forwarding behavior, so credential misuse risk is low.
Both the system checks and the material show no remote endpoints. The README only mentions optional integrations with project trackers, calendars, and chat tools when the user connects them, but the current skill itself does not declare active networking or outbound user data transfer.
It is classified as prompt-only, and the documentation is limited to planning workflow and output templates. There is no indication of starting local processes, running scripts, or invoking system-level capabilities.
Based on the material, it only handles project-management information provided by the user, such as team availability, sprint duration, backlog, and dependencies. It does not declare reading or writing local files, system resources, or other protected data; data access appears limited to conversation input.
The source is an open GitHub repository, which is a clear positive for auditability. However, the license is undeclared, community adoption is 0 stars, and maintenance status is unknown, so supply-chain trust is reasonable but still warrants attention to repository maintenance and licensing boundaries.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "sprint-planning" skill from askskill: 1. Download https://raw.githubusercontent.com/anthropics/knowledge-work-plugins/main/product-management/skills/sprint-planning/SKILL.md 2. Save it as ~/.claude/skills/sprint-planning/SKILL.md 3. Reload skills and tell me it's ready
Help me plan the next two-week sprint. The team has 4 engineers, 1 designer, and 1 QA; one engineer is on PTO for 2 days. Recurring meetings take 4 hours per person per week. Backlog items: A 8 points P0; B 5 points P1; C 3 points P0; D 13 points P1; E 8 points P2. Estimate available capacity, define sprint goals, and split work into committed vs stretch items.
A sprint plan with capacity calculations, sprint goals, committed scope, stretch scope, and scheduling recommendations.
We have two carryover items from the last sprint: 5 points left for login refactor and 3 points left for export optimization. This sprint also has 6 new candidate tasks totaling 28 points. Team capacity this sprint is about 24 points. Based on business priority and risk, recommend what should be included now vs deferred, and explain why.
A prioritization recommendation covering carryover and new work, with included items, deferred items, and decision rationale.
Estimate the actual capacity for this sprint based on team availability. The team has 3 frontend engineers, 2 backend engineers, and 1 product manager. The sprint lasts 10 working days. Two frontend engineers are taking 1 and 2 days off; each backend engineer has half a day of on-call duty; everyone spends 1 hour per day in meetings. Provide role-level and team-level capacity estimates, and recommend a safe commitment range.
A role-based capacity estimate and a recommended safe workload commitment range for the sprint.
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Plan a sprint by scoping work, estimating capacity, and setting clear goals.
/sprint-planning $ARGUMENTS
┌─────────────────────────────────────────────────────────────────┐
│ SPRINT PLANNING │
├─────────────────────────────────────────────────────────────────┤
│ STANDALONE (always works) │
│ ✓ Define sprint goals and success criteria │
│ ✓ Estimate team capacity (accounting for PTO, meetings) │
│ ✓ Scope and prioritize backlog items │
│ ✓ Identify dependencies and risks │
│ ✓ Generate sprint plan document │
├─────────────────────────────────────────────────────────────────┤
│ SUPERCHARGED (when you connect your tools) │
│ + Project tracker: Pull backlog, create sprint, assign items │
│ + Calendar: Account for PTO and meetings in capacity │
│ + Chat: Share sprint plan with the team │
└─────────────────────────────────────────────────────────────────┘
## Sprint Plan: [Sprint Name]
**Dates:** [Start] — [End] | **Team:** [X] engineers
**Sprint Goal:** [One clear sentence about what success looks like]
### Capacity
| Person | Available Days | Allocation | Notes |
|--------|---------------|------------|-------|
| [Name] | [X] of [Y] | [X] points/hours | [PTO, on-call, etc.] |
| **Total** | **[X]** | **[X] points** | |
### Sprint Backlog
| Priority | Item | Estimate | Owner | Dependencies |
|----------|------|----------|-------|--------------|
| P0 | [Must ship] | [X] pts | [Person] | [None / Blocked by X] |
| P1 | [Should ship] | [X] pts | [Person] | [None] |
| P2 | [Stretch] | [X] pts | [Person] | [None] |
### Planned Capacity: [X] points | Sprint Load: [X] points ([X]% of capacity)
### Risks
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [What happens] | [What to do] |
### Definition of Done
- [ ] Code reviewed and merged
- [ ] Tests passing
- [ ] Documentation updated (if applicable)
- [ ] Product sign-off
### Key Dates
| Date | Event |
|------|-------|
| [Date] | Sprint start |
| [Date] | Mid-sprint check-in |
| [Date] | Sprint end / Demo |
| [Date] | Retro |
Create stakeholder updates tailored to audience, cadence, and communication goals.
Review an analysis for methodology, accuracy, bias, and evidence support.
Generate people analytics reports on headcount, attrition, diversity, and org health.
Identify, categorize, and prioritize technical debt for smarter refactoring decisions.
Choose the right Zoom surface for a product use case with clear tradeoffs.
Turn an approved brief into social assets, copy, and a staged campaign.
Analyze team capacity and forecast utilization for planning, staffing, and prioritization.
Plan task capacity and queue handling to improve execution and resource allocation.
Turn requirements into a clear step-by-step execution plan before implementation.
Create objective-driven plans for agent-led development with an audit trail.
Create step-by-step implementation plans for engineers new to a codebase.
Execute detailed plans in batches with review checkpoints and course correction.