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

• 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.

• 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.

• 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.

• 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.

• 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.

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

• 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.

• Use the

  templates/

  directory when the task needs a structured deliverable.

1. Load

   world-class-engineering

   .
2. Load this skill to define the planning baseline and phase-entry gates.
3. Pair it with

   engineering-management-system

   ,

   advanced-testing-strategy

   , and

   deployment-release-engineering

   when the plan must be executable.

• 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

• 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)

• 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

mobile-saas-planning

multi-tenant-saas-architecture

modular-saas-architecture

saas-seeder

sdlc-design

sdlc-testing

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.

• 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

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

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