跳到主要内容
知仓学习社ZHICANG

statement-of-work

Write a tight Statement of Work (SOW) that prevents scope creep and payment disputes. Use when asked to write a SOW, a scope of work, a project agre…

不碰外部(只输出文字)无严重或高危命中mohitagw15856/pm-claude-skills

它会碰到什么

扫了多少1 个文本文件,4 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

Statement of Work Skill

The proposal wins the deal; the SOW protects it. Most consulting pain — scope creep, "that's not what I

meant," late or withheld payment — traces to a vague SOW. This skill writes a precise one: exactly what's

in (and explicitly out), how each deliverable is accepted, when money changes hands, and how changes are

handled — so both sides are protected.

Required Inputs

Ask for these only if they aren't already provided:

  • The engagement — parties, and what was agreed (often from a [consulting-proposal](../consulting-proposal/SKILL.md)).
  • Deliverables — the concrete outputs and how "done" is judged.
  • Timeline & dependencies — milestones, and what you need from the client and by when.
  • Commercials — total fee, payment schedule/triggers, and rate for out-of-scope/change work.

Output Format

Statement of Work — [project]

Between: [provider] and [client] · Effective: [date]

1. Scope — what will be done, specifically. Then explicit exclusions ("Out of scope: …") — the most valuable section; unsaid scope is assumed-included by clients.

2. Deliverables & acceptance criteria — each deliverable with how it's accepted (the objective bar, and a review window — e.g. "approved, or feedback within 5 business days, else deemed accepted").

| Deliverable | Acceptance criteria | Due |

|---|---|---|

3. Timeline & milestones — phases, dates, and client dependencies (their inputs/approvals — and what happens to the timeline if they slip).

4. Payment schedule — amounts tied to milestones/dates, invoicing terms, and late-payment terms. Deposit up front where appropriate.

5. Assumptions — what the plan and price depend on (access, environments, responsiveness) — so a broken assumption is a change, not a fight.

6. Change control — how scope changes are requested, priced (the change rate), and approved in writing before work proceeds. This is the anti-scope-creep clause.

7. Terms — IP/ownership (on payment), confidentiality, termination, liability — flag that legal should review for material engagements.

Quality Checks

  • [ ] Scope includes an explicit "out of scope / exclusions" list
  • [ ] Every deliverable has objective acceptance criteria and a review/sign-off window
  • [ ] Payment is tied to milestones/dates with late terms (and a deposit where apt)
  • [ ] Client dependencies are listed, with the timeline consequence if they slip
  • [ ] A written change-control process with a change rate is defined
  • [ ] Assumptions the price depends on are stated

Anti-Patterns

  • [ ] Do not leave scope open-ended — without exclusions, clients reasonably assume everything is included
  • [ ] Do not omit acceptance criteria — "deliver a website" with no bar means endless revisions
  • [ ] Do not skip change control — it's the clause that turns scope creep into billable change requests
  • [ ] Do not ignore client dependencies — if their delay silently becomes your problem, you eat the cost
  • [ ] Do not present this as final legal advice — recommend counsel review for significant contracts

Based On

Statement-of-work / contracting practice — explicit scope + exclusions, acceptance criteria, milestone payments, change control.

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。

同名技能的其他版本

有 3 个不同仓库或目录里都有叫 statement-of-work 的技能。它们内容并不相同,别混用: