Sdlc

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 6f5be687a268 · 14 Oct 2026Report an issue or request a re-scan

• PublisherHoangNguyen0403 GitHub userOwner of the repository this skill is read from
• Source folderHoangNguyen0403/agent-skills-standard/.codex/skills/sdlcThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict6f5be687a268A new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Route a task to the next synced SDLC workflow based on current artifacts and repo state.

---
name: sdlc
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 when multiple bullets match: (1) workflow explicitly named by the operator or latest `recommended_next_workflow`, (2) production-incident/urgent-regression signals, (3) earliest missing required decision or task-linked authority/input—not a missing document filename—except sufficiently specified low-risk maintenance with approved evidence, (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`
   - BRD-lite exists or business direction clear but product scope, priorities, ACs, rollout, delivery plan unclear -> `plan-feature` (explicitly loads `common-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`
   - 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`
   - 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.
   - 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 plann

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/HoangNguyen0403/agent-skills-standard
git -C agent-skills-standard checkout 6f5be687a268

Works in

1. 2026-10-14
   ✓SAFE B 89 / 100

   first audit · source 6f5be687a268

Questions about Sdlc

• github.com/HoangNguyen0403/agent-skills-standard/tree/develop/.c — the audited source at commit 6f5be687a268 and every finding aboveObserved · 14 Oct 2026

Spotted something wrong? Report a correction · Methodology