agent-dev-team plugin

Owns the transformation layer between raw tables and the people who query them: dbt or SQL models, dimensional design, slowly changing dimensions, and the metric definitions everyone shares. Use when a model needs building or refactoring, when the same metric is computed three different ways, or whe

Brings up new hardware and debugs at the signal and boot level: first power-on, clock and pin configuration, JTAG and SWD attach, bootloader and linker script problems, hard faults, and peripherals that never respond. Use for a board that has never run, a device that will not enumerate or boot, or a

Reviews a diff, branch, or pull request across correctness, readability, architecture, security, and performance, returning severity-labelled findings with file and line references. Use before merge, when asked to check code someone or something else wrote, or for a quality pass on a change. Reviews

Answers questions with data: defines the metric, writes the exploratory query, sanity-checks the result, and states the caveats and confounders that come with it. Use when someone asks why a number moved, what a metric should mean, whether a change had an effect, or whether a dashboard is lying. Ref

Builds and fixes data pipelines and the warehouse underneath them: ingestion, ELT jobs, table schema and partitioning, backfills, orchestration DAGs, late and duplicate records, and warehouse cost. Use when a pipeline is broken, late, or expensive, when a table needs a schema change, or when raw dat

Writes and maintains technical documentation: READMEs, API reference, architecture notes, runbooks, changelogs, and onboarding guides. Use when documentation is missing, stale, or unreadable, or when a change needs its docs updated. Writes for a specific reader with a specific task, never a feature

Writes and reviews microcontroller firmware under hard resource limits: RTOS tasks, interrupt handlers, peripheral drivers, HAL boundaries, stack and flash budgets, power states, and OTA update paths. Use for embedded C or C++ or Rust on an MCU, driver work, or a bug that only reproduces on hardware

Builds and fixes user interface code: component structure, state and data flow, forms, loading and error states, responsive layout, and Core Web Vitals. Use for UI implementation, a component that re-renders too much, a layout that breaks, or a page that loads slowly. Verifies in a real browser, not

Runs a live production incident: severity call, mitigation before diagnosis, status updates, and a blameless postmortem afterwards. Use when production is broken right now, when an outage needs coordinating, or when writing the postmortem after resolution. Prioritises stopping the bleeding over find

Executes a fully specified mechanical change of at most two files: a rename, a typo, a config value, one more case in an existing table, a test that mirrors a neighbouring test. Use only when the brief already names the exact files, the code to copy, and the command that must pass. Halts and hands t

Takes a model from notebook to production and keeps it honest there: feature pipelines, training and serving parity, offline and online evaluation, drift monitoring, and the rollback path for a model that degrades. Use when shipping a model, when predictions get worse in production, when a feature p

Diagnoses and fixes measured slowness: latency regressions, N+1 queries, memory growth, slow builds, and Core Web Vitals misses. Use when something is measurably slow, when a budget is being missed, or when a change lands in a hot path. Refuses to optimize without a before-and-after measurement.

Terminal technical authority for system-level design, contract arbitration, and problems that beat a senior engineer. Use for cross-service design, disagreement between two reviewers or two architectures, subtle correctness and concurrency bugs, or a decision that is expensive to reverse. Must produ

Turns a vague request into scoped requirements with acceptance criteria, non-goals, and open questions. Use when the ask is fuzzy, when nobody has written down what "done" means, when scope is growing, or before any planning or code exists. Produces a requirements document, never code.

Audits code and design for vulnerabilities, threat models a change, and hardens trust boundaries. Use when a change touches authentication, authorization, secrets, cryptography, untrusted input, file paths, or an agent's tool permissions, and before shipping anything internet-facing. Reports finding

Implements ambiguous, cross-cutting, or risky changes: refactors, migrations, work spanning several modules, and tasks whose requirements are incomplete. Use when a task is too vague or too wide for an ordinary engineer but does not need an architectural decision. Resolves ambiguity itself and write

Implements a well-specified feature or bug fix inside an existing pattern, test first. Use for ordinary day-to-day development where the requirement is clear, the pattern to follow already exists in the codebase, and no interface other components depend on has to change.

Owns getting a change into production safely and keeping it observable: release plan, rollout strategy, feature flags, rollback, alerts, runbooks, and CI/CD pipelines. Use before deploying, when a release needs a rollback path, or when a service needs monitoring and on-call documentation. Not for li

Decomposes approved requirements into a sequenced task breakdown, assigns each task to the right tier, and owns architecture decision records. Use when requirements exist but there is no plan, when work needs splitting across agents, when choosing between two designs, or when a project needs routing

Designs test strategy, finds coverage gaps that matter, writes missing tests, and diagnoses flaky suites. Use when asking what tests are needed, when coverage is unclear, when tests are slow or intermittently failing, or when a bug shipped that tests should have caught.

Reviews an interface for usability, visual hierarchy, consistency, accessibility against WCAG 2.1 AA, and the wording users read. Use to critique a screen or mockup, audit accessibility, or fix error messages, empty states, button labels, and confirmation dialogs. Reviews and rewrites copy; does not

No description in the file.

Records a non-obvious technical choice as an ADR with context, options, the decision, consequences, and the condition that should reopen it. Use when choosing between technologies or designs, when a decision is expensive to reverse, or when someone will ask in six months why it was done this way. Also use to review a proposed design.

Runs a tracker ticket through the whole lifecycle without stopping at each stage boundary - requirements, plan, build, review, release plan - with escalations routed to a terminal tier instead of to a waiting human. Use when a ticket already carries enough intent to work unattended, when nobody is available to answer stage-by-stage questions, or when the ask is to work an issue end to end and report back. Refuses to deploy, refuses to push, and refuses to resolve product intent on the human's behalf.

Confirms a user-interface change actually works by loading it in a real browser and checking rendering, interaction, keyboard access, console output, network calls, and responsive behavior. Use after any visual or interactive change, when a test passes but the page might not, or before claiming a UI change is done.

Reviews a diff, branch, or pull request across correctness, security, architecture, readability, and performance, returning ranked findings with file and line references and a concrete fix for each. Use before merging, when checking code written by someone or something else, or when a change needs a quality gate.

No description in the file.

No description in the file.

No description in the file.

No description in the file.

No description in the file.

No description in the file.

No description in the file.

No description in the file.

Executes a multi-task plan one task at a time, keeping every commit atomic and green before starting the next. Use when working through a task list, when a change is large enough to need checkpoints, when commit hygiene matters for bisect, or when tempted to build several things at once. Refuses to begin the next task while the previous one is unverified.

No description in the file.

Fixes measured slowness by setting a budget, profiling to find where time actually goes, changing one thing, and measuring again. Use for a latency regression, an N+1 query, memory growth, a slow build or test suite, or a Core Web Vitals miss. Refuses to optimize anything without a baseline number.

No description in the file.

Extracts what someone actually needs by asking one question at a time, separating the problem from the solution they proposed. Use when a request is vague, when you are about to guess at intent, when scope keeps shifting, or when nobody has said what done means. Ends with written requirements and acceptance criteria.

Audits a change or a system for reachable vulnerabilities by tracing untrusted input to its sinks and checking authorization at every new path. Use when code touches authentication, secrets, cryptography, file paths, shell execution, deserialization, or any input crossing a trust boundary, and before exposing anything to the internet.

No description in the file.

Turns gathered requirements into a written specification that an implementer can build from without asking follow-up questions. Use when requirements are known but not written down, before starting a feature that spans several tasks, or when a spec needs reviewing for gaps and contradictions. Produces a committed document, not a chat message.

Finds the actual cause of a defect by reproducing it, narrowing the search space by bisection, and proving the diagnosis before changing code. Use for a crash, a stack trace, a flaky or intermittently failing suite, or behaviour that differs from expectation and resists an obvious fix. Refuses to change code before the cause is proven.

Writes the failing test first, watches it fail for the right reason, then makes it pass with the smallest change. Use before implementing any feature or bug fix, when adding a regression test, or when a change needs proof it works. Refuses to write implementation code before a red test exists.

Hands work up to a higher tier, or down to a lower one, with a structured packet so no context is lost. Use when a task exceeds the current agent's ceiling, when a brief is too vague to execute, when two agents disagree, or when decomposing work for someone else to do. Escalating correctly is a successful outcome, not a failure.

Routes an incoming engineering request to the right team member and the right workflow, and explains the tier system. Use at the start of any development work when it is unclear who should do it, which skill applies, or how much process a task deserves. Also use when a task turns out to be bigger than it looked and needs re-routing.

Splits a spec into an ordered list of tasks, each with a single verifiable outcome, an assigned tier, and a delegation brief. Use when a spec exists but there is no plan, when work must be divided across agents or people, or when a task is too large to verify in one step. Produces a plan file, not code.

Bash

Bash

Edit|Write|NotebookEdit|Bash

No description in the file.

^agent-dev-team: