delivery-team

Plugin delivery-team from marketplace ember-toolkit in saralafleur/ember-claude-toolkit. Commands read from the repo's manifest — 21 days ago.

Skills (6)

• team-build

  Run a virtual engineering team (build-triage, build-planner, test-author, implementer, verifier, reviewer, build-lead) over an approved plan to actually BUILD it — on any project. Use when: a team-intake technical-plan and a team-qa test-plan exist and the work now needs to be implemented; you want

• team-intake

  Run a virtual delivery team (triage, product owner, architect, engineer, QA, project manager, tech lead) over an incoming client request — on any project. Use when: a new feature/bug/change request comes in and needs to be understood, classified, and turned into a plan before any code is written; yo

• team-qa

  Run a virtual QA team (change-intake, coverage cartographer, risk analyst, unit-test architect, e2e-test architect, QA strategist, QA lead) over a change that was just built — on any project. Use when: code has just been written/modified and you need to know what tests to add or update so it cannot

• team-release

  Run a small virtual release team (release-scribe, release-lead) over everything that shipped in a version and produce a client-facing release-notes.md — on any project. Use when: one or more team-build runs are done (verified green) and you want to tell the client what changed; you are cutting a ver

• team-status

  Run a virtual delivery-status team over a folder in a project''s delivery pipeline and answer "where are we, and what do we invoke next?" — on any project. Use when: you open a batch or an intake-base folder and need to know the true current state of every work item in it; a plan/report might be sta

• team-decisions

  Sweep a project''s delivery-team pipeline (every intake/qa/build/release/status decisions.md) for PENDING or PARKED decisions the team could not resolve on its own, and clear the backlog the way a director of engineering would: auto-resolve every decision the context can confidently settle — clear p

Subagents (28)

• build-implementer

  Sole implementer for the team-build process. Works the ordered task list in sequence and applies the technical-plan's change set to make the red tests pass — applying any durable structural cure the plan marked MANDATORY and never taking an inline shortcut. The green half of strict red-first TDD. Th

• build-lead

  Build Lead / synthesizer for the team-build process. Runs last, after the build is verified green and reviewed. Reconciles the brief, task list, red/green evidence, and review into a single build-report, owns the build run-log, and feeds this project's shared defect-catalog memory (if configured) wh

• build-planner

  Build planner for the team-build process. Turns the approved technical-plan (what to change) and test-plan (what to prove) into ONE ordered, dependency-correct task list the implementer can execute step by step — and marks every durable-cure step MANDATORY so a structural fix can't be quietly droppe

• build-reviewer

  Adversarial diff reviewer for the team-build process. Reviews the build's diff since the starting commit against this project's recurring-issue traps (loaded from its domain context, if configured) plus ordinary correctness/simplification. Runs after the verifier is green, to catch the green-but-wro

• build-test-author

  Test author for the team-build process. Writes the tests named in the approved test-plan FIRST and proves each one RED against the current unbuilt code, recording the exact failing output — so the implementation that follows has something real to make green. Edits test files only, never product code

• build-triage

  Build-intake clerk for the team-build process. Confirms the approved technical-plan and test-plan exist and are buildable, provisions an isolated per-effort git worktree set (only for the repos the plan actually touches) plus a namespaced Docker stack when the project has one, records the starting c

• build-verifier

  Verification gate for the team-build process. Brings up this effort's own isolated Docker stack (if the project has one) and never the shared dev stack, runs the full relevant suites against it, proves every new test went red→green, and runs the Definition of Done plus this project's standing qualit

• director-of-engineering

  Decision-maker for `direct` mode, shared across every team-* skill in this plugin. Given a skill's own agent roster and the actual request/change/plan, decides which of that skill's agents are actually warranted for THIS piece of work and in what order — so small changes don't pay for the full forma

• intake-architect

  Solution Architect for the team-intake process. Evaluates a request's system/design impact — which subsystems and boundaries are affected, architectural options and trade-offs, and risks. Runs in the evaluation phase. Read-only investigation plus a written findings file. Generic — works on any proje

• intake-client-liaison

  Client-facing sign-off writer for the team-intake process. Translates the internal intake artifacts (decisions, sign-off flags, blockers) into a clean, plain-language approval sheet a non-technical client can read and answer in a few minutes. Strips ALL internal jargon and reference codes, and keeps

• intake-engineer

  Software Engineer for the team-intake process. Evaluates code-level reality — exactly which files/functions change, feasibility, effort, dependencies, and concrete gotchas. Runs in the evaluation phase. Read-only investigation plus a written findings file. Generic — works on any project.

• intake-product-owner

  Product Owner for the team-intake process. Evaluates a request from the value/scope/stakeholder side — is it in scope, does it align with approved requirements and any stakeholder source-of-truth, what's the user-facing acceptance and priority. Runs in the evaluation phase. Generic — works on any pr

• intake-project-manager

  Project Manager for the team-intake process. Determines the true TYPE of a request, reconstructs its HISTORY/background (have we seen this before?), consults persistent memory to break repeating cycles, and authors the PM plan. This is the agent whose plan the human reviews. Generic — works on any p

• intake-qa

  QA / Test architect for the team-intake process. Defines how we will PROVE the request is done and protected against regression — acceptance verification steps, which tests to add/update (parity/regression), and the manual check. Runs in the evaluation phase. Generic — works on any project.

• intake-tech-lead

  Tech Lead / synthesizer for the team-intake process. Merges the Architect, Engineer, and QA findings into a single coherent Technical Plan with concrete code recommendations and a sequenced implementation approach. Runs last, after the evaluation phase. Generic — works on any project.

• intake-triage

  Intake clerk for the team-intake process. Ingests a raw client request (file or folder), normalizes it into a structured request brief, and flags blocking ambiguities before any evaluation happens. First agent in the pipeline. Generic — works on any project.

• qa-coverage-cartographer

  Coverage cartographer for the team-qa process. Maps the EXISTING test coverage for the surfaces a change touches across every layer this project tests at, and runs the relevant suites to record the current green/red baseline. This is how the team "fully understands the current testing strategy" befo

• qa-e2e-architect

  E2E / API / integration test architect for the team-qa process. Designs the end-to-end and contract-level coverage the change needs — which spec, which project/tag/bucket, and the single-spec run command. Runs in the evaluation phase. Read-only investigation plus a written findings file. Does not au

• qa-lead

  QA Lead / synthesizer for the team-qa process. Merges the coverage, risk, unit-test and e2e-test findings into a single coherent, buildable Test Plan — the exact specs to add/update, the assertions, the sequencing, the run commands, and the Definition of Done. Runs last, after the evaluation phase.

• qa-risk-analyst

  Risk & regression analyst for the team-qa process. Evaluates what the change could break, which invariants must hold, and how it maps onto this project's known recurring failure modes (if it has a defect catalog configured). Names the "ships green but broken" traps so the test plan closes them. Read

• qa-strategist

  QA Strategist for the team-qa process. Judges whether the change's current test coverage is adequate, diagnoses test-debt, answers "have we shipped this kind of gap before?" from shared recurring-issue memory (when the project has one configured), and authors the QA assessment the user reads first.

• qa-triage

  Change-intake clerk for the team-qa process. Ingests "what we just changed" (a git diff, a list of changed files, or a completed team-intake technical-plan) and normalizes it into a structured change brief that names the surfaces touched and the test-invariants at risk. Flags blocking ambiguity befo

• qa-unit-architect

  Unit / parity / component test architect for the team-qa process. Designs the fast, deterministic-layer tests the change needs — naming exact specs, cases, and assertions for whatever unit/component/integration frameworks this project uses. Runs in the evaluation phase. Read-only investigation plus

• release-lead

  Release Lead / synthesizer for the team-release process. Runs last, after the release-scribe drafts the client-facing notes. Fact-checks every client-facing claim against the ACTUAL shipped git commits and build-reports (so the client is never told something that wasn't shipped, and nothing shipped

• release-scribe

  Client-facing release-notes writer for the team-release process. Turns the internal delivery artifacts of everything shipped in a version (build-reports, plans, decisions, the git/version diff) into a plain-language release-notes.md a non-technical client can read in a few minutes — and keeps a priv

• status-lead

  Status Lead / synthesizer for the team-status process. Merges the triage inventory and every per-item scanner's findings into one status-report.md — a stage-map of every work item, the report-vs-reality discrepancies, open decisions, cross-item drift, and the SINGLE recommended next action (which of

• status-scanner

  Per-item reconciler for the team-status process. Takes ONE work item and reconstructs its true current state by reading its plans/reports AND re-verifying every load-bearing claim against the live code (re-running cited tests, grepping cited files, checking cited endpoints) — because a report is a c

• status-triage

  Scope-and-inventory clerk for the team-status process. Resolves whether a target folder is a whole batch or a single work item, enumerates every work item inside it, and inventories which pipeline artifacts (technical-plan, test-plan, qa-assessment, build-report, decisions) each item has. Writes not

Similar plugins