sdlc

Plugin sdlc from marketplace nonoun in kimgranlund/nonoun-plugins. Commands read from the repo's manifest — today.

Skills (34)

• agent

  Launch an SDLC agent by name on instructions: solo delivers a ticket, scout, researcher, architect, and archaeologist answer a question, ui-designer plans, reviews, or generates DOM and CSS. Other names point to their own skill. NOT for creating agents.

• architect

  Design how a goal fits the existing system: approach, interfaces, constraints, rejected alternatives. Use before /plan for cross-cutting or unfamiliar work.

• ask

  Sweep the thread, task folder, tickets, run results, and notes for open questions and blockers, then ask them in one AskUserQuestion round with reasoned options, and take prose input when an answer needs it. Use for \"what is still open\", \"what is blocking us\", \"ask me what you need\", or before

• bench

  Benchmark the agent team: run each saved task through /chain in a throwaway worktree, grade it with the real solution's hidden tests, and compare pass rate, cost, and attempts across runs. Use after changing a role, a level table, or a rubric.

• board

  The status board for sdlc work: one table (Task, Step, Status, %) rendered from .sdlc/ by scripts/board.py, never written by hand; gains optional ID and Ticket columns when a rendered task's handoff.md has ticket front matter. Use for any status ask (\"status?\", \"where are we\", \"show the board\"

• chain

  Drive one task through the whole loop: optional scout, research, and architect, then plan, then build and verify each step with escalation, then finish loose ends, file, and close out in one question round. Use when a task should run end to end.

• checking-rules

  Discipline for a verifier checking a builder's step against its acceptance criteria: a dismissal costs the same evidence as a confirmation, a builder's "done" claim is checked against the artifact rather than trusted, and every fail reason is steelmanned before it is filed. Use when verifying a buil

• checks-that-bite

  Makes a check actually discriminate — tests, negative controls, guard greps, gates — and audits prose claims with the same rigor. Use when writing a negative control, reviewing assertions, or asking "is this test actually testing anything", "prove the gate bites", "the test passes but the feature is

• clarify

  Sharpen a vague or overloaded ask into an executable one (root goal, deltas, scoped do with a done-condition) and write it into the task handoff. An ask that already states its scope and done-condition passes through in one line. Use for \"what are they actually asking for\", \"is this ask scoped\",

• decompose

  Break a scoped problem into parts along two independent planes, outside-in (whole to parts, the structure) and inside-out (actions to surfaces, the behavior), then prove they cover each other with scripts/coverage_check.py. Use when breaking down a technical or UX architecture, a goal, or a system;

• dig

  Explain why code is the way it is: history, decisions, landmines, from git history.

• fanout

  Run ticket lanes in parallel: each lane is a git worktree whose tickets run one at a time through the lane `steps.py lane` picks (the `solo` agent for ticket levels L1 and L2, the headless /chain for the rest), merge into an integration branch behind gates, and close there. On the Claude host the pa

• file

  Draft the records for a finished task (PR title and body, changelog entry, follow-ups) from its .sdlc artifacts, then publish only what the user approves.

• fix

  Fast lane for a ticket level L1 item (a doc line, a lint tweak, one test, a one-file fix), run only when the user asks for /fix or the lane script prints `fix`; ticket levels L1 and L2 go to the `solo` agent by default. The factory writes the step handoff itself, runs builder L1 or L2 and verifier L

• fleet-doctor

  Diagnose why runs are slow or stuck right now: a role waiting on stdin, a stalled lane, a slow check.sh, an overloaded machine, a runaway process, a heavy peer repo, or replan cost. Printed by scripts/fleet_doctor.py with evidence per finding, then one AskUserQuestion round of ranked fixes, carried

• fleet-retro

  Run a retro of how SDLC served several repos at once: collect each repo's fingerprint, detect waste and stalls mechanically, interview each repo's factory, write one cost-ranked report where every finding carries an evidence pointer and [V] or [U], check the findings with a sampled verifier and the

• fleet-status

  The status of every active repo in one screen, in a fixed order: machine load with a verdict, what needs the user, what is really moving, what is stale or stuck, what finished since the last report, and release state. Printed by scripts/fleet_status.py render, never composed by hand, then at most on

• grill

  Derive the load-bearing design decisions for a greenfield system, component family, or feature whose decision space is mostly unmade, in grounded, cascading AskUserQuestion rounds until it settles, then write the ratified design to the task. Use for \"grill me on the design\", \"nothing is decided y

