Platform Notes

Optional helper plugins may help in some environments, but they must not be treated as required for this skill.

SDLC Planning Skill

Use When

Generate Planning & Management documentation for SDLC projects. Covers Project Vision & Scope, SDP, SCMP, QA Plan, Risk Plan, SRS, and Feasibility Study. Use when starting a new project, conducting project governance, or establishing the planning...
The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.

Do Not Use When

The task is unrelated to
```
sdlc-planning
```
or would be better handled by a more specific companion skill.
The request only needs a trivial answer and none of this skill's constraints or references materially help.

Required Inputs

Gather relevant project context, constraints, and the concrete problem to solve; load
```
templates
```
only as needed.
Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.

Workflow

Read this
```
SKILL.md
```
first, then load only the referenced deep-dive files that are necessary for the task.
Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.

Quality Standards

Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
Prefer deterministic, reviewable steps over vague advice or tool-specific magic.

Anti-Patterns

Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
Loading every reference file by default instead of using progressive disclosure.

Outputs

A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
References used, companion skills, or follow-up actions when they materially improve execution.

Evidence Produced

Category	Artifact	Format	Example
Release evidence	SDLC planning document set	Markdown docs covering Project Vision & Scope, SDP, SCMP, QA Plan, and Risk Plan	`docs/sdlc/planning-2026-04-16.md`

References

Use the
```
templates/
```
directory when the task needs a structured deliverable.

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.

Load Order

Load
```
world-class-engineering
```
.
Load this skill to define the planning baseline and phase-entry gates.

Pair it with

engineering-management-system

advanced-testing-strategy

, and

deployment-release-engineering

when the plan must be executable.

Executable Planning Standard

Planning documents must define more than scope. They must define:

critical flows and risk class
measurable success criteria and service expectations
delivery slices and release assumptions
testing, observability, and rollback expectations
ownership for decisions, operations, and follow-up

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
```
mobile-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


templates/project-vision-scope.md
templates/software-development-plan.md
templates/configuration-management-plan.md
templates/quality-assurance-plan.md
templates/risk-management-plan.md
templates/software-requirements-spec.md
templates/feasibility-study-report.md

#	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
`mobile-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.
`sdlc-design`	Design documentation phase. Uses approved SRS as primary input.
`sdlc-testing`	Testing documentation. Uses SRS requirement IDs for test case traceability.

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

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.

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.

Gate	DA Milestone	Triggered By	Exit Criteria
G1	Stakeholder Vision	End of Skill 01–03	Vision documented; stakeholder register complete; scope agreed with Out of Scope listed; domain confirmed
G2	Proven Architecture	End of Skill 04	Interface spec complete; architecture strategy selected; key risks identified; no unresolved [CONTEXT-GAP] tags
G3	Requirements Complete	End of Skill 05	All FRs have GWT stubs; all NFRs have SMART metrics; every FR traced to business goal; zero [V&V-FAIL] tags
G4	Logic Validated	End of Skill 06–07	All LaTeX formulas verified; attribute mapping complete; no conflicts in Section 3.4
G5	Audit Passed	End of Skill 08	Zero [V&V-FAIL], [GLOSSARY-GAP], [TRACE-GAP], [SMART-FAIL] tags; SRS approved by consultant
G6	Production Ready	Post-testing	Test plan complete; no open must-fix defects; Go/No-Go approved in phase exit meeting

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
Release, rollback, and post-deploy observation assumptions are documented in the plan set
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)

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
Omit Out of Scope section from SRS	Scope creep is invisible	SRS Section 1.2 must include explicit `## Out of Scope` subsection
Vague NFRs without SMART metrics	Cannot verify or test non-functional requirements	Each NFR must be Specific, Measurable, Achievable, Relevant, Time-bound
No Given-When-Then acceptance stubs	Requirements written without verification linkage	Add inline `Acceptance: Given [state], When [action], Then [outcome]` to every SHALL requirement
Prioritize only by gut feel	High-value work delayed; delivery misaligned with business	Use Cost of Delay (CoD) for time-sensitive requirements alongside MoSCoW

Template Files

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

Project Vision & Scope
Software Development Plan
Configuration Management Plan
Quality Assurance Plan
Risk Management Plan
Software Requirements Specification
Feasibility Study Report

References

../sdlc-lifecycle.md: Shared SDLC execution model and lifecycle gates.

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

sdlc-planning

NPX Install

Tags

SKILL.md Content

Platform Notes

SDLC Planning Skill

Use When

Do Not Use When

Required Inputs

Workflow

Quality Standards

Anti-Patterns

Outputs

Evidence Produced

References

Load Order

Executable Planning Standard

When to Use

When NOT to Use

Document Inventory

Generation Workflow

Prerequisites

Cross-References to Existing Skills

Upstream Skills (use BEFORE this skill)

Parallel Skills (use ALONGSIDE this skill)

Downstream Skills (use AFTER this skill)

Available SDLC Skills

Available SDLC Skills (continued)

Adaptation Rules

SaaS vs Standalone

Android + Web vs Web-Only

MVP vs Full Product

Output Structure

Phase Gate Exit Criteria

Quality Checklist

Anti-Patterns (What NOT to Do)

Template Files

References