Sdlc

Skill shaunczubkowski/claude-skills/sdlc

Reusable Claude Code skills for agentic software development workflows.

Install

npx -y skills add shaunczubkowski/claude-skills --skill sdlc

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

3 things to look at

14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Full agentic SDLC orchestrator — implement, branch, PR, wave-based code review, fix, merge. Reads per-project .claude/sdlc-config.md for agents, waves, and gates. Invoke as /sdlc <task>, /sdlc --review, /sdlc --fix, or /sdlc --merge.

SKILL.md

9.4 KB, as published. Nobody here has run it

SDLC Orchestrator Skill

This skill drives the full development lifecycle from task description to merged PR. It is project-agnostic: all project-specific configuration (agents, waves, gates) is loaded from .claude/sdlc-config.md in the working directory.

Step 0 — Boot (always first)

Before doing anything else:

Read .claude/sdlc-config.md. If the file is missing, stop and tell the user: "No .claude/sdlc-config.md found. Create one using the template at the top of the sdlc skill before proceeding."
Parse the config into three structures:
- Agents map — name → role + file path
- Waves list — ordered array of { wave, agents[], isHardGate } (hard-gate waves block on any failure before the next wave starts)
- Merge requirements — per-agent rules (explicit APPROVED comment, test suite pass, no open blockers, etc.)
Parse any conditional-agent rules (e.g., bob is required only when certain file paths are touched).
Store these in working context — all subsequent steps reference them.

Then branch based on the invocation flag:

/sdlc <task> → proceed to Phase 1
/sdlc --review → jump to Phase 3 (PR already open)
/sdlc --fix → jump to Phase 4 (findings already in context)
/sdlc --merge → jump to Phase 6

Phase 1 — Plan & Implement

1.1 Plan

Enter plan mode (EnterPlanMode). Produce a concise implementation plan:

What files will be created or modified
What the key logic changes are
Which conditional agents are triggered (check file paths in the plan against conditional rules in the config)

Present the plan to the founder. Do not proceed until they approve.

1.2 Implement

Exit plan mode (ExitPlanMode). Execute the approved plan:

Write the code
Run type-check and lint (npm run typecheck && npm run lint or project equivalent) — fix all errors before proceeding
Run unit tests (npm test or equivalent) — fix any test failures

Commit all changes. Commit message format: conventional commits (feat:, fix:, chore:, etc.).

Phase 2 — Branch & PR

2.1 Branch

If not already on a feature branch:

git checkout -b feat/<slug>

where <slug> is a kebab-case summary of the task (≤5 words).

2.2 Push

git push -u origin feat/<slug>

2.3 Open PR

gh pr create --base main --title "<title>" --body "<body>"

The PR body must include:

A Summary section (2–4 bullet points)
An Engineers table listing every contributor: | Name | Role | Contribution |
A Test plan checklist
The conditional agents triggered (if any), listed under Domain gates
The standard footer: 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Capture the PR URL. All subsequent gh pr comment calls use this PR.

Phase 3 — Wave Review Loop

Repeat for each wave in the config's wave list:

3.1 Identify active agents for this wave

Start with all agents listed for this wave. Remove any conditional agents that aren't triggered by this PR's changed files. If a wave has no active agents after filtering, skip it.

3.2 Dispatch agents in parallel

Use the Agent tool to dispatch all active agents in this wave simultaneously (single message with multiple Agent tool calls). Each agent gets a self-contained prompt that includes:

The PR URL and branch name
The changed file list (git diff --name-only origin/main...HEAD)
Their role from the config
What they should review (their domain)
What to report: confirmed findings only, with file path + line number + severity + description
Instruction to give an explicit APPROVED or CHANGES REQUESTED verdict at the end

Agents run in background (default). Wait for all wave-N agents to complete before proceeding.

3.3 Resume dead agents

If any agent times out or goes silent, resume via SendMessage(agentId, ...) — do NOT cold-relaunch with a new Agent call. A cold relaunch loses the agent's context. Resume once; if the agent is unresponsive after a second attempt, surface the blocker to the founder.

3.4 Collect findings

Once all wave-N agents have responded, compile:

All confirmed findings across agents (file, line, severity, description)
Each agent's verdict (APPROVED / CHANGES REQUESTED)
Any hard-gate failures (wave is marked hard gate in config)

3.5 Hard gate check

If this wave is a hard gate AND any agent gave CHANGES REQUESTED:

