SDLC Pipeline

Plugin sdlc-pipeline from marketplace claude-sdlc in DevLab-Technologies/claude-sdlc. Commands read from the repo's manifest — 1 month ago.

Skills (3)

• sdlc-digest

  How to compress a long SDLC artifact — PRD, specification, user stories, architecture, test plan, review or QA report, release record — into a short brief a human can read in minutes, in a voice that reads as written rather than generated, without losing anything they are accountable for. Read this

• sdlc-figma-design

  The Figma contract for the SDLC pipeline — how a requirement becomes a versioned Figma design, how that design is exported into the feature workspace so every downstream agent can read it without touching Figma, which artifact wins when Figma and the markdown specification disagree, and how design d

• sdlc-protocol

  The shared filesystem contract every SDLC agent must follow — where artifacts live, how agents communicate, how state and history are recorded, and the rules for issues, fix authority, sign-off, and parallel safety. Read this before doing any SDLC phase work.

Slash commands (14)

• /sdlc-pipeline:sdlc-bug

  Investigate and fix a reported defect through the root-cause path — reproduce, diagnose, fix the cause, add a regression test, verify, and sweep the blast radius.

• /sdlc-pipeline:sdlc-digest

  Turn the long pipeline artifacts — PRD, specification, stories, architecture, test plan, review and QA, release record — into short briefs a human can read in minutes, without losing any open question, risk, or blocker.

• /sdlc-pipeline:sdlc-figma-design

  Turn the requirements into a versioned Figma design — generate the frames, or import an existing Figma file — then export the whole design into the feature workspace so implementers and QA can build and check against it without Figma access.

• /sdlc-pipeline:sdlc-init

  Set up the SDLC pipeline in the current project — scaffold the workspace, install the ADR template, learn the project's conventions, and write the pipeline rules into CLAUDE.md.

• /sdlc-pipeline:sdlc-integrate

  Run the integration gate for a cross-repo program — contract conformance in both directions, cross-repo journeys, version alignment, and a deploy order that never needs simultaneous deployment.

• /sdlc-pipeline:sdlc-join

  Join this repository to a cross-repo program — read the shared specification, take this repo's slice of the work, implement it against the published contract, and run this repo's own review and QA gates.

• /sdlc-pipeline:sdlc-product

  Product-only work — takes a feature request, a PRD, or a set of user stories, reviews it through four parallel lenses for uncovered scenarios and business impact, then produces an improved specification. Stops before any design or engineering.

• /sdlc-pipeline:sdlc-program

  Start or drive a feature that spans several repositories — writes the specification once in a shared workspace, publishes versioned contracts so consumers can start immediately, then tracks each participant to the integration gate.

• /sdlc-pipeline:sdlc-resume

  Diagnose an interrupted pipeline run and continue it — reconciles state against the event log and artifacts, quarantines partial output, re-runs only what was interrupted, then hands back to the pipeline.

• /sdlc-pipeline:sdlc-review

  Run the whole review phase in one command — verify the build once, fan out five specialist lenses in parallel, then merge, deduplicate, fix mechanically, and sign off. Works inside a feature workspace or standalone on a diff, branch, or PR.

• /sdlc-pipeline:sdlc-status

  Report the state of every SDLC feature — phase, cycle, gates, open issues, investigations, unanswered questions, and what runs next.

• /sdlc-pipeline:sdlc-timing

  Report how long things actually took and what they cost — per feature, per cycle, per agent, and per individual run — computed from the duration_ms every agent records on run_complete and the tokens the orchestrator records on run_usage. Read-only.

• /sdlc-pipeline:sdlc-visualize

  Show a real feature's pipeline as the live Pipeline Floor — who has finished, who is working and on what, how long the running task has taken, what runs next, and what each agent cost. Built from history/events.jsonl and the workspace by a deterministic script, not hand-assembled.

• /sdlc-pipeline:sdlc

  Run the full SDLC pipeline for a feature — intake, research, PRD and stories, UX design, Figma design version, UX audit, architecture, implementation, review, QA, UI QA — cycling until every gate passes.

Subagents (23)

• sdlc-architect

  Owns technical design — architecture, interface contracts, ADRs, the implementation workplan, and the test strategy. Runs after the UX audit passes, and reviews implementations for architectural compliance.

• sdlc-business-analyst

  Validates the business case behind a feature — whether the problem is evidenced, who benefits and by how much, whether the success metric is real and measurable, what it costs including opportunity cost, and whether not building it is the better option. Emits local findings for the product owner to

• sdlc-code-reviewer

  Correctness and requirement-fidelity lens of the parallel review phase — reads the intent before the diff, then checks that the code does what was specified, does nothing unrequested, and is correct, well-structured, and conventional. Emits local findings for the review lead to merge. Runs concurren

