sdlc

Run SDLC pipelines in parallel for multiple tasks — decomposes scope, detects file conflicts, dispatches worktree-isolated pipelines.

Diagnose SDLC pipeline health — external plugin dependencies, runtime preflight status, and cost baseline (if available). Read-only.

List all stack profiles found in installed plugins, with priority and detection rules. Useful for verifying setup and debugging stack auto-detection.

Materialize stack-specific security-patterns.yaml and claude-security-guidance.md into the current project for the security-guidance plugin to pick up. Safe to re-run — preserves user-defined rules outside the managed block.

Run the full SDLC pipeline (BA → Dev → QA → Security → Docs) for a feature, with auto-detection of the framework stack.

Senior business analyst for ambiguous feature requests. Reads product context (Jira tickets, README, existing code) and produces user stories, acceptance criteria, data model sketches, and edge cases. <example> user invokes /sdlc:start "Add subscription billing with Stripe" orchestrator: dispatches business-analyst for phase 1. output: 5 user stories with Gherkin, data model (Subscription, PaymentMethod, Invoice entities), edge cases (failed payments, refunds, GDPR), open questions about trial periods. </example> Do NOT use this agent for: - Writing code (use developer / framework-architect) - Writing tests (use qa-engineer) - Security review (use security-analyst)

Vanilla full-stack implementer. Used as the development-phase agent when no framework-specific provider is registered. Framework plugins (laravel-plugin, django-plugin, etc.) override this slot via their stack.md. <example> vanilla project (no framework profile matches), orchestrator runs /sdlc:start. developer agent receives spec, implements changes, returns compact summary. </example> Do NOT use this agent for: - Laravel/Django/etc. projects (those have specialized architects) - Test writing (use qa-engineer) - Database-heavy work in Laravel (artisan-specialist handles it)

Final phase. Reads all prior phase outputs and creates a Pull Request with a clean description: summary, what changed, testing notes, security notes. Optionally creates a release-notes blurb for the changelog. <example> pipeline reaches phase 6/6. document-writer reads docs/plans/{slug}/01..04, calls `gh pr create` with a structured description, returns the PR URL. </example> Do NOT use this agent for: - Writing technical documentation in /docs (out of scope for v1.0) - API documentation generation (separate concern) - Updating README beyond linking to the new feature (out of scope)

Test writer and runner. Adds unit/integration/feature tests for development-phase changes. Aims for ≥80% coverage. ⚠️ HARD ITERATION CAP: Maximum 3 attempts to fix failing tests, then STOP and report. This is non-negotiable — runaway iterations are the #1 cost incident. <example> development phase produced 5 changed files. qa-engineer reads the changes, writes pest/jest/pytest tests, runs them, fixes failures within 3 attempts, reports. </example> Do NOT use this agent for: - Writing implementation code (developer / framework-architect) - End-to-end browser tests in Laravel (Phase 5+ might add a separate qa-e2e agent) - Manual QA / exploratory testing (out of scope for this pipeline)

OWASP Top 10 security review of the development-phase changes. Fixes Critical and High issues directly. Documents Medium issues without fixing. Skips Low/Info. <example> development implemented user-uploaded file processing. security-analyst checks: path traversal, MIME-type spoofing, virus scanning, storage in S3 with proper ACL, no shell exec on user input. Fixes Critical issues. </example> Do NOT use this agent for: - Performance review (out of scope for v1.0) - Code style or refactoring suggestions (reviewer-style work — covered by other phases) - Compliance certification (this is an in-loop review, not an audit)

Shared conventions for every SDLC development-phase architect agent: hard rules, code quality bar, workflow steps (superpowers invocation, spec reading, codebase exploration, verification), and the report/compact-summary contract. Architects load this skill first, then apply their stack-specific instructions on top.

Parallel SDLC batch runner. Analyzes a list of independent task descriptions, groups them by heuristic file-conflict prediction, dispatches one worktree-isolated background agent per task (each running the full pipeline-orchestrator: BA → Dev → QA → Sec → Docs), and aggregates results into a single batch summary. Use when: - `/sdlc:batch` invokes this skill after parsing its arguments (Step 2 of commands/batch.md) - You have 2+ independent feature/fix descriptions to run through the SDLC pipeline in parallel Do NOT use for: - A single task (use pipeline-orchestrator directly via /sdlc:start) - Tasks that must share a single working tree (this skill isolates each task in its own git worktree)

Universal SDLC pipeline orchestrator with stack provider auto-discovery. Reads stack.md profiles from installed plugins, picks the highest-priority match, executes a 5-phase pipeline (BA → Dev → QA → Sec → Docs) plus stack-defined extra phases. Use when: - User invokes /sdlc:start "<feature>" - User asks to "run the SDLC pipeline" or "go through the full pipeline" - You need to coordinate specialist agents to deliver a complete feature Do NOT use for: - Trivial single-file edits (just edit directly) - Read-only questions about the codebase - Casual conversation

1 hook across 1 event