• handoff-format

  Layout and templates for sdlc task folders (<work root>/<task>/, .sdlc/ by default or docs/work/ with work_root: docs/work) and handoff files. Reference for the launcher skills; not a command.

• handoff

  Start an sdlc task: create <work root>/<task>/handoff.md (.sdlc/ by default, docs/work/ with work_root: docs/work) from the current discussion so clean-context agents get everything they need.

• level-rubric

  Level tables and routing rubrics for every sdlc role (model and effort per level, and how to pick a level). Reference for the launcher skills; not a command.

• onboard

  Set up or check the entry files (AGENTS.md, CLAUDE.md) and the docs layout for a repository adopting SDLC, keeping anything the repository already wrote. NOT for moving existing documents into the layout.

• open-questions

  Clear a task's unresolved items (open questions, unconfirmed defaults, undecided choices) in one batched AskUserQuestion round at the end of a /chain run or session. Use for \"anything still open\", \"loose ends\", \"close this out\", or \"what's still pending\". NOT for ambiguity before a task star

• plan-loop

  Plan a /loop: pick the interval or dynamic mode, write a self-contained idempotent prompt with a stop condition, check it with plan_check.py, and return one copy/paste /loop line. Use for \"check this every 20 minutes\" or \"keep watching X\". NOT for running the loop, or for watching running roles

• plan-verification

  Capture the outcome a plan serves: one outcome sentence with its why, a measure with its before value and target, a 3 to 5 criterion rubric, and a negative control, as lines another plan skill places in its block. Use before a goal is written (plan-goal reads it), or for \"what is this goal for\", \

