sdlc

Plugin sdlc from marketplace personal in kulykivska/claude-plugins. Commands read from the repo's manifest — yesterday.

Skills (8)

• debug

  Systematic debugging of a reported problem: reproduce, gather evidence from logs, hypothesize, fix, verify. Trigger on "it is broken", "figure out why", "debug", a pasted stack trace, or a prod incident report.

• engineering-standards

  The one standard both the coding work and the reviewers work from: architecture, failure handling, security, scalability, performance, naming, data and migrations, behaviour analytics, and tests. Also defines review scope (the diff plus the code around it) and the one-pass discipline. Load it before

• lessons-learned

  Accumulated engineering lessons from real production incidents across the owner's projects. Load PROACTIVELY during development, code review, and planning of any feature that sends notifications, handles errors, or runs on a schedule - and whenever a new incident is analyzed, append its lesson here.

• new-task

  Author a tracker-ready task the way a business analyst would, and never let a contradictory one through. Turns an intake into structured requirements, runs a mandatory consistency audit, writes full Gherkin scenarios, and creates the ticket in the project's tracker. Also runs in audit mode against a

• plan-task

  Plan the implementation of a defined task before writing code. Trigger on "plan this out", "plan this", or before starting any multi-file change. Produces the file-level plan, risks, and verification strategy, grounded in the actual code (not assumptions).

• qa

  Exercise a change end-to-end like a user before declaring it done. Trigger on "test this", "qa this", or after implementing any user-visible change. Drives the real flow (API calls, running app, UI), not just unit tests.

• requirements

  Turn a raw (often dictated) idea into concrete requirements before coding. Trigger on "let us build...", "I want a feature...", "add a feature", or any substantial new-feature request where scope is fuzzy. Produces user-visible behavior, edge cases, acceptance criteria, and a consistency check again

• task-review

  Task-scoped review after implementing: regressions, bugs, and smells on the touched files only. Trigger on "review the task", or after finishing a multi-file change before commit. Complements pre-push-review (which gates the push); this one runs right after implementation.

Subagents (3)

• architect

  Designs the implementation approach for a substantial feature or refactor before coding: reads the affected code, weighs alternatives, returns a concrete file-level plan with tradeoffs. Use for multi-file features, cross-repo changes, or when two plausible approaches exist.

• debugger

  Investigates a bug or incident from evidence: logs (Fly/local), stack traces, recent commits. Returns root cause + proposed minimal fix with file:line. Use for non-trivial bugs, prod errors, or when the cause is unclear.

• requirements-analyst

  Audits a set of requirements for contradictions, ambiguity, gaps, and untestability before anything is built. Use from the new-task or requirements skills, or whenever asked to sanity-check a spec, PRD, or ticket for internal consistency. Returns a ranked consistency report; does not design or code.