Help us improve
Share bugs, ideas, or general feedback.
From founder-os
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.
npx claudepluginhub thecloudtips/founder-os --plugin founder-osHow this skill is triggered — by the user, by Claude, or both
Slash command
/founder-os:scope-definitionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
Generates a formal Scope of Work document with objectives, deliverables, acceptance criteria, in/out scope definitions, work breakdown structure, milestones, and change request process.
Guides software project planning with discovery questions, requirements gathering, user stories, MoSCoW prioritization, T-shirt estimation, scope management, risk assessment, and templates for briefs and epics. Use for new projects or features.
Turns ideas into buildable feature specs, project scopes, requirements, or MVP definitions. Guides quick workflows for AI builds and full scopes for planning and estimates.
Share bugs, ideas, or general feedback.
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.