From memstack
Generates formal Scope of Work documents defining project objectives, deliverables, acceptance criteria, in/out scope, work breakdown structure, milestones, and change request processes.
npx claudepluginhub cwinvestments/memstack --plugin memstackThis skill uses the workspace's default tool permissions.
*Generates a formal Scope of Work document with objectives, deliverables, acceptance criteria, in/out scope definitions, work breakdown structure, milestones, and change request process.*
Drafts project charter defining scope, stakeholders, RACI matrix, milestones, success criteria, and risk register for agile/classic projects. Use for kickoffs, scope formalization, or stakeholder alignment.
Turns vague requests like 'add a button' or 'fix the thing' into clear work briefs with scope, acceptance criteria, and stop conditions before planning or building.
Analyzes feature requests, maintains PRDs, and decomposes into tracks with work breakdowns and execution order. For new feature planning, architecture changes, requirements analysis, or plan adjustments.
Share bugs, ideas, or general feedback.
Generates a formal Scope of Work document with objectives, deliverables, acceptance criteria, in/out scope definitions, work breakdown structure, milestones, and change request process.
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 |
| 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. |
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:
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:
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 added via Change Request |
| Content creation | Client provides all copy, images, and branding | Content services available separately |
| Email marketing | No email campaigns or newsletter integration | Recommend Mailchimp integration post-launch |
| Payment processing | No billing or payment features in this phase | Phase 2 scope, separate SOW |
| Data migration | No import of existing data from legacy systems | Can be scoped as separate project |
| SEO optimization | Beyond basic meta tags and semantic HTML | SEO audit available as add-on |
| Accessibility audit | WCAG compliance testing by third party | Recommend post-launch audit |
| Browser support | IE11 or older browsers | Modern browsers only (Chrome, Firefox, Safari, Edge) |
| Load testing | Stress testing beyond normal usage patterns | Recommend before scaling |
### Assumptions
| # | Assumption | Impact if Wrong |
|---|-----------|----------------|
| A1 | Client provides branding assets (logo, colors, fonts) by kickoff | Delays Phase 2 by duration of delay |
| A2 | Client designates one decision-maker for feedback | Multiple reviewers slow approval cycles |
| A3 | Existing API documentation is accurate and current | Additional discovery time needed |
| A4 | Production hosting costs are paid by client directly | Hosting setup may differ |
| A5 | Feedback is provided within 2 business days of each review | Timeline shifts day-for-day |
Rules:
Map tasks with dependencies:
## 4. Work Breakdown Structure
### Phase 1: Foundation (Week 1-2)
| Task | Deliverable | Depends On | Hours |
|------|------------|-----------|-------|
| 1.1 Project setup (repo, CI/CD, environments) | D1 | β | 6 |
| 1.2 Database schema design and migration | D1 | β | 8 |
| 1.3 Authentication: email/password flow | D1 | 1.1, 1.2 | 10 |
| 1.4 Authentication: Google OAuth | D1 | 1.3 | 6 |
| 1.5 Authentication: password reset | D1 | 1.3 | 4 |
| 1.6 Auth testing and hardening | D1 | 1.3, 1.4, 1.5 | 6 |
| **Phase 1 total** | | | **40** |
### Phase 2: Core Features (Week 3-5)
| Task | Deliverable | Depends On | Hours |
|------|------------|-----------|-------|
| 2.1 Dashboard layout and navigation | D2 | 1.3 | 8 |
| 2.2 User management CRUD | D2 | 2.1, 1.6 | 12 |
| 2.3 Analytics display components | D2 | 2.1 | 10 |
| 2.4 System settings interface | D2 | 2.1 | 8 |
| 2.5 Role-based access control | D2 | 2.2 | 8 |
| 2.6 Dashboard testing | D2 | 2.2, 2.3, 2.4, 2.5 | 10 |
| **Phase 2 total** | | | **56** |
### Phase 3: Polish & Launch (Week 6-7)
| Task | Deliverable | Depends On | Hours |
|------|------------|-----------|-------|
| 3.1 API documentation | D3 | 2.6 | 6 |
| 3.2 Deployment setup (production) | D3 | 2.6 | 8 |
| 3.3 User manual / guides | D3 | 2.6 | 6 |
| 3.4 Final QA and bug fixes | All | 3.1, 3.2, 3.3 | 12 |
| 3.5 Client UAT support | All | 3.4 | 4 |
| **Phase 3 total** | | | **36** |
**Total hours: 132** (+/- 15% contingency)
WBS rules:
## 5. Milestones
| # | Milestone | Target Date | Go/No-Go Criteria | Deliverables |
|---|-----------|------------|-------------------|-------------|
| M1 | Kickoff | [Date] | Signed SOW, deposit received, access granted | β |
| M2 | Phase 1 Review | [Date + 2 wk] | All D1 acceptance criteria pass on staging | D1: Auth system |
| M3 | Phase 2 Review | [Date + 5 wk] | All D2 acceptance criteria pass on staging | D2: Dashboard |
| M4 | UAT Begin | [Date + 6.5 wk] | Client begins user acceptance testing | All deliverables on staging |
| M5 | Launch | [Date + 7.5 wk] | All acceptance criteria pass, client sign-off | Production deployment |
| M6 | Support Period End | [Date + 11.5 wk] | No critical bugs open | Support handoff |
### Go/No-Go Process
At each milestone review:
1. Vendor demonstrates completed deliverables against acceptance criteria
2. Client has **2 business days** to review and provide feedback
3. **Go:** Client confirms acceptance criteria are met β proceed to next phase
4. **No-Go:** Client provides specific items that fail acceptance criteria β vendor addresses within 3 business days β re-review
5. If no response within 2 business days, milestone is considered accepted
**Milestone acceptance is required before the next phase begins.** This protects both parties from building on unapproved work.
## 6. Constraints & Dependencies
### Constraints
| Constraint | Impact |
|-----------|--------|
| Budget ceiling of $XX,XXX | Scope adjustments if estimates exceed budget |
| Launch deadline of [date] | Feature prioritization required if timeline slips |
| Must integrate with [existing system] | API compatibility required, may limit tech choices |
| Data must remain in [region] | Hosting provider and database region restricted |
### External Dependencies
| Dependency | Owner | Required By | Risk if Delayed |
|-----------|-------|------------|----------------|
| Branding assets (logo, colors) | Client | M1 (Kickoff) | Delays Phase 2 UI work |
| API credentials for [service] | Client | Phase 2 start | Blocks integration tasks |
| DNS access for domain setup | Client | Phase 3 start | Blocks production deployment |
| Stakeholder availability for UAT | Client | M4 | Delays launch milestone |
| Code review approval | Vendor lead | Each phase end | Blocks milestone sign-off |
## 7. Change Management
### Change Request Process
Changes to scope, timeline, or budget follow this process:
1. **Request:** Either party submits a written change request describing:
- What changes (new feature, modified requirement, removed item)
- Why the change is needed
- Which deliverables are affected
2. **Impact Assessment:** Vendor provides within 3 business days:
- Hours impact (additional or reduced)
- Cost impact (additional or credit)
- Timeline impact (delay or no change)
- Risk assessment (what else might be affected)
3. **Approval:** Client reviews and provides written approval or rejection
- Approved changes update this SOW as an amendment
- Rejected changes are documented but not implemented
4. **Implementation:** Approved changes begin in the next phase or sprint
### Change Request Template
CHANGE REQUEST #[number] Date: YYYY-MM-DD Requested by: [Name]
Description: [What changes and why]
Affected deliverables: [D1, D2, etc.] Hours impact: [+/- N hours] Cost impact: [+/- $X,XXX] Timeline impact: [+/- N days/weeks]
Approved: [ ] Yes [ ] No Signature: _______________ Date: ___________
### Out-of-Process Changes
Work requested outside the change request process (verbal, chat, email without formal CR) is not included in this SOW and will not be implemented. This protects both parties from scope drift.
Output the complete SOW:
# Scope of Work: [Project Name]
| Field | Value |
|-------|-------|
| **Client** | [Client Name, Company] |
| **Vendor** | [Your Name / Company] |
| **Date** | YYYY-MM-DD |
| **Version** | 1.0 |
| **Valid until** | [Date + 30 days] |
---
## Table of Contents
1. Project Objectives
2. Deliverables
3. Scope Definition
4. Work Breakdown Structure
5. Milestones
6. Constraints & Dependencies
7. Change Management
---
[Section 1-7 content]
---
## Signatures
This Scope of Work is agreed to by both parties:
**Client:**
Name: ___________________________
Title: ___________________________
Signature: ___________________________
Date: ___________________________
**Vendor:**
Name: ___________________________
Title: ___________________________
Signature: ___________________________
Date: ___________________________
---
## Amendments
| # | Date | Description | Approved By |
|---|------|-------------|------------|
| β | β | Original SOW | β |
---
*This document, together with any approved amendments, constitutes the complete
agreement regarding the scope of work for this project.*
Output summary:
π Scope of Work β Complete
Project: [name]
Client: [client name]
Deliverables: [count] with [total] acceptance criteria
Phases: [count] across [weeks] weeks
Total hours: [count] (+/- 15%)
Milestones: [count] with go/no-go gates
Assumptions: [count]
Exclusions: [count] items explicitly out of scope
Document: [word count] words
Next steps:
1. Review with client, negotiate any changes
2. Both parties sign the document
3. File signed copy and begin kickoff preparations
4. Set up milestone calendar reminders