sdlc

Plugin sdlc from marketplace nightshift in whimzyLive/nightshift-ai. Commands read from the repo's manifest — 3 days ago.

Skills (16)

• acli

  Use acli (Atlassian CLI) to interact with Jira Cloud — create, search, view, link, and edit work items via shell commands instead of MCP tools. Prefer acli over Atlassian MCP to minimize token usage.

• conventional-commit

  Prompt and workflow for generating conventional commit messages using a structured XML format. Guides users to create standardized, descriptive commit messages in line with the Conventional Commits specification, including instructions, examples, and validation.

• design-md

  Analyze Stitch projects and synthesize a semantic design system into DESIGN.md files

• enhance-prompt

  Transforms vague UI ideas into polished, Stitch-optimized prompts. Enhances specificity, adds UI/UX keywords, injects design system context, and structures output for better generation results.

• find-skills

  Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable ski

• gh-cli

  Use gh (GitHub CLI) for all GitHub operations — creating PRs, checking status, commenting, and capturing URLs. Prefer gh over GitHub MCP tools to minimize token usage.

• graphify

  any input (code, docs, papers, images) - knowledge graph - clustered communities - HTML + JSON + audit report

• skill-creator

  Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better t

• to-issues

  Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

• to-prd

  Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.

• user-story-mapping

  Create a user story map that lays out activities, steps, tasks, and release slices. Use when planning a workflow, backlog, or MVP around the user journey.

• user-story-splitting

  Break a large story or epic into smaller deliverable stories using proven split patterns. Use when backlog items are too big for estimation, sequencing, or independent release.

• user-story

  Create user stories with Mike Cohn format and Gherkin acceptance criteria. Use when turning user needs into development-ready work with clear outcomes and testable conditions.

