sdlc-planning（SDL 规划）

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

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

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.

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

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

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

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)