/scope-of-work

name: memstack-business-scope-of-work
description: "Use this skill when the user says 'scope of work', 'SOW', 'define scope', 'project scope', 'write SOW', 'scope document', or is defining project boundaries, deliverables, and acceptance criteria for a formal engagement. Do NOT use for proposals, contracts, or invoicing."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

📐 Scope of Work: Defining project boundaries and deliverables...

*Generates a formal Scope of Work document with objectives, deliverables, acceptance criteria, in/out scope definitions, work breakdown structure, milestones, and change request process.*

Activation

When this skill activates, output:

`📐 Scope of Work, Defining project scope and deliverables...`

Then execute the protocol below.

| Context | Status | |---------|--------| | User says "scope of work" or "SOW" or "define scope" | ACTIVE | | User says "write SOW" or "project scope" or "scope document" | ACTIVE | | Defining formal project boundaries for a client engagement | ACTIVE | | Writing internal task lists (no formal scope needed) | DORMANT: use Work skill | | Writing a proposal (includes pricing/sales) | DORMANT: use proposal-writer |

Anti-patterns

| Trap | Reality Check | |------|---------------| | "The scope is obvious from the proposal" | Proposals sell. SOWs define. Same project, different documents, different purpose. | | "We don't need to list exclusions" | Every scope dispute starts with "I assumed it was included." List what's OUT explicitly. | | "Acceptance criteria slow us down" | Acceptance criteria prevent "it's not what I wanted" after you've built it. They speed up delivery. | | "We'll handle changes informally" | Informal changes create informal expectations. Formal change requests protect the timeline and budget. | | "Dependencies don't matter yet" | Dependencies determine what blocks what. Discovering them mid-project causes delays. Map them upfront. |

Protocol

Step 1: Define Project Objectives

Establish what success looks like at the highest level:

## 1. Project Objectives

### Primary Objective
[One sentence: what this project delivers and why it matters]

Example: Build a multi-tenant SaaS dashboard that enables [Client]'s customers
to manage their accounts, view analytics, and configure integrations, replacing
the current manual process that requires 3 support staff.

### Success Criteria
| Criteria | Measurement | Target |
|----------|------------|--------|
| Core functionality | All deliverables pass acceptance criteria | 100% |
| Performance | Page load time under 3 seconds | p95 < 3s |
| Reliability | Uptime during business hours | 99.5% |
| User adoption | Active users within 30 days of launch | > 50% of target audience |
| Support reduction | Decrease in support tickets for covered workflows | > 40% reduction |

Success criteria must be **measurable**. "The client is happy" is not a success criterion.
"Support tickets decrease by 40%" is.

**Rules:**

• One primary objective, max 2 sentences
• 3-5 measurable success criteria with specific targets
• Criteria should be verifiable by both parties (no subjective measures)

Step 2: List Deliverables with Acceptance Criteria

Every deliverable needs a clear definition of "done":

## 2. Deliverables

### D1: User Authentication System
**Description:** Complete authentication flow including registration, login, password reset, and OAuth integration with Google.

**Acceptance criteria:**
- [ ] Users can register with email and password
- [ ] Users can log in with email/password and receive a session token
- [ ] Users can reset their password via email link
- [ ] Users can log in with Google OAuth
- [ ] Invalid credentials return appropriate error messages
- [ ] Session expires after 24 hours of inactivity
- [ ] All auth endpoints have rate limiting (5 attempts per 15 minutes)

**Depends on:** None (first deliverable)
**Estimated effort:** 20 hours

---

### D2: Admin Dashboard
**Description:** Administrative interface for managing users, viewing analytics, and configuring system settings.

**Acceptance criteria:**
- [ ] Dashboard loads within 3 seconds on standard broadband
- [ ] Displays active user count, revenue metrics, and system health
- [ ] User management: view, search, edit roles, deactivate accounts
- [ ] Data refreshes automatically every 60 seconds
- [ ] Responsive layout works on desktop (1024px+) and tablet (768px+)
- [ ] Role-based access: admin sees all, manager sees their org only

**Depends on:** D1 (Authentication)
**Estimated effort:** 32 hours

---

### D3: [Next Deliverable]
...

**Acceptance criteria rules:**

• Each criterion is a binary yes/no check: not subjective ("looks good")
• Include functional requirements (what it does)
• Include non-functional requirements (performance, responsiveness, accessibility)
• Include negative cases (error handling, invalid input)
• Number deliverables (D1, D2, D3) for easy reference in change requests

Step 3: Define In-Scope and Out-of-Scope

This section prevents scope disputes. Be exhaustive on exclusions:

## 3. Scope Definition

### In Scope
| Item | Details |
|------|---------|
| User authentication | Registration, login, password reset, Google OAuth |
| Admin dashboard | User management, analytics display, system settings |
| API development | RESTful endpoints for all dashboard operations |
| Database design | Schema, migrations, seed data, RLS policies |
| Deployment | Railway (backend) + Netlify (frontend), CI/CD pipeline |
| Testing | Unit tests for critical paths, integration tests for API |
| Documentation | API docs, deployment guide, user manual |
| Post-launch support | 30-day bug fix window (Standard tier) |

### Out of Scope
| Item | Rationale | If Needed Later |
|------|-----------|----------------|
| Mobile application | Not required for MVP; web app is responsive | Can be