• writing-adrs

  Use when authoring an Architecture Decision Record (ADR) — a short document that captures one significant, hard-to-reverse technical or architectural decision, its context, and its consequences. Triggered by the sdlc ADR pipeline (the knowledge-engineer agent behind /sdlc:docs seed adr and /sdlc:doc

• writing-docs

  Use when writing, restructuring, or reviewing any prose documentation — a tutorial, how-to guide, reference page, or explanation/conceptual doc — for a public docs site (e.g. Mintlify MDX, docs/, README material), a getting-started guide, an API/CLI reference page, or a "why we built it this way" co

• writing-specs

  Use when producing a technical design spec for a feature or Jira story. Enforces consistent spec structure covering data model, API surface, permissions, offline-sync rules where applicable, and web/mobile UI. Run before writing-plans.

Slash commands (16)

• /sdlc:analyze

  Manually-triggered repo-wide scan for AI-config drift, gaps, and config-vs-memory conflicts. Read-only by default; applies a fix only after explicit human confirmation, producing a reviewable diff/PR — never a silent write.

• /sdlc:auto

  Full SDLC automation for a Jira story. Assesses the story (a label probe when it is already AI-Ready), applies the shared triage protocol (refs/triage.md, inline), and routes a `full` story through spec-in-session → your approval → implementation, shipping spec and code in ONE PR, or a `lightweight`

• /sdlc:design

  Attach a design to a Jira ticket. Ingests HTML exports (standalone bundles are unpacked into one readable page each, with a headless render per page), screenshots, handoff folders, and any non-design reference files into docs/design/<slug>/, writes the design index and component inventory, raises a

• /sdlc:docs

  Generate and maintain this repo's public docs surface via the doc-type registry and per-repo docs manifest. Ships five live modes — `sync` diff-drives deterministic reference-doc + `llms.txt` regen and drafts gated how-to refreshes; `release <version>` aggregates merged stories since the last tag in

• /sdlc:impl

  Execute implementation for a Jira story by running the Principal Engineer playbook INLINE in this session (domain agents dispatched directly). Comments the PR back on the story. Triages first — full stories require an approved spec (/spec) on their feat/ branch; lightweight (<= threshold pts) storie

• /sdlc:init

  One-command onboarding for a new repo — interactively scaffolds .claude/project/project-context.md, the active agents' override files, the plugin-root marker, and the project skills manifest, after gating on the gh/acli prerequisites and walking you through acli authentication. Scans the repository

• /sdlc:loop

  Per-pass logic for the code review-and-fix cycle. Each invocation probes PR status, applies the decision table (wait / fix / stop), and returns — the native /loop command handles re-invocation and pacing. The reviewer is configurable per-repo (Review agent: github-copilot | claude-inline | claude-su

• /sdlc:plan

  Produce an implementation plan for a full-path Jira story from its approved spec, committed to the story's feat/ branch (no PR of its own) so it ships in the implementation PR. Off by default — an approved spec's Implementation tasks are the task list. /auto and /impl run it only when project-contex

• /sdlc:prd

  Optional — convert a Jira Epic into a full PRD. The product-manager drafts docs/features/ doc, then every open question is settled with you in this session before the PR is raised and linked back to the Epic. Run after /refine-feature and before /design; skip it when the Epic already says enough — /

• /sdlc:refine-feature

  Refine a raw idea (or an existing Jira ticket) and create or update a Jira Epic. First step in the SDLC pipeline. Returns an Epic key for /prd (optional), then /design and /stories.

• /sdlc:refine-issue

  Triage an unpolished Jira story or a raw text/idea blob into a well-formed story. Refines existing tickets in-place or creates new ones. Use when a story is incomplete, when you receive a rough ticket from a stakeholder, or when raw input needs to be formalised into Jira before it enters the /spec p

• /sdlc:review-fix

  Ingest review comments from a GitHub PR or commit, triage them with the receiving-code-review skill (keep only the ones true in this app's context), fix the accepted ones via the right domain agents, re-review the applied commits, then post each comment's accept/reject justification back on its PR t

• /sdlc:review

  Run ONLY the QA code-quality loop (review → fix → re-review until clean or the round cap) without re-running the implementation lifecycle. With a story key → reviews its fix/ or feat/<STORY-KEY> branch (whichever exists) against the plan + ACs. With no key → Diff mode: reviews the current working ch

• /sdlc:spec

  Write a technical spec for a Jira story IN THIS SESSION, settle every open question with you, and record your approval. The approved spec is committed to the story's feat/ branch (no PR of its own) and ships in the implementation PR alongside the code. Takes one or more story keys, or an Epic key to

• /sdlc:stories

  Decompose a Jira Epic into user stories linked to the Epic. Run after the /prd and /design PRs are merged — both are optional; without a PRD the Epic description is the source.

• /sdlc:triage

  Triage a Jira story's complexity and return a deterministic TRIAGE=lightweight|full / STORY_POINTS= routing block so /impl and /auto route consistently. Reads existing story points; never sets them.

Subagents (11)

• ai-enablement-engineer

  AI workflow manager — SDLC domain agent that owns and keeps the repository's AI configuration (CLAUDE.md, AGENT(S).md, .agents/**, .claude/**), plus plugins/** and skills/**, synchronized once the repo opts in at init. Scans for drift, gaps, and config-vs-memory conflicts and applies fixes as review

• database-administrator

  Database engineer — owns the relational schema: entities and migrations. ALWAYS runs BEFORE the backend engineer when new tables are needed. NEVER runs in parallel with another database-administrator.

• knowledge-engineer

  Knowledge curator — SDLC agent that owns ADR curation: turns founder-known patterns and the accumulated learnings corpus into curated, indexed Architecture Decision Records under docs/adr/. Runs the shared ADR pipeline behind /sdlc:docs seed adr + /sdlc:docs distill and regenerates docs/adr/index.md

• mobile-engineer

  Mobile app engineer — owns mobile screens, components, navigation, and offline-read hooks. Tech stack is project-defined. Scope: the mobile app workspace.

• platform-engineer

  Backend & infrastructure engineer — owns server-side infrastructure and serverless application/handler code. Tech stack is project-defined.

• product-manager

  Use to convert a vague feature idea or requirement into a detailed, product-oriented feature with clear acceptance criteria. Output is product language (no technical details). Run this FIRST before solutions-architect or tech-lead agents. Can be triggered via hooks when a raw feature/ticket arrives.

• scrum-master

  Use to decompose an approved product feature into Jira user stories (decompose mode) or to triage/refine an unpolished story or raw text blob into a well-formed story (triage mode). Run AFTER product-manager for decompose mode. For triage mode, input is a Jira story key or free-form text. Design-rev

• solutions-architect

  Technical-spec workflow for an approved Jira story — data model, API surface, UI flows, permissions, sync behaviour, and the agent-tagged implementation tasks. /spec runs it INLINE so the user settles open questions and approves the spec in session. Input: Jira story key.

• sync-engineer

  Offline-sync engineer — owns the sync layer: sync rules, transaction builders, schema typegen, DLQ. Runs AFTER database-administrator and the backend engineer. NEVER runs in parallel with another sync-engineer.

• tech-lead

  Use to convert an approved technical spec into a detailed implementation plan with tasks tagged by agent and ordered by dependency. Dispatched by /plan — by hand, or by /auto and /impl when project-context `Plan step` is `on` (off by default; the approved spec's Implementation tasks are the task lis

• web-engineer

  Web app engineer — owns the web frontend (pages, components, data hooks, client state). Tech stack is project-defined. Scope: the web app workspace.

Hooks (3)

• SessionStart

  ${CLAUDE_PLUGIN_ROOT}/hooks/load-project-context.sh

• SessionEnd

  ${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-tmp.sh

• SessionEnd

  ${CLAUDE_PLUGIN_ROOT}/scripts/worktree-gc.sh