Defines project scope and work breakdown structures for Statement of Work documents. Activates when the user wants to scope a project, define deliverables, break down requirements, or asks 'what should be in the SOW scope?' Generates conservative, balanced, and ambitious scope interpretations for the competing-hypotheses pipeline.
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.
Translate a project brief into a structured scope definition with deliverables, effort estimates, and timeline milestones. Used by Scope Agent A (conservative), Scope Agent B (balanced), and Scope Agent C (ambitious) — all three agents run this skill in parallel during Phase 1 of the competing-hypotheses pipeline.
Every scope proposal must define exactly six elements. Never omit one; use "N/A" only for constraints when there are genuinely none.
| Element | What to define |
|---|---|
| Deliverables | Named outputs the client receives, each with acceptance criteria |
| Effort hours | Numeric estimate per task area, summed to a project total |
| Timeline milestones | Named checkpoints with week numbers from project start |
| Exclusions | Items explicitly out of scope with rationale |
| Assumptions | Conditions that must hold for the estimate to remain valid |
| Constraints | Fixed limits (budget cap, regulatory, team size, deadline) |
Each scope agent applies a different lens to the same brief.
Every item encountered during scope definition must be explicitly classified. Ambiguity in scope is the primary cause of SOW disputes.
Break total project work into discrete task areas before summing:
| Task area | Typical share of effort |
|---|---|
| Discovery and requirements | 5–10% |
| Design and architecture | 10–20% |
| Implementation | 40–55% |
| Testing and QA | 15–20% |
| Documentation | 5–10% |
| Project management overhead | 10–15% |
Never estimate the project as a single number. Break it down first, then sum.
Use T-shirt sizes as a cross-check before committing to hour estimates:
| Size | Hours | Typical scope |
|---|---|---|
| S | 8 h | Single feature or screen, clear requirements |
| M | 20 h | Small module, 2–4 deliverables |
| L | 40 h | Full feature set, cross-functional dependencies |
| XL | 80 h | Complex system, multiple integrations |
| XXL | 160 h+ | Multi-phase program; break into phases |
If a single deliverable sizes as XXL, recommend splitting it into phases rather than estimating it as one line item.
Apply percentile adjustments to the summed estimate, not to individual task areas:
Format every deliverable as a four-part entry:
[Name] — [Description of what is produced] — [Acceptance criteria] — [Milestone week]
Example: User Authentication Module — Login, registration, and password reset flows with JWT session management — All flows pass QA checklist; 0 critical bugs in staging — Week 3
Rules:
Avoid vague deliverable names:
Apply standard exclusions as a starting checklist. Not all will apply to every project — use judgment.
| Exclusion | Recommended path |
|---|---|
| Features scoped to a future phase | "Phase 2 — revisit after [milestone]" |
| Nice-to-have features not in the brief | "Phase 2 if budget allows" |
| Infrastructure provisioning (if not stated) | "Client-side responsibility — provide credentials and access" |
| Third-party vendor dependencies | "Client to own vendor relationship; SOW covers integration only" |
| Training and change management (if not requested) | "Separate engagement upon request" |
| Performance optimization beyond baseline | "Post-launch optimization sprint — separate engagement" |
| Ongoing maintenance | "Maintenance retainer — separate agreement" |
| Data migration (if not stated) | "Requires separate data migration assessment" |
State the exclusion precisely: name the exact feature or activity being excluded, not a category. "All future enhancements" is not a valid exclusion. "Push notification system" is.
Assumptions are conditions that, if false, invalidate the estimate. Only include testable assumptions — ones the client can confirm or deny before signing.
Client assumptions:
Technical assumptions:
Constraints (things that cannot change):
If an assumption is wrong, state explicitly what changes. Example: "If the client cannot provide API access by Week 1, the implementation phase shifts by the number of days delayed — timeline and cost adjust accordingly." This language protects the vendor and sets clear expectations.
Build the change management language into the scope proposal. The synthesis lead will carry this language into the final SOW packages.
Each scope agent must produce a proposal with exactly these sections in order:
Do not add sections. Do not omit sections. The synthesis lead and risk/pricing agents depend on this consistent structure.