Stop the wave loop
Surface a blockers list to the founder: [AgentName]: <brief summary of blocking finding>
Do NOT proceed to the next wave
Do NOT start fixes without founder acknowledgement
After founder acknowledges, proceed to Phase 4 for just these blockers, then re-run this wave

If no hard gate failures (or wave is not a hard gate), proceed directly to Phase 4 for this wave's findings, then continue to the next wave.

Phase 4 — Fix & Push

4.1 Fix all confirmed findings

Work through every confirmed finding from the current wave:

Apply the fix
Re-run type-check and lint
Re-run affected tests

If a finding is out of scope or intentionally deferred, note it — you'll acknowledge it in the response comment.

4.2 Commit and push

Group all fixes into a single commit (or one per reviewer if changes are clearly separable):

fix(review): address <Wave N> findings — <AgentName>[, <AgentName>...]

Push to the feature branch:

git push

Phase 5 — Response Comments

For each reviewer in the current wave, post exactly one gh pr comment with this format:

**[AgentName] — [ADDRESSED / ACKNOWLEDGED / DEFERRED]**

- Finding 1 (file:line): Fixed — <one sentence on what changed>
- Finding 2 (file:line): Acknowledged — <reason it wasn't changed>
- Finding 3 (file:line): Deferred — <rationale, links to issue if created>

Rules:

One comment per reviewer, not one per finding
Use the reviewer's actual name from the config (not their role)
Mark as ADDRESSED if all findings were fixed, ACKNOWLEDGED if some were intentionally skipped, DEFERRED if punted to a follow-up issue
Create a GitHub issue for any deferred non-trivial finding (label follow-up)

After posting all response comments, return to Phase 3 to start the next wave (if any remain).

Phase 6 — Gate Verification & Merge

6.1 Verify all merge requirements

Check each requirement from the config's merge requirements section:

Requirement type	How to verify
explicit APPROVED comment	`gh pr view --comments` — scan for the agent's name + APPROVED
test suite green	Finn's review or CI status — `gh pr checks`
no blocking findings open	Review response comments — confirm all CHANGES REQUESTED items were addressed

Build a gate status table:

| Gate      | Status  | Notes |
|-----------|---------|-------|
| vesper    | PASSED  | Explicit APPROVED in comment #42 |
| finn      | PASSED  | All tests green (Jest + Playwright) |
| bob       | N/A     | Conditional — not triggered |
| sage      | PASSED  | No blocking findings |
| kit       | PASSED  | No blocking findings |
| rael      | PASSED  | No blocking findings |
| mara      | PASSED  | No blocking findings |
| dex       | PASSED  | No blocking findings |

6.2 Surface unresolved gates

If any required gate has not PASSED, stop and present the table to the founder with failed gates highlighted. Do not merge. Ask the founder how to proceed with each failed gate.

6.3 Merge

Once all gates PASSED:

gh pr merge <PR-URL> --squash --delete-branch

Confirm the merge completed. Report the merged commit SHA to the founder.

Error & Edge Cases

"I don't know what task to do" — /sdlc with no args or with --review/--fix/--merge flags assumes context is already in the session. If context is missing, ask the founder for the PR URL or task description before proceeding.

Config parsing fails — Stop immediately. Show the founder the line(s) that failed to parse and ask them to correct the config. Do not guess at intent.

Agent finds a critical security issue — Even if not a hard-gate wave, any finding marked CRITICAL or SEVERITY: HIGH by Vesper is treated as a hard gate. Stop, surface to founder, do not proceed.

Tests fail after fixes — Do not push broken code. Fix the regression before continuing. If fixing the regression requires scope expansion, tell the founder and get approval.

PR already has merge conflicts — Rebase onto main before proceeding: git fetch origin && git rebase origin/main. Resolve conflicts. Push with force-with-lease: git push --force-with-lease.

Config Template (for new projects)

Copy this to .claude/sdlc-config.md in any new project and fill in the values:

# SDLC Config — <Project Name>

## Agents
| Name | Role | File |
|------|------|------|
| <name> | <role> | .claude/agents/<name>.md |

## Review Waves
Wave 1 (hard gates — block on fail): <agent1>, <agent2>
Wave 2 (<domain>): <agent3>, <agent4>
Wave 3 (<domain>): <agent5>, <agent6>

## Conditional Agents
<name>: required when PR touches `<path-glob>` OR files match `<pattern>`

## Merge Requirements
- <name>: explicit APPROVED comment required
- <name>: full test suite green required
- <name>: no blocking findings open