• plan

  Plan work by kind and return a linted, paste-ready result with a dry run printed first. Kinds: steps (default: dispatch the planner to turn a goal into ordered steps with acceptance criteria and a builder level per step), doc (a plan doc a smaller session runs with run-plan), goal (one /goal block f

• report

  Report the state of this agent thread: an executive summary by default, or the views you name (tasks, signals, needs, context, cost, children, identity, evidence, lanes, waves, full). It shows what finished, what is in progress, what comes next, what needs the person, and where the thread has proble

• research

  Research an outside-world question (docs, APIs, libraries) with cited findings.

• review-traces

  Review a project's sdlc run traces for waste and bugs caused by sdlc, with no model call in the ingest and detect stages, then diagnose, verify, propose, and file each confirmed finding as a ticket after approval.

• run-plan

  Run an approved plan doc to completion unattended: preflight, then loop plan_done.py, dispatch each open step through fanout.py prep and land, follow steps.py next, and stop with state written when a script says stop. Built for a smaller driver model that follows exit codes and carries no judgment.

• scout

  Map where the code for a question lives: files, symbols, entry points. Fast and read-only.

• sdlc

  Run SDLC workflows in Codex: tickets, handoffs, plans, builds, verification, chains, boards, and parallel lanes. Use for structured software delivery or SDLC status. Includes native Codex role execution and project-scoped predefined subagents. Requires authenticated Codex CLI for pipeline roles.

• ticket

  Stamp a typed ticket with the next id, or generate the roadmap (roadmap.md in .sdlc/, .sdlc/tickets/roadmap.md with layout: topics, docs/work/ROADMAP.md with work_root: docs/work) from ticket front matter in dependency order. NOT for free-text briefs, which stay with /handoff.

• verify

  Verify a built step: dispatch the independent verifier against the step's acceptance criteria. Use after /build.

Subagents (38)

• archaeologist-L1

  archaeologist at level L1: sonnet medium. Same role as the archaeologist agent.

• archaeologist

  Use to explain why code is the way it is: past decisions, deliberate oddities, and landmines, from git history, comments, and tests. Read-only. NOT for locating code (scout), outside documentation (researcher), or designing a change (architect).

• architect-L1

  architect at level L1: opus xhigh. Same role as the architect agent.

• architect

  Use to design how a goal fits the existing system before planning: approach, interfaces, constraints, rejected alternatives. Writes only its decompose manifest under the artifacts dir. NOT for ordered steps with criteria (planner), locating code (scout), or any code edit.

• builder-L1

  builder at level L1: opus low. Same role as the builder agent.

• builder-L2

  builder at level L2: sonnet high. Same role as the builder agent.

• builder-L3

  builder at level L3: opus medium. Same role as the builder agent.

• builder-L4

  builder at level L4: opus high. Same role as the builder agent.

• builder-L5

  builder at level L5: opus xhigh. Same role as the builder agent.

• builder

  Use to implement exactly one plan step from a handoff, running the checks its acceptance criteria name. Edits code in the current tree. NOT for planning, widening a step, judging its own work (verifier), or publishing.

• factory

  Default session agent for repos that use sdlc. Talks to the user, routes each ask to the right sdlc skill, dispatches roles as sub-agents (dispatch.py prepare, an Agent spawn, dispatch.py record; Codex runs scripts/run.sh), applies escalation, and reports with /board. Makes only trivial edits itself

• filer-L1

  filer at level L1: sonnet low. Same role as the filer agent.

• filer

  Use after a task finishes, to draft its records (PR title and body, changelog entry, tagged follow-ups) from the plan, builder, and verifier artifacts. Drafts only, never publishes. NOT for running gh or git, filing tickets (tickets.py close does that), or work that has no artifacts yet.

• hybrid

  Session agent for repos that use sdlc in hybrid mode: works live on small asks (ticket levels L1 and L2) as the live agent does, and sends large, background, or hash_bound asks to a ticket and a solo lane with one independent verifier, as the factory does. Stays interactive while lanes run. Declare

• live

  Session agent for repos that use sdlc in live mode: the session does the work live with the user, with no tickets, handoffs, or pipeline roles unless the user asks. Reads, edits, runs the project's own checks, and commits with a one-line message. Declare per repo with \"agent\": \"sdlc:live\" in .cl

• messenger

  Long-lived session sub-agent, not a run.sh pipeline role, that polls the mailbox for new messages and reports them to its parent.

• plan-reviewer-L1

  plan-reviewer at level L1: fable high. Same role as the plan-reviewer agent.

• plan-reviewer

  Use to review a finished plan before any builder starts: returns pass, replan, or blocked with findings tied to steps and evidence. Read-only, never rewrites the plan. Run it on a different model family than the planner. NOT for writing or fixing the plan (planner), verifying built work (verifier),

• planner-L1

  planner at level L1: sonnet high. Same role as the planner agent.

• planner-L2

  planner at level L2: opus medium. Same role as the planner agent.

• planner-L3

  planner at level L3: opus high. Same role as the planner agent.

• planner

  Use to turn a goal (plus any scout, research, architecture, or failed-build artifacts) into ordered steps with runnable acceptance criteria and a builder level per step; also the one replan after a block or plan defect. Read-only. NOT for building, reviewing its own plan (plan-reviewer), or designin

• researcher-L1

  researcher at level L1: sonnet high. Same role as the researcher agent.

• researcher-L2

  researcher at level L2: opus medium. Same role as the researcher agent.

• researcher-L3

  researcher at level L3: opus high. Same role as the researcher agent.

• researcher

  Use to answer one question about the outside world (docs, APIs, libraries, prior art) with cited findings. Read-only. NOT for locating code in this repo (scout), why this code is as it is (archaeologist), or choosing a design (architect).

• scout-L1

  scout at level L1: sonnet low. Same role as the scout agent.

• scout

  Use to locate where the code for one question lives: files, symbols, entry points, as a short Map the next role searches from. Read-only and cheap. NOT for explaining design (architect) or history (archaeologist), outside documentation (researcher), or any edit.

• solo-L1

  solo at level L1: sonnet high. Same role as the solo agent.

• solo-L2

  solo at level L2: opus medium. Same role as the solo agent.

• solo-L3

  solo at level L3: opus high. Same role as the solo agent.

• solo

  Use to deliver one ticket of level L1 or L2 end to end in a single session or one named background sub-agent: read, change, run the checks, report. The default lane for ticket levels L1 and L2 (steps.py lane); solo level L3 for a large ticket. NOT for a ticket that needs a plan or a merge step (chai

• ui-designer-L1

  ui-designer at level L1: opus high. Same role as the ui-designer agent.

• ui-designer

  Use to plan, review, or generate semantic DOM and CSS that follows the project's design system. The handoff's mode line picks one of the three; generate is the only mode that edits. NOT for framework-specific code generation, visual regression tooling, or a non-UI plan step.

• verifier-L1

  verifier at level L1: opus low. Same role as the verifier agent.

• verifier-L2

  verifier at level L2: sonnet high. Same role as the verifier agent.

• verifier-L3

  verifier at level L3: fable xhigh. Same role as the verifier agent.

• verifier

  Use to independently check one built step or ticket against its acceptance criteria and return pass or fail with evidence. Runs checks, never edits. Run it on a different model family than the builder. NOT for building or fixing, reviewing a plan (plan-reviewer), or a second opinion on its own earli

Similar plugins