AGENT SKILL

statement-of-work-writer

Writes a dispute-preventing statement of work with explicit inclusions and exclusions, a 2-revision-round limit, acceptance criteria, a 50-percent-upfront or milestone payment schedule, and a change-order clause, from a full template with [FILL] fields. Use when a freelancer or consultant says "write my SOW", "the client keeps adding stuff and I have nothing in writing", "how do I define scope in the contract", "what should my payment terms be", "draft a statement of work for this project", or "client won't sign off on the deliverable". Do NOT use for the persuasive proposal that wins the work - use sales-proposal-writer instead; this skill contracts work already agreed in principle.

License 许可
MIT
所属仓库
SkillMedev/skills
最近更新
2026-10-14
Stars
★ 25
Forks
3

01 前言 Front Matter

name
statement-of-work-writer
description
Writes a dispute-preventing statement of work with explicit inclusions and exclusions, a 2-revision-round limit, acceptance criteria, a 50-percent-upfront or milestone payment schedule, and a change-order clause, from a full template with [FILL] fields. Use when a freelancer or consultant says "write my SOW", "the client keeps adding stuff and I have nothing in writing", "how do I define scope in the contract", "what should my payment terms be", "draft a statement of work for this project", or "client won't sign off on the deliverable". Do NOT use for the persuasive proposal that wins the work - use sales-proposal-writer instead; this skill contracts work already agreed in principle.

03 SKILL.md 正文

Statement of Work Writer

Almost every freelance dispute - unpaid invoices, endless revisions, "that was obviously included" - traces back to a scope document that only listed what IS included and stayed silent on everything else. A dispute-preventing SOW is defined as much by its exclusions as its inclusions, and it decides in advance how three predictable events get handled: the client asks for more, the client goes quiet, and the client won't say "done". This skill writes that document.

It pairs with scope-creep-defense, which enforces at delivery time what this SOW establishes at signing time. In the Freelancer / Consultant OS pack, the scope content comes from productized-service-designer. Worked example: Maya, a freelance brand designer moving from $75/hr hourly work to productized retainers, contracting her $4,900/month Brand System Retainer.

Operating procedure

Step 1: Collect the inputs

  1. The agreed offer: deliverables, quantities, price (from productized-service-designer if productized; for Maya, the Tier 2 retainer at $4,900/month, up to 36 hours).
  2. Client legal name, signer, and start date.
  3. Project type: one-time project or ongoing retainer - this decides the payment schedule.
  4. The 3-5 requests the client is most likely to make that are NOT included. If the freelancer cannot name them, derive them from the "outside the box" list in productized-service-designer. Label guesses as guesses and confirm with the freelancer.

Step 2: Write inclusions AND exclusions

Inclusions follow the deliverable definition rules from productized-service-designer: named artifact, quantity, format, revision rounds, turnaround. Then write the exclusions list - the section most SOWs skip and the reason most disputes happen. Include, at minimum:

  • The likely-adjacent services this freelancer does not provide (Maya: copywriting, naming, motion design, print production and vendor management).
  • Quantity overruns ("social templates beyond 8 per month").
  • Third-party costs (stock assets, fonts, printing) - excluded or billed at cost with pre-approval.
  • Meetings beyond the stated cadence.

State plainly: "Anything not listed under Inclusions is out of scope and handled under the Change Orders section." That single sentence converts every future ambiguity from an argument into a process.

Step 3: Set the revision-round limit

2 rounds per deliverable is the standard (identical across productized-service-designer and scope-creep-defense). Define a round precisely: one consolidated set of comments from a single designated approver, returned within 5 business days. Feedback trickling in over a week is one round, not five. Additional rounds are available at a stated rate - Maya lists $150/hr - so round three is a purchase decision, not a fight.

Step 4: Write acceptance criteria

Every deliverable needs an objective "done" condition plus a deemed-acceptance clause: if the client provides neither approval nor a consolidated revision request within 5 business days of delivery, the deliverable is deemed accepted. Without this clause, a silent client can hold payment hostage indefinitely. Acceptance criteria must be checkable ("delivered as print-ready PDF at the agreed dieline dimensions"), never subjective ("client is happy with the design").

