一键在 Manus 中运行任何 Skill

sprint-sow

星标6

分支3

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

Generates a Sprint Scope of Work (SOW) document in the exact format used by the team - with Sprint Goal, Overview, Timeline, Team table, Deliverables by Theme (each with a ticket table), Out of Scope list, and Definition of Done checklist. Use this skill whenever the user asks to create, draft, or update a sprint SOW, scope of work document, or sprint planning document. Trigger even if they say "write up the sprint", "create the SOW", or "document this sprint".

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Erica-J-01

Erica-J-01/ai-pm

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

相关职业SOC

基于 SOC 职业分类

项目管理专家商业与金融运营类职业·SOC 13-1082

文件资源管理器

2 个文件

SKILL.md

readonly

同仓库更多 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-sow
description	Generates a Sprint Scope of Work (SOW) document in the exact format used by the team - with Sprint Goal, Overview, Timeline, Team table, Deliverables by Theme (each with a ticket table), Out of Scope list, and Definition of Done checklist. Use this skill whenever the user asks to create, draft, or update a sprint SOW, scope of work document, or sprint planning document. Trigger even if they say "write up the sprint", "create the SOW", or "document this sprint".
version	1.1.0
argument-hint	<sprint goal, dates, team, and ticket list>
allowed-tools	Read, mcp__claude_ai_Atlassian_Rovo__searchJiraIssuesUsingJql, mcp__claude_ai_Atlassian_Rovo__getJiraIssue, mcp__claude_ai_Atlassian_Rovo__createConfluencePage, mcp__claude_ai_Google_Drive__create_file, mcp__claude_ai_Notion__notion-create-pages

Input

$ARGUMENTS

If no input is provided above, ask: "Please share the sprint details - sprint number, goal, start and end dates, team members and roles, and the ticket list with assignees."

If the user names a sprint or board and Jira is connected, pull the ticket list, assignees, dates, and estimates with the Jira read tools instead of asking for a paste. If Jira is not connected, say so once and ask for pasted details - see the Connection Failsafe in .claude/CLAUDE.md.

Sprint Scope of Work Generator

You produce sprint SOW documents that match the team's exact Confluence format. The output is a clean, structured markdown document ready to be pasted into Confluence or saved as a file.

DOCUMENT STRUCTURE (MANDATORY - follow this order exactly)

Header Block

Prepared By: [Name]
Date: [Date]
Version: [1.0]
Status: [Draft | Approved]
Link to the Jira Board: [URL]

Bump Version on any material revision, per the project's Artefact Versioning rule.

Sprint Goal

A single-sentence blockquote capturing the purpose of the sprint.

## Sprint Goal

> [One punchy sentence describing what the sprint achieves and why it matters.]

Overview

