agentleFS
OneWave-AIOneWave-AI/claude-skills/sow-generator/SKILL.md

sow-generator

Skill378 starsChanged 53 days agoMITView on GitHub

Generates professional Statements of Work from a project brief. Use when a user needs to create an SOW, scope a project, define deliverables and milestones, or produce a consulting engagement document.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Verify against the quality checklist below, then write the finished SOW to sow.md in the working directory (or a user-specified path).

    line 28
  2. Distinctive:

    No emojis anywhere in the document.

    line 35
  3. Distinctive:

    All user-provided inputs are reflected accurately

    line 42
  4. Distinctive:

    Every in-scope item has corresponding deliverables

    line 44
  5. Distinctive:

    Every deliverable has measurable acceptance criteria

    line 45
  6. Distinctive:

    Every milestone has a date, associated deliverables, and payment trigger (if applicable)

    line 46
  7. Distinctive:

    All cross-references resolve correctly

    line 52
  8. Distinctive:

    No placeholder brackets remain except those explicitly deferred by the user

    line 53
  9. Distinctive:

    Document reads as a cohesive narrative, not a filled-in template

    line 54
  10. Distinctive:

    Ask clarifying questions whenever the scope is ambiguous enough that the SOW could be interpreted in materially different ways.

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Statement of Work Generator

Generate complete, client-ready Statements of Work from a project brief, meeting the standards of Big Four consulting firms, top-tier agencies, and enterprise procurement. Produce polished documents ready for client review with minimal edits, never rough drafts or templates with blanks.

Contents

  • references/required-inputs.md -- inputs to gather and pre-generation client research
  • references/document-structure.md -- the 16-section SOW structure with templates for every section
  • references/pricing-templates.md -- fixed-price, time-and-materials, and retainer pricing models (Section 11)
  • references/legal-terms.md -- confidentiality, IP, warranties, liability, termination, and other legal clauses (Section 14)
  • references/change-management.md -- change request and change order process (Section 12)
  • references/risk-management.md -- risk register and escalation path (Section 13)

Workflow

  1. Gather the required inputs. Read references/required-inputs.md. If any required item is missing, ask for it explicitly. Do not guess at critical commercial terms.
  2. Research the client. Use WebSearch per references/required-inputs.md to gather company overview, recent news, technology footprint, and regulatory environment. If research yields nothing, proceed on user-provided inputs and flag assumptions explicitly. Never fabricate company information.
  3. Select the pricing model from references/pricing-templates.md based on engagement type (default: fixed-price).
  4. Generate all 16 sections following references/document-structure.md, pulling Section 11 from pricing-templates, Section 12 from change-management, Section 13 from risk-management, and Section 14 from legal-terms. Replace every bracketed placeholder with real values from inputs and research. Leave brackets only where the user explicitly deferred. Mark gaps with [ACTION REQUIRED: ...].
  5. Enforce traceability: every deliverable traces to a scope item, every milestone references deliverables, every payment trigger references a milestone, and all cross-referenced IDs (D-, M-, DEP-, R-, CR-, CO-) are correct.
  6. Verify against the quality checklist below, then write the finished SOW to sow.md in the working directory (or a user-specified path).

Output Requirements

  • Comprehensive: typically 500-800 lines for a standard engagement, longer for complex multi-phase projects.
  • Clean Markdown with proper heading hierarchy, tables, and numbered lists.
  • Professional, precise, unambiguous third-person prose. Define any non-standard jargon on first use.
  • No emojis anywhere in the document.
  • Include a footer note that the document is a template and should be reviewed by qualified legal counsel before execution. Never provide legal advice.

Quality Checklist

Verify before finalizing:

  • All user-provided inputs are reflected accurately
  • Client research is incorporated into Background and Context
  • Every in-scope item has corresponding deliverables
  • Every deliverable has measurable acceptance criteria
  • Every milestone has a date, associated deliverables, and payment trigger (if applicable)
  • Out-of-scope section is specific to this engagement, not generic
  • Assumptions are realistic and comprehensive; dependencies have owners and deadlines
  • Risk register contains engagement-specific risks, not boilerplate
  • Payment schedule sums to the total engagement fee
  • Legal sections are complete and internally consistent
  • All cross-references resolve correctly
  • No placeholder brackets remain except those explicitly deferred by the user
  • Document reads as a cohesive narrative, not a filled-in template
  • Tone is professional and consistent throughout

Notes

  • For regulated industries (healthcare, finance, government), include industry-specific compliance sections (Section 15) and note additional legal review requirements.
  • Ask clarifying questions whenever the scope is ambiguous enough that the SOW could be interpreted in materially different ways. Ambiguity in an SOW is a professional failure.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.