Required Plugins

Superpowers plugin: MUST be active for all work using this skill. Use throughout the entire build pipeline — design decisions, code generation, debugging, quality checks, and any task where it offers enhanced capabilities. If superpowers provides a better way to accomplish something, prefer it over the default approach.

SDLC Planning Skill

Generate a complete Planning & Management documentation suite for software development projects. This skill produces 7 foundational documents that establish the project baseline before any code is written.

When to Use

Starting a new SaaS project and need a governance baseline
Establishing project planning documents for stakeholders or investors
Conducting a feasibility study before committing resources
Setting up configuration management and quality assurance processes
Creating a software development plan for the team
Building a risk management framework for an upcoming project
Preparing a full-system SRS (not just requirements interview or Android-only)

When NOT to Use

Gathering raw requirements via interview -- use project-requirements skill instead
Planning a single feature (spec + implementation) -- use feature-planning skill
Planning an Android companion app (PRD, SDS, API Contract) -- use android-saas-planning skill
Writing design documents (SDD, architecture, database design) -- use sdlc-design skill
Writing test plans with test cases -- use sdlc-testing skill
Writing deployment or user documentation -- use sdlc-user-deploy skill

Document Inventory

#	Document	File	Purpose	Audience	Length
1	Project Vision & Scope	`templates/project-vision-scope.md`	Establish the "why" and "what"	Stakeholders, sponsors, investors	15-30 pages
2	Software Development Plan	`templates/software-development-plan.md`	Management & technical approach	PM, dev leads, QA	20-40 pages
3	Configuration Management Plan	`templates/configuration-management-plan.md`	Change & version control processes	DevOps, dev leads, release mgrs	15-25 pages
4	Quality Assurance Plan	`templates/quality-assurance-plan.md`	Quality processes & standards	QA team, devs, PM	15-25 pages
5	Risk Management Plan	`templates/risk-management-plan.md`	Identify, assess, mitigate risks	PM, stakeholders, dev leads	15-25 pages
6	Software Requirements Spec	`templates/software-requirements-spec.md`	Full functional & non-functional requirements	Devs, QA, stakeholders, architects	30-60 pages
7	Feasibility Study Report	`templates/feasibility-study-report.md`	Viability analysis before commitment	Decision makers, investors, sponsors	15-30 pages

Generation Workflow

Generate documents in this order. Each builds on the previous.

Step 1: Gather context (use project-requirements skill if not done)
    |
Step 2: Feasibility Study Report (Go/No-Go decision)
    |
Step 3: Project Vision & Scope (approved vision)
    |
Step 4: Software Requirements Specification (full requirements)
    |
Step 5: Software Development Plan (how to build it)
    |
Step 6: Configuration Management Plan (how to manage changes)
    |
Step 7: Quality Assurance Plan (how to ensure quality)
    |
Step 8: Risk Management Plan (what can go wrong)

Prerequisites

Before generating any documents, gather or confirm:

Input	Source	Required?
Project name & domain	User interview	Yes
Target market & users	User interview	Yes
Core feature list	`project-requirements` output or user	Yes
Tech stack decisions	Project context or defaults	Yes
Budget & timeline constraints	User or stakeholder	Recommended
Existing system inventory	Codebase audit	If migrating
Regulatory requirements	User or domain research	If applicable

Cross-References to Existing Skills

Upstream Skills (use BEFORE this skill)

Skill	Relationship
`project-requirements`	Gathers raw requirements via guided interview. Feed its output (requirements.md, business-rules.md, user-types.md, workflows.md) into this skill's SRS and Vision documents.

Parallel Skills (use ALONGSIDE this skill)

Skill	Relationship
`feature-planning`	For individual feature specs and implementation plans. This skill covers project-level planning; `feature-planning` covers feature-level planning.
`vibe-security-skill`	Security baseline for all web applications. Reference in QA Plan and Risk Plan.