2-4 sentences of plain English explaining what this sprint delivers (or doesn't), and why it exists in the context of the product.

## Overview

[Plain English explanation. What is being built. What is NOT being built. Why this sprint matters for future sprints.]

Sprint Timeline

## Sprint Timeline

* Sprint Start: [Date]
* Sprint End: [Date]

Sprint Team

A markdown table with columns: Team Member | Role | Assigned Tickets

Ticket references: when a Jira board or base URL is known, link each key as [TICKET-1](https://<domain>/browse/TICKET-1). When no URL can be derived, write the plain key with no link markup. Never emit a literal (url).

## Sprint Team

| Team Member | Role | Assigned Tickets |
| --- | --- | --- |
| [Name] | [Role] | TICKET-1, TICKET-2 |

Deliverables by Theme

This is the core section. Group tickets into named themes. Each theme gets:

A numbered ### N. Theme Name heading
A 1-sentence description of what the theme establishes
A table: Ticket | Deliverable | Description | Assignee
A --- divider after each theme table

Rules:

Theme names must be short and business-readable (not technical jargon)
Deliverable = short noun phrase describing what is produced
Description = 1-2 plain English sentences explaining what was built and what it does
Never use bullet points inside the table
Always include --- after each theme block
If the input or Jira data carries estimates (story points or days), confirm inclusion in the consolidated intake question - the SOW is client-facing and some teams keep internal points out of it. On yes, add an Estimate column to each theme table and one line after the last theme: Sprint total: [N] [points/days]. If no estimates exist, omit the column entirely - never invent them.

## Deliverables by Theme

### 1. [Theme Name]

[One sentence describing what this theme establishes and why.]

| Ticket | Deliverable | Description | Assignee |
| --- | --- | --- | --- |
| TICKET-1 | [Short noun phrase] | [Plain English description of what it does.] | [Name] |

---

### 2. [Theme Name]

...

Typical themes (adapt to actual sprint content):

Project Scaffold & Architecture
Application Shells
Shared Backend Infrastructure
Logging & Observability
CI/CD & Quality Gates
Error Handling
Developer Experience & AI Tooling
Quality Assurance & Release

Out of Scope

A bulleted list of items explicitly NOT in this sprint. Be specific - name deferred tickets and target sprints where known.

## Out of Scope - Sprint [N]

The following are explicitly excluded from this sprint and will be addressed in subsequent sprints:

* [Item]
* [Item - deferred to Sprint N (TICKET-KEY where known)]

Dependencies & Assumptions (optional)

Include only when the input itself surfaces client-side dependencies (access, credentials, content, sign-off) or load-bearing assumptions. Never generate this section from nothing and never pad it with boilerplate.

## Dependencies & Assumptions

* [Client-side dependency - what is owed, by whom, by when]
* [Load-bearing assumption taken from the input]

Definition of Done

A checklist of binary, testable completion criteria. Each item must be objectively verifiable.

## Definition of Done

Sprint [N] is considered complete when all of the following conditions are met:

- [ ] [Testable condition]
- [ ] [Testable condition]

Approval

One line at the end of the document. Leave it as Pending while Status is Draft.

Approval: [Approver name], [Date]

BEHAVIOUR RULES

One consolidated ask, then proceed. If any of sprint number, sprint goal, sprint dates, team members + roles, or the ticket list with assignees is missing, gather every gap - plus the carry-over and estimate confirmations - into a single question. If the user says proceed anyway, generate the draft with each gap marked TBC - confirm and list the open TBCs after the document. Never re-block once the user has said proceed.
Never invent ticket numbers or URLs. When a Jira board or base URL is known, link each key as https://<domain>/browse/<KEY>. When no URL can be derived, write the plain ticket key with no link markup. Never emit a literal (url).
Match the writing register - plain English, present-tense imperative for deliverable descriptions ("Establishes...", "Validates...", "Provides..."). No buzzwords, no passive voice bloat.
No invented sections. Do not add Executive Summary, User Stories, Acceptance Criteria, or Epics. This is an SOW, not a spec document. A short Dependencies & Assumptions list is allowed only when the input itself surfaces client-side dependencies or load-bearing assumptions - never boilerplate, never invented.
Tables over bullets - always use tables for deliverables, never bulleted lists.
One document per sprint - do not mix sprints or produce multiple SOWs in one response.
Reconcile carry-over. Before generating, Read the previous sprint's SOW in the active project's sprint-artefacts/ folder if one exists. If it deferred an item to this sprint that is missing from the new ticket list, flag the mismatches once ("PDF export was deferred to this sprint but is not in the ticket list - deliberately dropped, or missing?"), folded into the consolidated intake question when one is already being asked. Never block on the answer and never silently add the item.

OUTPUT DELIVERY

Render the full document in chat as clean markdown.
Follow the Saving Artefacts rules in .claude/CLAUDE.md - ask where to save before writing anything. Default local path: clients/CLIENT/sprint-artefacts/YYYY-MM-DD-sprint-N-sow.md
If the chosen platform isn't connected (Confluence, Drive, or Notion MCP unavailable): say so and fall back to a local file or clean markdown to copy. Never claim a page was published when no MCP tool actually ran. See Connection Failsafe in .claude/CLAUDE.md.