SDLC Documentation
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use this parent skill as the active SDLC documentation entrypoint. Keep the phase-specific details in references and load only the phase being authored or reviewed.
Use When
- Creating or reviewing SDLC document sets, delivery evidence, traceability, phase gates, and lifecycle handoffs.
- Consolidating planning, design, testing, deployment, user rollout, post-deployment, and maintenance documents.
- Aligning project documentation with implementation, validation, release, and support obligations.
Do Not Use When
- The task is unrelated to this parent skill or is better handled by a narrower active parent named in the workflow.
- The request only needs a trivial answer and no reference module needs to be loaded.
Required Inputs
| Artefact |
Required? |
Purpose |
| System, repository, environment, and constraints |
yes |
Ground the document in actual delivery context |
| Requested lifecycle phase and audience |
yes |
Select only the needed reference and output |
Workflow
- Load
world-class-engineering for baseline delivery quality.
- Load the needed phase reference:
references/sdlc-planning.md for project planning and initiation.references/sdlc-design.md for solution and technical design documents.references/sdlc-testing.md for test planning, evidence, and acceptance gates.references/sdlc-user-deploy.md for user rollout and adoption documents.references/sdlc-post-deployment.md for go-live review and stabilisation evidence.references/sdlc-maintenance.md for support, maintenance, and continuous improvement.
- Pair with
project-requirements, advanced-testing-strategy, deployment-release-engineering, or implementation-status-auditor when the task needs those outputs.
Quality Standards
- Every document must be tied to a decision, acceptance criterion, release gate, or operating obligation.
- Preserve traceability from requirement to design, implementation, test evidence, release, and support.
- Avoid generic SDLC text that cannot guide an implementation or audit decision.
Anti-Patterns
- Treating absorbed reference files as active skills or separate routing entrypoints.
- Loading every migrated child reference instead of the one that matches the task.
- Producing generic advice without constraints, evidence, or next verification steps.
Outputs
- SDLC document, review findings, traceability notes, phase gate checklist, or handoff package.
Evidence Produced
| Category |
Artifact |
Format |
Example |
| Correctness |
Traceability results |
Matrix |
Requirement-to-test mapping |
| Security |
Security review |
Findings register |
Unresolved authorization risk |
| Data safety |
Data-control evidence |
Checklist |
Recovery verification |
| Performance |
Performance verification |
Test record |
SLO result |
| Operability |
Operational handoff |
Runbook and checklist |
Monitoring ownership |
| UX quality |
User validation |
Acceptance record |
Accessibility result |
| Release evidence |
Release decision |
Approval record |
Signed gate outcome |
References
- Load only the references/.md files named in the workflow when their depth is required.
Decision Rules
| Condition |
Action |
| One lifecycle phase is requested |
Load only its absorbed reference |
| Evidence conflicts with an older document |
Flag and reconcile before update |
| Required operational fact is unknown |
Mark it open; do not invent it |
Capability Contract
Read and search are required. Editing and validation execution require authorisation.
Degraded Mode
Fallback: without repository evidence, return a document skeleton and open-question register.
Domain Anti-Patterns
- Copying every phase template into one document.
- Presenting planned behaviour as implemented.
- Omitting owner or acceptance evidence.
- Leaving stale cross-document contradictions.
- Inventing deployment or maintenance facts.
1---2name: sdlc-documentation3description: Use when producing, reviewing, or consolidating SDLC documentation across planning, requirements, design, testing, deployment, user rollout, post-deployment, and maintenance phases. Load absorbed SDLC phase references as needed.4---56# SDLC Documentation7Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.89Use this parent skill as the active SDLC documentation entrypoint. Keep the phase-specific details in references and load only the phase being authored or reviewed.1011<!-- dual-compat-start -->12## Use When1314- Creating or reviewing SDLC document sets, delivery evidence, traceability, phase gates, and lifecycle handoffs.15- Consolidating planning, design, testing, deployment, user rollout, post-deployment, and maintenance documents.16- Aligning project documentation with implementation, validation, release, and support obligations.1718## Do Not Use When1920- The task is unrelated to this parent skill or is better handled by a narrower active parent named in the workflow.21- The request only needs a trivial answer and no reference module needs to be loaded.2223## Required Inputs2425| Artefact | Required? | Purpose |26|---|---|---|27| System, repository, environment, and constraints | yes | Ground the document in actual delivery context |28| Requested lifecycle phase and audience | yes | Select only the needed reference and output |29## Workflow30311. Load `world-class-engineering` for baseline delivery quality.322. Load the needed phase reference:33 - `references/sdlc-planning.md` for project planning and initiation.34 - `references/sdlc-design.md` for solution and technical design documents.35 - `references/sdlc-testing.md` for test planning, evidence, and acceptance gates.36 - `references/sdlc-user-deploy.md` for user rollout and adoption documents.37 - `references/sdlc-post-deployment.md` for go-live review and stabilisation evidence.38 - `references/sdlc-maintenance.md` for support, maintenance, and continuous improvement.393. Pair with `project-requirements`, `advanced-testing-strategy`, `deployment-release-engineering`, or `implementation-status-auditor` when the task needs those outputs.4041## Quality Standards4243- Every document must be tied to a decision, acceptance criterion, release gate, or operating obligation.44- Preserve traceability from requirement to design, implementation, test evidence, release, and support.45- Avoid generic SDLC text that cannot guide an implementation or audit decision.4647## Anti-Patterns4849- Treating absorbed reference files as active skills or separate routing entrypoints.50- Loading every migrated child reference instead of the one that matches the task.51- Producing generic advice without constraints, evidence, or next verification steps.52## Outputs5354- SDLC document, review findings, traceability notes, phase gate checklist, or handoff package.5556## Evidence Produced5758| Category | Artifact | Format | Example |59|---|---|---|---|60| Correctness | Traceability results | Matrix | Requirement-to-test mapping |61| Security | Security review | Findings register | Unresolved authorization risk |62| Data safety | Data-control evidence | Checklist | Recovery verification |63| Performance | Performance verification | Test record | SLO result |64| Operability | Operational handoff | Runbook and checklist | Monitoring ownership |65| UX quality | User validation | Acceptance record | Accessibility result |66| Release evidence | Release decision | Approval record | Signed gate outcome |6768## References6970- Load only the references/<old-skill>.md files named in the workflow when their depth is required.71<!-- dual-compat-end -->7273## Decision Rules7475| Condition | Action |76|---|---|77| One lifecycle phase is requested | Load only its absorbed reference |78| Evidence conflicts with an older document | Flag and reconcile before update |79| Required operational fact is unknown | Mark it open; do not invent it |8081## Capability Contract8283Read and search are required. Editing and validation execution require authorisation.8485## Degraded Mode8687Fallback: without repository evidence, return a document skeleton and open-question register.8889## Domain Anti-Patterns9091- Copying every phase template into one document.92- Presenting planned behaviour as implemented.93- Omitting owner or acceptance evidence.94- Leaving stale cross-document contradictions.95- Inventing deployment or maintenance facts.
peterbamuhigire