Downstream Skills (use AFTER this skill)

Skill	Relationship
`android-saas-planning`	For Android companion app planning (PRD, SDS, API Contract). Uses this skill's SRS as input.
`multi-tenant-saas-architecture`	Backend architecture patterns. Uses SDP and SRS as input.
`modular-saas-architecture`	Pluggable module architecture. Uses SRS module inventory.
`saas-seeder`	Bootstrap the SaaS template. Uses requirements from SRS.

Available SDLC Skills

Skill	Phase	Documents
`sdlc-design`	Design	SDD, Database Design, API Design, UI/UX Spec
`sdlc-testing`	Testing	Test Plan, Test Cases, V&V Plan, Test Report, Peer Review

Available SDLC Skills (continued)

Skill	Phase	Documents
`sdlc-user-deploy`	Delivery	User Manual, Deployment Guide, Release Notes, Training Plan

Adaptation Rules

SaaS vs Standalone

Aspect	Multi-Tenant SaaS	Standalone App
Data isolation	Row-level via `franchise_id`	Not applicable
Auth model	Dual auth (Session + JWT)	Single auth model
Deployment	3-env (dev/staging/prod)	May be simpler
Scaling	Per-tenant growth planning	Single-instance scaling
SRS sections	Include NFR-MT (multi-tenancy)	Omit multi-tenancy NFRs
Risk register	Include tenant data leakage risks	Omit tenant-specific risks

Android + Web vs Web-Only

Aspect	Android + Web	Web-Only
SRS scope	Include mobile NFRs (offline, app store)	Web NFRs only
SDP	Include Android build pipeline	Web pipeline only
SCMP	Include Gradle + PHP configs	PHP configs only
QA Plan	Include Android testing (Compose UI, JUnit 5)	Web testing only
Risk Plan	Include app store rejection risks	Omit mobile risks

MVP vs Full Product

Aspect	MVP	Full Product
Vision scope	P0 features only	P0 + P1 + P2 features
SDP phases	2-3 phases	5-8 phases
SRS depth	Core modules only	All modules
Feasibility	Focus on technical + economic	All five feasibility types
Risk register	Top 10 risks	Comprehensive (20-30 risks)

Output Structure

When generating documents for a project, create this structure:

docs/planning/
├── 01-feasibility-study.md
├── 02-project-vision-scope.md
├── 03-software-requirements-spec.md
├── 03-srs/
│   ├── functional-requirements.md
│   ├── non-functional-requirements.md
│   └── traceability-matrix.md
├── 04-software-development-plan.md
├── 05-configuration-management-plan.md
├── 06-quality-assurance-plan.md
└── 07-risk-management-plan.md

Each file must stay under 500 lines. Split into subdirectories as needed.

Quality Checklist

Run after generating all documents:

Anti-Patterns (What NOT to Do)

Anti-Pattern	Why It Fails	Do This Instead
Skip feasibility, jump to coding	Wastes resources on unviable projects	Always do feasibility first
Copy-paste generic templates	Documents don't match your project	Customize every section to your context
Write SRS without stakeholder input	Requirements will be wrong	Use `project-requirements` skill first
No measurable success metrics	Can't tell if project succeeded	Define KPIs with specific numeric targets
Ignore multi-tenant requirements	Data leakage between tenants	Always include NFR-MT requirements
One massive document	Exceeds 500-line limit, hard to maintain	Split into index + sub-files
No risk register	Risks become surprises	Pre-populate with common SaaS risks
Skip configuration management	Deployment chaos, lost changes	Document branching, releases, migrations
Write plans and never update them	Plans become stale and useless	Review and update at each phase gate

Template Files

Each template provides the complete structure, section-by-section guidance, example excerpts, anti-patterns, and a quality checklist.

Back to: Skills Repository Related: project-requirements | feature-planning | android-saas-planning Last Updated: 2026-02-20

sdlc-planning