Automates task routing for the SDLC process. Checks project documentation and repo state to determine the next workflow step.
Install
mkdir -p .claude/skills/sdlc && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17467" && unzip -o skill.zip -d .claude/skills/sdlc && rm skill.zipInstalls to .claude/skills/sdlc
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Route a task to the next synced SDLC workflow based on current artifacts and repo state.Key capabilities
- →Inspect current artifacts and repository state.
- →Infer operator profile (business, hybrid, technical).
- →Search for matching feature slugs in documentation.
- →Choose the next SDLC workflow based on existing artifacts and gaps.
- →Enforce handoff quality for business, product, and IT department outputs.
- →Set runtime state for interactive or autonomous modes.
How it works
This skill inspects the current state of artifacts and the repository, then chooses the next appropriate SDLC workflow based on predefined rules and the presence of required documentation.
Inputs & outputs
When to use sdlc
- →Determining the next step in a feature workflow
- →Validating project requirement trace health
- →Handing off tasks from planning to implementation
About this skill
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
-
Inspect state:
- User request; infer
operator_profile(business | hybrid | technical) percommon-operator-profileand carry it in every Handoff Payload. - Search
docs/brd/,docs/prd/, anddocs/srs/for a matching[slug]; if absent, use the newest BRD orgit status. Slug = lowercase kebab-case, minted once atbrainstorm-feature, reused verbatim downstream; never re-derived. - If multiple candidates exist, list them and ask whether to focus, consolidate, or sequence.
- Baseline reference:
docs/requirements-standards-baseline.md - 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
- User request; infer
-
Choose next workflow (apply tie-break order when multiple bullets match: (1) workflow explicitly named by the operator or by the latest
recommended_next_workflow, (2) production-incident/urgent-regression signals, (3) earliest missing artifact along the chain below — never skip forward past a gap, (4) cross-cutting audits only on request or as a pre-release gate):- Unclear idea, missing business case, missing stakeholder owner, or missing measurable value (BRD-lite / Why, BA-owned intake) ->
brainstorm-feature - BRD-lite exists or business direction is clear but product scope, priorities, acceptance criteria, rollout, or delivery plan are unclear (PRD / What, PM-owned planning) ->
plan-feature - PRD exists but technical behavior/contracts unclear (SRS/FRS / How) ->
design-solution - Architecture, auth, trust boundaries, compliance controls, or agent/runtime safety need deeper technical validation ->
design-solution - BRD-lite, PRD, or SRS/FRS exists but readiness unclear ->
implementation-readiness - Approved plan with BRD/PRD/SRS trace and testable ACs needs code ->
implement-feature - Production incident or urgent regression ->
incident-hotfix - Bug ticket needs fix (non-urgent) ->
dev-fix - Ticket or cross-functional change needs specialist fanout, AC coverage, and PR metadata review ->
review-ticket - PR diff needs focused merge-risk review ->
code-review - Code complete but unproven ->
verify-work - Fix implemented and ticket has a UAT/Jira flow ->
verify-bug verify-workPASS 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
- Unclear idea, missing business case, missing stakeholder owner, or missing measurable value (BRD-lite / Why, BA-owned intake) ->
-
Enforce handoff quality:
- BA output must include business objective, stakeholder/validation owner, AS-IS/TO-BE, SMART metric, scope fence, risks, assumptions, and BRD objective IDs.
- PM output must link each PRD requirement and AC to a BRD objective, name requirement owners/status/priority, define rollout/ops, and identify whether
design-solutionis required. - IT Department handoff must include implementation owner candidates, affected repos/modules, test lanes, environments, release/rollback notes, and open blockers.
- Never route directly to implementation when BRD/PRD/SRS trace, owner, or testable ACs are missing; route to BA/PM/design first.
- This applies even when the request explicitly says "implement" or names a specific feature/module: if
docs/brd/anddocs/prd/have no matching[slug]for it yet, the FIRST slice dispatched must be abrainstorm-featureorplan-featureintake slice (ownerba-agent/pm-agent) — never animplementation-readiness/design-solution/implement-featureslice as slice-01. Missing repo roots, OAuth/client IDs, or session-policy decisions are a sign the BRD/PRD step was skipped, not questions to resolve inline in an implementation slice. - Keep payloads runtime-neutral; adapters may map them to task boards, MCP, Jira, GitHub, ADO, Zephyr, or local files.
-
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.
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, 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
# SDLC Route
## Recommended Workflow
## Requirement Layer
## Handoff Owner
## Required Input
## Blocking Gaps
## Offshore Delivery Notes
## Outcome Report
feature_status: not_started | requirements_ready | design_ready | partially_implemented | implemented | blocked
requirement_trace: BRD-OBJ-* -> REQ-* -> AC-* -> SRS-* -> evidence
completed_evidence: []; missing_evidence: []; decision_needed: []; recommended_next_workflow:
## Next Workflow
## Verification Command
## Cost Report
Call `get_session_cost(workflow="sdlc")` before final handoff.
When not to use it
- →Never route directly to implementation when BRD/PRD/SRS trace, owner, or testable ACs are missing.
- →Do not resolve missing repo roots, OAuth/client IDs, or session-policy decisions inline in an implementation slice.
- →Do not skip forward past a gap in the artifact chain.
Limitations
- →The skill will return BLOCKED in autonomous/channel mode if required artifacts or owners are unknown.
- →It asks a maximum of 3 blocking questions in interactive mode.
- →It does not route directly to implementation if key documentation or traceability is missing.
How it compares
This skill automates the routing of tasks through the SDLC by evaluating existing artifacts and enforcing handoff quality, providing a traceable and structured progression compared to manual task assignment.
Compared to similar skills
sdlc side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| sdlc (this skill) | 0 | 23d | No flags | Advanced |
| ble | 0 | 2mo | Caution | Intermediate |
| team-routing | 1 | 6mo | Review | Intermediate |
| azure-devops-queries | 0 | 2mo | Caution | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by HoangNguyen0403
View all by HoangNguyen0403 →You might also like
ble
mozilla
Run Base Load Engineer checks for the current day and produce a prioritized action list
team-routing
WellApp-ai
Detect domain from context and find appropriate team member
azure-devops-queries
gonzalezpazmonica
Usar cuando se necesitan consultas WIQL, actualización de work items o datos de sprint en Azure DevOps.
sunset-sequence
komunite
Yapılandırılmış süreç, kalite kontrolleri ve sistem entegrasyonu ile bir gün batımı dizisi oluşturun
archon
coleam00
Interactive Archon integration for knowledge base and project management via REST API. On first use, asks for Archon host URL. Use when searching documentation, managing projects/tasks, or querying indexed knowledge. Provides RAG-powered semantic search, website crawling, document upload, hierarchical project/task management, and document versioning. Always try Archon first for external documentation and knowledge retrieval before using other sources.
linear
lobehub
Linear issue management guide. Use when working with Linear issues, creating issues, updating status, or adding comments. Triggers on Linear issue references (LOBE-xxx), issue tracking, or project management tasks. Requires Linear MCP tools to be available.