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

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:

Cross-References to Existing Skills

Upstream Skills (use BEFORE this skill)

Parallel Skills (use ALONGSIDE this skill)

Downstream Skills (use AFTER this skill)

Future skills to add (identified from ISO/IEC 14764-2006): Software Maintenance Plan (Corrective/Adaptive/Perfective/Preventive maintenance types) and Post-Deployment Evaluation Report are not yet implemented as skills but should be generated at project close.

Available SDLC Skills

Available SDLC Skills (continued)

Adaptation Rules

SaaS vs Standalone

Android + Web vs Web-Only

MVP vs Full Product

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.

Phase Gate Exit Criteria

Every project passes through six risk-based milestones (Disciplined Agile, 2020). Each milestone has mandatory exit criteria verified before proceeding. These map to the six DA milestones.

Anti-pattern: Advancing to the next gate without resolving all tags from the current gate propagates defects downstream. One unresolved [V&V-FAIL] at G3 typically generates 5–10 downstream rework items.

Quality Checklist

Run after generating all documents:

• All 7 documents generated (or justified why one was skipped)
• Each document stays under 500 lines (split if needed)
• Vision & Scope has measurable success metrics with numeric targets
• SRS has numbered requirement IDs (FR-MOD-001, NFR-PERF-001)
• SRS Section 1.2 includes an explicit ## Out of Scope subsection
• Every NFR is SMART: Specific, Measurable, Achievable, Relevant, Time-bound — flag [V&V-FAIL: SMART metric not defined] for any that are not
• Every SHALL requirement has an inline acceptance stub: **Acceptance:** Given [state], When [action], Then [outcome]
• Requirements are prioritized using MoSCoW; time-sensitive features additionally scored with Cost of Delay
• SDP references the correct tech stack with version numbers
• SCMP describes the actual Git branching strategy being used
• QA Plan references vibe-security-skill for security quality gates
• Risk Register includes at least 8 pre-populated SaaS-specific risks
• Feasibility Study ends with a clear Go/No-Go/Conditional recommendation
• All documents cross-reference each other where relevant
• Multi-tenant isolation addressed in SRS, QA Plan, and Risk Plan
• Deployment environments (Windows dev, Ubuntu staging, Debian prod) documented in SDP
• No vague language ("user-friendly", "fast", "secure") -- all measurable
• Examples are tailored to the project's actual tech stack and domain

Anti-Patterns (What NOT to Do)

Template Files

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

1. Project Vision & Scope
2. Software Development Plan
3. Configuration Management Plan
4. Quality Assurance Plan
5. Risk Management Plan
6. Software Requirements Specification
7. Feasibility Study Report

Back to: Skills Repository Related: project-requirements | feature-planning | android-saas-planning Last Updated: 2026-03-15 (strengthened per Adjei 2023, Winston, Etter 2016, Cone 2023)