Synthesizes scope definitions and risk assessments into a polished Statement of Work document. Activates when the user wants to write, generate, or format a SOW, or asks 'create the final SOW document.' Produces professional client-facing output with multiple scope options, risk annotations, and clear deliverable specifications.
From founder-osnpx claudepluginhub thecloudtips/founder-os --plugin founder-osThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Produce professional, client-ready Statement of Work documents in Markdown format. Used by: scope-agent-a, scope-agent-b, and scope-agent-c during Phase 1 (independent hypothesis proposals), and sow-lead during Phase 3 (final synthesis into the three-option deliverable).
Transform a project brief into a structured SOW document a client can read, compare, and sign off on without further clarification. Each option must be self-contained: a reader viewing only Option A should understand the full engagement without cross-referencing other options. All output is Markdown — never produce DOCX directly. The user converts to DOCX, PDF, or other formats as needed.
Scope agents produce one draft SOW per agent (conservative, balanced, or ambitious). The sow-lead combines those three drafts — enriched by risk-agent and pricing-agent evaluations — into a single final document containing all three options with a comparison table and a provider recommendation.
Produce sections in this exact order for every SOW option. Omit a section only when input data provides no basis for it, and note the omission in a <!-- OMITTED: reason --> comment.
# Statement of Work: [Project Name]
**Client:** [Client Name]
**Provider:** [Service Provider Name]
**Date:** [ISO date: YYYY-MM-DD]
**Version:** 1.0
Write 2-3 sentences. Cover: what the engagement is, what the client will have at the end, and the total timeframe. Do not introduce individual deliverables here — save those for Scope of Work.
List 3-5 measurable outcomes the client receives. Frame from the client's perspective, not the provider's activities. Each objective must be testable at project close.
Example:
Present a deliverables table. Every row is a discrete, handoff-ready deliverable — never list activities or phases as deliverables.
| Deliverable | Description | Milestone | Acceptance Criteria |
|-------------|-------------|-----------|---------------------|
| [Name] | [1-2 sentences: what it is and what problem it solves] | Week [N] | [Measurable test for "done"] |
Rules for acceptance criteria: write a test, not a description. "Functional" is not an acceptance criterion. "Processes 100 concurrent transactions without error" is.
Present an explicit exclusions table. Include everything a client might reasonably expect that is not included. Missing exclusions create scope disputes.
| Excluded Item | Rationale |
|---------------|-----------|
| [Item] | [One sentence: why it is excluded and what to do instead] |
Present a milestone table. Use a single committed week number per milestone — no ranges.
| Milestone | Deliverables | Week | Dependencies |
|-----------|-------------|------|--------------|
| Kickoff | Brief review, environment setup | 1 | Signed SOW, access credentials |
| [Name] | [Deliverable names from Scope of Work] | [N] | [Prerequisite milestones or client actions] |
| Final Delivery | All deliverables accepted | [N] | Client acceptance on all prior milestones |
Present a pricing table with explicit hours, rates, and subtotals. Round to the nearest whole dollar. Never use ranges in the Investment section.
| Component | Hours | Rate (USD/hr) | Subtotal |
|-----------|-------|---------------|----------|
| [Role or phase] | [N] | $[X] | $[Y] |
| **Total** | **[N]** | | **$[Z]** |
Follow with a one-sentence payment schedule: e.g., "50% due at contract signing; 50% due on final delivery acceptance."
Number each assumption. Write testable statements — if an assumption is wrong, it triggers a change order. Include assumptions about: client-provided assets, access, and approvals; third-party integrations; timeline dependencies; and technical environment.
Example:
Include this section verbatim, adjusting the threshold dollar amount for each option:
Any change to scope, timeline, or deliverables is handled through a written Change Order. The provider documents the change, its impact on timeline and investment, and presents it to the client for approval before work begins. Changes under $[threshold] with no timeline impact may be absorbed at provider discretion. All other changes require a signed Change Order.
Include three standard sub-sections kept brief. Do not expand these into full legal language — this is a commercial SOW, not a contract:
When sow-lead synthesizes the final output, produce a single Markdown document in this structure:
# Statement of Work: [Project Name]
[Client Name] x [Provider Name] | [Date]
---
## Executive Summary
[2-3 sentences covering the full engagement context. State what the client wants to achieve and that three scope options follow.]
---
## Option Comparison
| | Option A: [Conservative Name] | Option B: [Balanced Name] | Option C: [Ambitious Name] |
|---|---|---|---|
| Scope | Conservative — core deliverables only | Balanced — core + highest-value additions | Ambitious — full vision |
| Timeline | [N] weeks | [N] weeks | [N] weeks |
| Investment | $[X] | $[X] | $[X] |
| Risk Profile | Low | Medium | Medium-High |
| Best For | Risk-averse clients; tight budget | Most clients; proven ROI | Growth-focused; flexible budget |
| | | ✓ Recommended | |
---
## Option A: [Conservative Name]
[Full Standard SOW Sections 1-10]
---
## Option B: [Balanced Name]
[Full Standard SOW Sections 1-10]
---
## Option C: [Ambitious Name]
[Full Standard SOW Sections 1-10]
---
## Provider Recommendation
[1 paragraph: identify which option is recommended and why. Ground the recommendation in the client's stated priorities from the brief — budget sensitivity, timeline urgency, growth ambitions, or risk tolerance. Do not recommend based on revenue to the provider.]
Give each option a memorable name beyond "Option A/B/C". The name must signal value and fit to the client, not internal scope sizing.
Naming patterns that work:
Naming patterns to avoid:
Apply these rules across all SOW content:
Voice and tense: Use active voice and present tense for deliverables. Write "The team delivers a fully tested API integration" not "An API integration will be delivered." Use future tense only in timeline and milestone contexts.
Numbers: Use exact figures everywhere. Hours, dollars, and weeks must be single committed values — never ranges. Reserve ranges for the Assumptions section when a dependency is client-controlled.
Client-first framing: Open every deliverable description with what the client receives or achieves, not what the provider does. "A mobile-responsive storefront the client's team can manage without developer support" not "We will build a mobile-responsive storefront."
Sentence length: Keep sentences under 25 words in the Scope of Work and Deliverables sections. Longer sentences are acceptable in the Executive Overview and Provider Recommendation.
Specificity: Every vague word is a scope dispute waiting to happen. Replace "consulting" with the specific advice type. Replace "ongoing support" with a defined ticket volume and response SLA. Replace "and similar activities" with an explicit list or explicit exclusion.
Vague deliverables: "Consulting services" and "ongoing support" are not deliverables. Define the concrete output: "8 hours of technical advisory per month, delivered as written recommendations via email."
Scope creep language: "And similar activities," "as needed," and "reasonable requests" open the door to unlimited scope expansion. Every deliverable must have a defined boundary.
Wishy-washy timelines: "Approximately 8-10 weeks" is a hedge that clients read as a commitment to 8 weeks. Commit to one number. If a dependency creates genuine uncertainty, name the dependency in the Assumptions section.
Missing acceptance criteria: "Deliverable is complete when the client is satisfied" is not a criterion. Every deliverable needs an objective, testable condition.
Omitting the exclusions section: Clients assume everything adjacent to the project is included unless explicitly excluded. A missing exclusions section does not protect the provider.
Price as first differentiator: Never lead the comparison table with price. Clients choosing on price alone choose the lowest option regardless of fit. Lead with scope and outcomes; price follows as a consequence of scope.
The Option Comparison table at the top of the final document must follow these rules:
Before passing a completed SOW draft to the next agent or outputting the final document, confirm:
On completion, create or update a record in the consolidated "[FOS] Deliverables" database with Type = "SOW".
When writing to "[FOS] Deliverables" or "Founder OS HQ - Deliverables":
./sow-output/sow-acme-corp-2026-02-24.md)/founder-os:sow:from-brief was usedAfter creating the SOW record, link it to its source Proposal:
When writing to "[FOS] Deliverables" or "Founder OS HQ - Deliverables":
Upsert key: Client Name + Project Title. When upserting in "Founder OS HQ - Deliverables", also filter by Type = "SOW" to avoid collisions with other deliverable types (Proposals, Contracts).
When falling back to legacy "SOW Generator - Outputs" database: