Sdlc Skill

---
name: sdlc-6f4e28999cd5
description: "Route a task to the next synced SDLC workflow based on current artifacts and repo state."
metadata:
  internal: true
  triggers:
    keywords:
    - sdlc
    - workflow
---
# Sdlc Skill

> [!IMPORTANT]
> Route a task to the next synced SDLC workflow based on current artifacts and repo state.

Optional args: slug=<feature>, ticket=<id/url>, mode=interactive|autonomous|channel, channel=<id>, auto_continue=true|false, profile=business|hybrid|technical.

## Instructions

When the user asks to perform this workflow, execute the following steps:

# SDLC Router Workflow
Goal: Select the next native workflow without loading every workflow body, while preserving a traceable BA -> PM -> IT Department handoff for offshore delivery.
## Steps
1. Inspect state:
   - User request; infer `operator_profile` (business | hybrid | technical) per `common-operator-profile` and carry it in every Handoff Payload.
   - Search for the requested task's linked brief/ticket using its stable slug; do not select an unrelated newest document or infer task authority/approval from `git status`. If no matching approved task record exists, identify the missing authority/input and route to the appropriate intake. Slug = lowercase kebab-case, minted once at `brainstorm-feature`, reused verbatim downstream; never re-derived.
   - If multiple candidates exist, list them and ask whether to focus, consolidate, or sequence.
   - Baseline reference: `common-software-requirements/references/requirements-standards-baseline.md` (ships with the skill)
   - Existing ticket, BRD-lite brief, PRD, SRS/FRS design, implementation plan, task list, walkthrough, UAT signoff, deployment report, release notes, and retro
   - Jira, ADO, Zephyr, or other MCP context when already configured
   - Changed files and current test status
   - Offshore delivery context: business owner, product owner, implementation owners, QA owner, timezone/cadence constraints, environments, release window, and dependency teams
   - Requirement trace health: `BRD-OBJ-* -> REQ-* -> AC-* -> SRS-* -> test evidence`
   - SNC tier per `common-task-complexity-routing` or the scout `SNC:` line; label as inference until scouted.

2. Choose next workflow (apply tie-break order: (1) explicit operator request or latest approved/recommended stage unless safety prerequisite blocks affected scope, (2) urgent task-linked production harm/incident -> `incident-hotfix` first, even if product learning stale; do not load unrelated incident as task context, (3) earliest missing required decision or task-linked authority/input—not a missing filename—except sufficiently specified low-risk maintenance with approved evidence; reused approved context skips rediscovery, (4) cross-cutting audits only on request or as a pre-release gate):
   - Unclear idea, missing business case, owner, or measurable value (Why lane), or unclear technical direction without BRD/PRD (Direction lane; exempts routine low-risk maintenance) -> `brainstorm-feature`
   - Task-linked unmet customer-evidence/problem/market gap that the decision depends on -> `discover-product` (when selected/installed; else `brainstorm-feature` with capability gap)
   - Material unresolved critical value hypothesis or assumption needing empirical test -> `validate-product` (when selected/installed; else `plan-feature` with capability gap)
   - BRD-lite exists or business direction clear but product scope, priorities, ACs, rollout, delivery plan unclear -> `plan-feature` (explicitly loads `product-management/product-requirements` and on-demand `references/requirements-modeling.md`)
   - Scale, topology, capacity, or store choice unsettled, or existing system needs architecture audit -> `system-design-session`
   - PRD exists but technical behavior/contracts unclear (SRS/FRS / How), or auth/trust-boundary/sensitive validation needed -> `design-solution`
   - Architecture, compliance controls, or agent/runtime safety need deeper technical validation -> `design-solution`
   - BRD-lite, PRD, or SRS/FRS exists but readiness/change impact unclear -> `implementation-readiness`
   - Approved plan with trace and testable ACs, or approved low-risk maintenance contract, needs code -> `implement-feature`
   - Production incident or urgent regression -> `incident-hotfix`
   - Control-band breach or scheduled security-scan result needs tiered diagnosis -> `monitor-respond`
   - Bug ticket needs fix (non-urgent) -> `dev-fix`
   - Ticket or cross-functional change needs specialist fanout, AC coverage, and PR metadata review -> `review-ticket`
   - Design arrives as an artifact (diagram, doc, board export, IaC) and needs review -> `review-system-design`
   - PR diff needs focused merge-risk review -> `code-review`
   - Implementation GREEN but ACs lack executable E2E/mobile coverage, or an E2E suite is red after a previously green slice -> `test-loop`.
   - Code complete but unproven -> `verify-work`
   - Fix implemented and ticket has a UAT/Jira flow -> `verify-bug`
   - `verify-work` PASS on a feature, business acceptance not yet granted -> `uat-signoff`
   - Business acceptance granted and release window open -> `deploy-release`
   - Post-release observation window open, registered metric review, or value evaluation -> `review-product-value` (when selected/installed; else `publish-notes` with capability gap)
   - Deployed and needs user-facing communication -> `publish-notes`
   - Trace health unknown before release or handoff -> `traceability-audit`
   - Session ending with unfinished work or context handoff -> `session-report`
   - Deployed or communicated, capture standards/process lessons -> `retro-learn`
   - Repo-wide health/debt question with no single feature in scope -> `codebase-review`
