sdlc-team

name	sdlc-team
description	Coordinate AI-assisted software delivery through one Project Manager, a Product Owner, Architect, Developer, Tester, and Operations role. Use when a product objective, feature, migration, or release needs Stage-Gated planning, role handoffs, independent evidence review, and explicit human approval boundaries.
license	Apache-2.0

SDLC Team

Operating Model

Keep exactly one Project Manager as the project-facing coordinator. Treat Product Owner as the product-value authority, not a second PM.

Route work through:

1. Sprint Framing & Delivery Readiness — Owner: Project Manager; Gatekeeper: Product Owner.
2. Product Contract — Owner: Product Owner; Gatekeeper: Architect.
3. Architecture & Domain Contract — Owner: Architect; Gatekeeper: Developer.
4. Build & Developer Verification — Owner: Developer; Gatekeeper: Tester.
5. Independent Quality Verification — Owner: Tester; Gatekeeper: Operations.
6. Staging & Operability — Owner: Operations; Gatekeeper: Project Manager.
7. Integrated Sprint Acceptance & Learning — Owner: Project Manager; Gatekeeper: human owner.

Use only PASS, PASS WITH CONDITIONS, REWORK, or BLOCKED. Never let a role approve its own Stage.

Required Inputs

• product objective and target user outcome;
• repository or delivery context;
• constraints, exclusions, deadlines, and available roles;
• evidence expected at acceptance;
• environment, security, privacy, cost, and production boundaries;
• decisions reserved for the human owner.

If a decision-critical input is unavailable, expose the gap and mark the affected work BLOCKED.

When Not To Use

• Do not use the full lifecycle for a trivial, isolated edit that needs only one role and one check.
• Do not use it to bypass repository rules, approvals, or specialist judgment.
• Do not use Stage documents as substitutes for code inspection, executed tests, deployment evidence, or user evidence.
• Do not invoke every role when risk and scope justify a smaller role set.
• Do not use it to contact external people, spend money, use production credentials, or release to production without authorization.

Step-by-Step Execution

1. State one primary delivery outcome and observable acceptance evidence.
2. Identify the current Stage instead of restarting the lifecycle automatically.
3. Select the minimum roles required by scope and risk.
4. Record committed, stretch, and excluded scope.
5. Assign one Stage Owner and the next-stage Gatekeeper.
6. Issue a Task Packet with inputs, constraints, deliverables, evidence, and reserved decisions.
7. Require the Stage Owner to execute the work and return an Evidence Package.
8. Record material specialist-skill use only when it closes an evidence gap.
9. Ask the Gatekeeper to review evidence independently.
10. Record one valid Gate verdict, conditions, residual risks, and next action.
11. Reopen an earlier Gate when downstream evidence invalidates it.
12. Capture a Stage Learning Note and merge reusable improvements into one canonical change record.
13. At Sprint acceptance, separate completed, conditional, carried-over, blocked, and rejected work.
14. Escalate changes to authority, Gate ownership, production, privacy, security, legal, or material cost.

Output Template

# Delivery Control

## Objective
- Primary outcome:
- Observable acceptance evidence:
- Current Stage:

## Scope
- Committed:
- Stretch:
- Excluded:

## Role And Gate Map
| Stage | Owner | Gatekeeper | Status |
|---|---|---|---|

## Evidence
- Deliverables:
- Checks actually run:
- Deviations:
- Residual risks:

## Gate Decision
- Verdict:
- Conditions:
- Next action:

## Human Decision Required
- Decision:
- Evidence:
- Reversible options:

## Learning
- Stage finding:
- Project-only or reusable:
- Verification point:

Quality Gate

Pass this skill's output only when:

• there is exactly one Project Manager and Product Owner is not described as a second PM;
• one primary outcome and explicit excluded scope are visible;
• each active Stage has one Owner and a different Gatekeeper;
• every completion claim points to actual evidence;
• unrun checks are labelled not run, never passed;
• conditions have an owner and follow-up;
• dissent, deviations, residual risk, and blockers remain visible;
• human-reserved decisions are separated from autonomous work;
• process changes include a later effectiveness check.