sdlc-team

Capture a new requirement into the project's Notion Backlog as a ticket (no sprint, no pipeline run). Non-blocking; no-ops if Notion is disabled.

Run or re-run the Design phase for a feature — dispatches the solution-architect to produce 02-design.md.

Run the optional Docs phase — dispatches the tech-writer to update README/API docs/changelog and write 06-docs.md.

Run the end-to-end test layer on demand — drive the running app as a user via Playwright and record a review video (with a visible mouse pointer, never screenshots) to docs/sdlc/<slug>/e2e-recordings/. No-ops without a web UI; asks before installing Playwright.

Diagnose a failing CI/CD run and, if the cause is pipeline config, patch + re-run until green (gated). Routes code/test failures to /sdlc-implement; infra failures to a re-run.

Use to diagnose a single failing CI/CD run. Given the failed-step logs + the repo's pipeline config, classifies the root cause (config | code/test | infra/transient) and, if it's config, prescribes a concrete patch. Diagnoses and prescribes only — never edits, pushes, re-runs, or deploys. <example> Context: The /sdlc-fix-ci loop fetched a red run's logs and needs a diagnosis. user: "(failing run logs + workflow.yml)" assistant: "I'll use the ci-doctor agent to classify the failure and, if it's config, prescribe a patch." <commentary>One diagnosis per loop iteration, with fresh context.</commentary> </example>

Use to review an implementation's code quality (part of the parallel inspection phase). Checks bugs, conventions, SOLID/clean-code, performance, and known vulnerability classes; writes 04b-code-review.md with file:line findings. White-box perspective. <example> Context: Implementation done; orchestrator runs the inspection trio. user: "(02-design.md + diff attached)" assistant: "I'll use the code-reviewer agent to review the diff and write 04b-code-review.md." <commentary>Phase 4 — code-quality review against the design and standards.</commentary> </example>

Use to end-to-end test an implementation by driving the running app as a real user via Playwright and recording a review video (part of the parallel inspection phase). Detects a web UI, emulates mouse/keyboard, writes 04e-e2e.md with the recording path, and no-ops when there's no web UI. Black-box perspective. <example> Context: Implementation done; orchestrator runs the inspection set. user: "(03-implementation.md + diff attached)" assistant: "I'll use the e2e-tester agent to drive the app via Playwright, record the run, and write 04e-e2e.md." <commentary>Phase 4 — end-to-end behavioral verification with a video for the Gate-3 review.</commentary> </example>

Use to implement an approved design in code with tests (Phase 3 of the SDLC pipeline). Writes the code and tests, runs the build/tests, and produces 03-implementation.md (files changed, decisions, test results). <example> Context: Design approved at Gate 2; orchestrator starts Phase 3. user: "(approved 02-design.md attached)" assistant: "I'll use the implementer agent to build it and write 03-implementation.md." <commentary>Implementation phase — write code + tests against the approved design.</commentary> </example>

Use during Phase 4 inspection to audit the repo's CI/CD pipeline config (CI workflows + Dockerfiles) for security, correctness, reliability/cost, and plugin-convention issues. Reports findings; never fixes or deploys. No-ops cleanly when no pipeline config exists. <example> Context: Phase 4 parallel inspection on an implemented feature. user: "(inspect the changes)" assistant: "I'll run the pipeline-reviewer agent alongside QA/code-review/security to audit the CI/CD config." <commentary>Phase 4 — pipeline audit as a parallel inspection dimension.</commentary> </example>

Inventory the capabilities already available in the current session so the SDLC team can reuse them. Use at pipeline start (Phase 0) to discover project-local agents and skills (.claude/agents, .claude/skills), agents/skills from other installed plugins, and connected MCP servers, plus the repo's CLAUDE.md. Produces a capability map the orchestrator uses to decide delegation.

Diagnose a failing CI/CD run — retrieve the failed-step logs, classify the root cause (config | code/test | infra/transient), and route or fix. Use when a CI run is red, e.g. by the ci-doctor agent and the /sdlc-fix-ci loop. Forge-aware; reuses the cicd-pipeline-audit fix catalog.

Audit CI/CD pipeline config (CI workflows + Dockerfiles) for security, correctness, reliability/cost, and plugin-convention issues. Use when reviewing or generating pipeline config — by the pipeline-reviewer (Phase 4) and the release-engineer (Phase 5). Prefers real linters, falls back to a checklist.

Apply pragmatic clean-code standards — DRY, YAGNI, KISS, separation of concerns, naming, small functions, low complexity. Use when writing or reviewing code to keep it readable and maintainable. Cited by the implementer, QA, and code reviewer as a shared rubric.

Design and review relational schemas, MySQL-focused. Use when the design or implementation involves data modeling — tables, keys, relationships, normalization, indexing, constraints, migrations, and query/EXPLAIN optimization. Used by the architect (data model) and implementer (schema/migrations).

1 hook across 1 event