3. Enforce handoff quality:
   - Governed/high-risk delivery requires full traceability: BA output links business objectives; PM links requirements/ACs in `docs/prd/`; IT handoff defines architecture in `docs/srs/`.
   - Low-risk maintenance exception: Sufficiently specified routine fixes/maintenance with approved in-chat/brief contract route directly to `dev-fix` or `implement-feature` without creating separate BRD/PRD/SRS files or restarting intake; never waives behavioral ACs, owner, approval, scope fence, or verification lane. Negative or inconclusive product evidence requires no-build, pivot, or bounded learning—never unconditional full build.
   - Reopen affected scope only: A stale or disputed decision blocks only its consuming action; unaffected approved decisions and independent scopes remain reusable without global reset.
   - Downstream specialist workers execute against assigned briefs and must not reload or repeat parent intake.
   - Sensitive-change risk floor: Changes touching auth, payments, data integrity, secrets, or trust boundaries enforce minimum `tier=medium` (or `tier=high`), requiring `design-solution` and human approval before coding.
   - Change impact & scope gaps: Changing requirements review affected ACs, contracts, approvals, and evidence without reopening settled decisions; product scope gaps route to planning and technical contract uncertainty routes to design.
   - Keep payloads runtime-neutral; adapters may map them to task boards, MCP, Jira, GitHub, ADO, Zephyr, or local files.
4. Set runtime state:
   - Interactive: ask max 3 blocking questions.
   - Autonomous/channel: continue only when required artifacts and owners are known; otherwise return BLOCKED.
   - Emit next workflow, handoff payload, verification command, and owner.
   - Tier drives autonomy: low -> autonomous + `fast` review; medium -> TDD + self-review + `deep` review; high -> plan-first HARD STOP, independent reviewers, human merge approval.
## Runtime Contract
- Use to select the next workflow without loading every workflow body.
- Required inputs: user request plus repo/artifact state.
- Return BLOCKED only in autonomous/channel mode when required artifacts or owners are unknown.
## Handoff Payload
- `slug`, `operator_profile`, `snc_tier`, `model_tier`, recommended workflow, requirement layer, handoff owner, required input, blocking gaps, offshore delivery notes.
## Blocking Questions
- Ask max 3 at a time with a recommended default and 2-3 options.
## Output Template
```md
# SDLC Route
## Recommended Workflow
## Requirement Layer
## Handoff Owner
## Required Input
## Blocking Gaps
## Offshore Delivery Notes
## Outcome Report
{schema_version: 1, run_id: "[run-id]", slug: "[slug]", workflow: sdlc, feature_status: not_started, started_at: "[timestamp]", completed_at: "[timestamp]", requirement_trace: {brd_objectives: [], requirements: [], acceptance_criteria: [], srs: []}, completed_evidence: [], missing_evidence: [], decision_needed: [], recommended_next_workflow: brainstorm-feature, cost: {source: unavailable}, agent: {identity: "[agent-identity]", model: "[model]"}}
## Next Workflow
## Verification Command
## Cost Report
Call `get_session_cost(workflow="sdlc")` before final handoff.
```