Step 5: Set the payment schedule

  • One-time projects: 50 percent upfront, 50 percent on completion. Never start work before the deposit clears - the deposit is both cash flow and a seriousness filter. Projects over roughly $10,000 or 6 weeks: switch to milestones (e.g. 40/30/30), each milestone invoiced on its acceptance per Step 4.
  • Retainers (Maya's case): full month billed on the 1st, in advance. Retainers are capacity reservations; billing in arrears turns them into disputed timesheets.
  • Late payment terms: work pauses on invoices 7+ days overdue; a late fee (1.5 percent per month is common) stated in the SOW.

Step 6: Add the change-order clause

The pressure valve that keeps the fixed scope fixed: any request outside Inclusions is written up as a one-paragraph change order - description, price, schedule impact - and requires sign-off before work begins. No signed change order, no out-of-scope work. The word-for-word conversation script for invoking this clause gracefully lives in scope-creep-defense; the SOW just has to make the mechanism contractual.

Step 7: Assemble from the template

Template: statement of work

STATEMENT OF WORK

Client: [FILL: legal name]          Provider: [FILL: freelancer/company name]
Effective date: [FILL]              Engagement type: [FILL: project / monthly retainer]

1. SERVICES AND INCLUSIONS
   [FILL: each deliverable - named artifact, quantity, format, turnaround]
   Example (retainer): Up to 8 social templates/month (source + sized exports),
   up to 4 web graphics/month, packaging design for 1 SKU/quarter, monthly
   60-minute creative direction call. Capacity: up to [FILL: 36] hours/month.
   Unused hours do not roll over.

2. EXCLUSIONS
   The following are out of scope: [FILL: adjacent services, quantity overruns,
   third-party costs, extra meetings]. Anything not listed in Section 1 is out
   of scope and handled under Section 7 (Change Orders).

3. REVISIONS
   Each deliverable includes 2 revision rounds. A round is one consolidated set
   of comments from [FILL: designated approver], returned within 5 business
   days. Additional rounds: $[FILL]/hour, invoiced with the next billing cycle.

4. ACCEPTANCE
   A deliverable is accepted when [FILL: objective criteria per deliverable].
   If Client provides neither approval nor consolidated revisions within 5
   business days of delivery, the deliverable is deemed accepted.

5. FEES AND PAYMENT
   [FILL - project: total $____; 50% due on signing, 50% on completion.
    FILL - retainer: $____/month, invoiced on the 1st, due on receipt.]
   Invoices 7+ days overdue pause all work; late fee [FILL: 1.5]%/month.

6. TERM AND TERMINATION (retainers)
   Initial term [FILL: 3] months, then month-to-month with [FILL: 30] days'
   written notice by either party. Prepaid fees for the notice period are due.

7. CHANGE ORDERS
   Requests outside Section 1 are documented in a written change order stating
   description, fee, and schedule impact, and require sign-off from both
   parties before work begins.

8. OWNERSHIP
   Upon full payment, Client owns final deliverables. Provider retains working
   files unless purchased and may display the work in a portfolio.

Signatures: _________________ (Client)   _________________ (Provider)

Concrete thresholds

  • 2 revision rounds standard; a round = one consolidated set of comments.
  • 5 business days for feedback and for deemed acceptance.
  • 50 percent upfront on projects; milestones above ~$10,000 or 6 weeks; retainers billed the 1st in advance.
  • Work pauses at 7 days overdue; 3-month initial retainer term, 30 days' notice after.
  • Exclusions list must name at least 3 specific likely requests - a generic "everything else is excluded" alone reads as boilerplate and invites argument.

Deliverable

A complete, signable SOW with every [FILL] resolved, an exclusions list naming the client's most probable off-scope requests, objective acceptance criteria, and a payment schedule matched to the engagement type.

Do NOT

  • Do not write inclusions without exclusions - the silent scope is the disputed scope.
  • Do not allow "revisions until satisfied" or any undefined revision language; it prices an unlimited liability at zero.
  • Do not start work before the deposit or first retainer invoice clears, whatever the stated urgency. Urgency without payment is a red flag, not an exception.
  • Do not use subjective acceptance criteria; "client satisfaction" is legally and practically unverifiable.
  • Do not bury the change-order clause and then improvise when the first extra request arrives - the clause only works if it exists before it is needed.

Quality bar

Done when: every deliverable has quantity, format, rounds, and turnaround; exclusions name specific likely requests; acceptance has the deemed-acceptance clause; the payment schedule matches engagement type with a work-pause trigger; the change-order clause is present; and no [FILL] remains.

Escalation

This is a working scope document, not legal advice. Have a contract lawyer review the template once for the freelancer's jurisdiction - especially ownership, termination, and liability - and reuse the reviewed version thereafter. For enforcing this SOW when live requests drift, go to scope-creep-defense; for winning the engagement in the first place, sales-proposal-writer.

04 同仓库更多 Skills

SkillMedev
SkillMedev/skills

有氧运动计划

zone-2-cardio-plan

当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练,或提高静息心率、最大摄氧量或耐力时,可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导,不构成医疗建议。请勿用于设计力量或举重训练计划(请使用力量训练计划)、高强度间歇训练 (HIIT) 或循环训练(请使用体能训练和 HIIT 计划),或灵活性/柔韧性训练(请使用灵活性训练计划)。

★ 25
SkillMedev
SkillMedev/skills

youtube-script-writer

Writes retention-engineered long-form YouTube scripts on a hook/body/payoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says "script my next video", "my retention graph dies at the start", "tighten this draft", or "outline a video on X". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.

★ 25
SkillMedev
SkillMedev/skills

win-back-campaign

Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says "our users went quiet", "design a win-back campaign", "how do I re-engage lapsed customers", "should we email people who haven't logged in for months", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.

★ 25
SkillMedev
SkillMedev/skills

wikipedia-style

Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks "write this like a Wikipedia article", "draft a Wikipedia page for this company or person", "make this neutral and encyclopedic", or "why does my article draft keep getting rejected". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.

★ 25
SkillMedev
SkillMedev/skills

whitepapers

Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks "write a whitepaper on this topic", "turn our research into a lead-gen asset", "make this credible enough for executives", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.

★ 25
SkillMedev
SkillMedev/skills

white-space-analysis

Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks "where are the gaps in this market", "what's underserved here", "where should we play next", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.

★ 25