• sdlc-contract-steward

  Owns the cross-repository contracts of a multi-repo program — drafts and publishes versioned boundary contracts, analyses consumer impact before a change lands, enforces breaking-change policy and compatibility windows, and detects when a repo is building against a superseded version. Use for any fe

• sdlc-debugger

  Investigates defects to root cause — reproduces, isolates, diagnoses, and proves the cause before anyone writes a fix. Use for any failing test, crash, regression, flaky behavior, production incident, or issue whose cause is not obvious. Diagnoses; does not implement the fix.

• sdlc-figma-designer

  The only agent that talks to Figma. Turns the requirements and the UX specification into a versioned Figma design, or imports an existing Figma file, then exports the whole design into the feature workspace as files every other agent can read without Figma access. Runs after the UX specification exi

• sdlc-implementer

  Implements one task from the architect's workplan, or fixes a set of assigned issues. Writes code and tests against the interface contract, records what it did, and never redefines scope. Run one instance per task; parallel tasks are declared conflict-free in the workplan.

• sdlc-intake

  First agent in the SDLC pipeline. Turns a raw feature request into a scoped brief, an explicit list of questions for the human, and recorded assumptions. Use at the start of every feature.

• sdlc-integration-qa

  Verifies what no single repository can — that a provider honors its published contract, that consumers assume only what the contract promises, that cross-repo user journeys work end to end, and that a deploy order exists which never requires simultaneous deployment. Runs after every participant pass

• sdlc-product-critic

  Adversarial product-specification reviewer — finds the user scenarios a PRD or story set never considered, the acceptance criteria that cannot be falsified, and the ambiguity that will become rework. Emits local findings for the product owner to revise against. Runs as one lens of the parallel produ

• sdlc-product-owner

  Writes the PRD and decomposes it into user stories with testable acceptance criteria and a prioritized backlog. Runs after research, and again whenever scope changes mid-cycle.

• sdlc-qa-functional

  Functional QA in two modes — authors the binding test plan from the acceptance criteria before any code exists, then later executes that approved plan against the running system, verifies fixed issues, and reports defects. Runs in phase 6 (plan) and phase 9 (execute).

• sdlc-qa-ui

  UI QA — drives the running interface, compares it against the UX specification state by state, checks responsive behavior, accessibility and console health, and reports visual and interaction defects. Runs after functional QA in every cycle.

• sdlc-release-gate

  Final arbiter. Audits the whole feature workspace against the termination criteria, decides ship / another cycle / escalate, and writes the release record. Runs at the end of every cycle.

• sdlc-researcher-constraints

  Constraints lens of the parallel research phase — the hard technical, legal, performance, compatibility, and team-convention limits the architect must treat as non-negotiable. Runs concurrently with the internal-findings and prior-art lenses.

• sdlc-researcher-findings

  Internal-code lens of the parallel research phase — searches the existing codebase for what already solves part of the request, what will conflict, and the conventions to match. Runs concurrently with the prior-art and constraints lenses. No network access needed.

• sdlc-researcher-prior-art

  External prior-art lens of the parallel research phase — how comparable products solve this user problem, and which interaction or structural ideas are worth borrowing. Runs concurrently with the internal-findings and constraints lenses.

• sdlc-review-lead

  Runs the review phase in two modes — verify mode establishes the build and test truth once before the specialist reviewers fan out, then synthesize mode merges their findings, deduplicates by root cause, allocates issue ids, applies mechanical fixes, and signs off on the review gate. Runs first and

• sdlc-review-performance

  Performance and resource lens of the parallel review phase — reviews the diff for N+1 access, unbounded queries and growth, missing timeouts, blocking work, and payload cost. Emits local findings for the review lead to merge. Runs concurrently with the other review lenses in phase 8.

• sdlc-review-security

  Security lens of the parallel review phase — reviews the diff for injection, authorization gaps, secret handling, unsafe deserialization, and data exposure, adversarially. Emits local findings for the review lead to merge. Runs concurrently with the other review lenses in phase 8.

• sdlc-review-tests

  Test honesty lens of the parallel review phase — checks every assigned test case against the approved plan, catches assertions narrowed to fit the implementation, tautological tests, over-mocking, and untested failure paths. Emits local findings for the review lead to merge. Runs concurrently with t

• sdlc-ux-auditor

  Independently audits the UX specification before implementation — usability, accessibility, cognitive load, error recovery, and consistency. Adversarial by design; does not defer to the designer.

• sdlc-ux-designer

  Designs the user experience for the stories — flows, screen specs, states, wireframes, and design tokens. Runs after the PRD. Use for any feature with a user-facing surface.

Similar plugins