Software engineering

Splits an epic into small, ordered vertical slices that each deliver testable value, with acceptance checks, dependencies and spikes. Use when an epic or large feature is too big to start.

Breaks engineering work into tasks and produces a range estimate with a confidence level, stated assumptions and the unknowns that need a spike. Use when asked "how long will this take?".

Turns a technical unknown into a time-boxed spike with a sharp question, exit criteria, cheapest-first experiments and a clear deliverable. Use when an unknown blocks a decision or an estimate.

Reads the codebase and writes an ordered implementation plan in small verifiable steps, with files to touch, tests, rollout and risks. Use before coding any change that spans several files.

Acts as a product manager who starts from the user problem and evidence, writes requirements engineers can build and test, and cuts scope to the smallest valuable release.

Writes testable acceptance criteria for a user story or ticket, covering the main path, alternatives, validation, boundaries, permissions and empty states. Use before a story enters development.

Writes a product requirements document that an engineering team can build from, with the problem, goals, success metrics, testable requirements, edge cases and open questions.

Turns a feature description into small, independent user stories for specific users, each with acceptance criteria, and splits stories that are too big. Use when preparing a backlog.

Compares two to four technical options against the criteria that matter, weighs reversibility and risk, and recommends one. Use when a team is stuck choosing between approaches or tools.

Designs an API contract before implementation, with operations, schemas, errors, pagination, idempotency and evolution rules. Use when adding an API that other teams or clients will call.

Reviews a design document or proposal for failure modes, scaling limits, data and consistency risks and operability gaps, and returns ranked findings. Use before a design review or before building.

Acts as a pragmatic software architect who designs from requirements and constraints, names trade-offs and failure modes, and keeps designs as simple as the problem allows.

Wraps new behaviour behind a feature flag with a safe default, a kill switch, tests for both paths and a cleanup ticket. Use when shipping a risky change incrementally.

Adds sleep modes to battery firmware, gating clocks and peripherals, choosing wake sources and state retention, and backs the change with a current measurement plan and battery-life budget.

Adds rate limiting to API endpoints with a fitting algorithm, keys, per-tier limits, standard headers, 429 responses and tests. Use when protecting endpoints from abuse or overload.

Adds timeouts, retries with exponential backoff and jitter, idempotency and a circuit breaker to calls to an external service, with tests that simulate failures.

Reviews a pull request diff for correctness bugs, risky changes and missing tests, and returns ranked findings. Use before merging a PR, branch or diff.

Reviews changes like a senior engineer who blocks only on real defects, backs every finding with a triggering input, and keeps style opinions out. Use as a reviewer persona or subagent.

Grades the review comments a developer wrote on a real diff, showing which caught real defects, which were overstated nits, what was missed and how to phrase each better. Use to learn to review.

Presents a realistic practice pull request with planted defects such as an off-by-one, a race or a security hole, then scores the learner's review comments against them.

Diagnoses a failing HTTP request layer by layer (DNS, TLS, proxy, CORS, auth, timeouts, payload) from error output and curl or browser traces, giving the next command at each step.

Debugs a bug that happens only in production by diffing environment, config, data, traffic, versions and timing, then plans safe instrumentation to confirm the cause. Use for works-on-my-machine bugs.

Finds the commit or input that introduced a regression by writing an automated good/bad check first, then bisecting. Use when something that used to work is broken and the cause is unclear.

Takes a bug from report to reproduction, root cause, regression test, minimal fix and a verified pull request, stopping for approval between steps. Use for any bug worth fixing properly.

Reviews a test suite or diff for weak assertions, over-mocking, hidden coupling, sleeps, nondeterminism and tests that cannot fail, with a concrete rewrite for each problem. Use when reviewing tests.

Standing rules for tests an assistant writes, covering behaviour over implementation, no sleeps, deterministic data, mocks only at boundaries and one reason to fail per test.

Writes a risk-based test plan for a feature or release covering scope, risks, test levels, environments, data, manual checks automation misses and exit criteria. Use before testing a release.

Pins down what untested legacy code does today with characterization and golden-master tests, bugs included, so it can be changed safely. Use before refactoring or modifying code with no tests.

Finds the complexity a design pattern would actually remove, such as a growing switch or tangled construction, applies it with identical behaviour, or says no pattern fits.

Converts callback-style and promise-chain code to async/await across a module or repo without changing behaviour, keeping error handling, ordering and concurrency, with tests run before and after.

Breaks hard-wired dependencies such as clocks, network calls, globals and singletons behind seams so a class or module can be unit tested, keeping behaviour and public callers unchanged.

Finds hard-coded URLs, limits, credentials and feature switches, moves them into typed configuration with defaults and validation, and updates usages and docs without committing secrets.

Plans and carries out an incremental JavaScript-to-TypeScript migration with config, file order, typed boundaries and a strictness ratchet. Use to move a JS codebase without a freeze.

Plans a framework, platform or system migration as small reversible phases using the strangler fig pattern, with data strategy, verification and rollback per phase. Use instead of a big-bang rewrite.

Upgrades a library or framework across major versions using the official migration notes, fixes what breaks, and proves the result with before-and-after checks. Use for any breaking upgrade.

Moves a Python or TypeScript codebase to strict type checking one module at a time, fixing real bugs found and ratcheting config so coverage never slides back. Use to adopt strict mode safely.

Finds N+1 database queries behind an endpoint, page or job by counting real queries, fixes them with eager loading or batching, and adds a query-count test so they do not return.

Measures a slow operation, profiles where the time goes, and makes it faster one verified change at a time, with before-and-after numbers. Use when an endpoint, command or function is too slow.

Measures a web app's JavaScript bundles, finds the largest avoidable contributors, and shrinks them with verified changes ranked by bytes saved. Use when page load is slow or a size budget is blown.

Interprets k6, JMeter, Locust or Gatling results, finding the knee where latency climbs, separating load-generator limits from server saturation, and judging the pass criteria.

Produces an ordered response plan for an exposed key, token or password - revoke and rotate, audit use, clean up copies, notify and prevent. Use right after a secret is committed, logged or shared.

Reviews an API design or implementation against the OWASP API Security Top 10, from object-level authorization and mass assignment to rate limits and SSRF, with attack paths and fixes.

Reviews AWS, GCP or Azure IAM policies for over-broad permissions, privilege-escalation paths, wildcard resources and missing conditions, and proposes least-privilege versions.

Reviews a diff for exploitable vulnerabilities and reports only findings with a concrete attack path. Use before merging changes to input handling, auth, data access or dependencies.

Fixes accessibility issues across a web app with a scan, keyboard and accessibility-tree checks, small fixes, a re-scan and a list for human testing. Use to clear accessibility debt in a sprint.

Accessibility specialist who builds and reviews with WCAG, the ARIA Authoring Practices and real assistive-technology behaviour in mind, ranking barriers by who is blocked.

Audits a game build or design for motor, vision, hearing and cognitive barriers using the Game Accessibility Guidelines and Xbox Accessibility Guidelines, ranked by players helped per effort.

Audits HTML email code for screen-reader and low-vision problems specific to email clients, then returns fixed markup that still renders across Outlook, Gmail and Apple Mail.

Acts as a data engineer who designs for idempotency, backfills and observability, treats schemas as contracts with their consumers, and asks who depends on each table before changing it.

Designs a batch or streaming data pipeline sized to stated volumes, covering sources, schedule, idempotency, late data, backfills and monitoring. Use before building or replacing a pipeline.

Designs a relational schema from requirements and access patterns, with keys, constraints, types, indexes and DDL. Use when starting a new service or feature that stores data.

Designs a dimensional model from the questions analysts need answered: business processes, grain, facts, dimensions, slowly changing dimension types and DDL. Use when building a warehouse layer.

Implements a Model Context Protocol server exposing the given tools and resources, with input validation, least privilege and error messages a model can act on. Use to connect a system to AI clients.

Builds an LLM step that turns documents into schema-valid JSON, with the schema, prompt, validation and repair loop, null handling and an eval set. Use when automating invoices, forms or emails.

Recommends rules, classical ML, a hosted LLM or a fine-tuned model for a problem, comparing accuracy, cost, latency and maintenance with the reasoning shown. Use before committing to an approach.

Designs an LLM agent system, deciding first whether an agent is needed, then single or multi-agent, tools, memory, guardrails, human checkpoints, evals and cost limits.

Chooses and specifies a deployment strategy (rolling, blue-green, canary or feature-flagged) with health gates, automated rollback triggers and database-change ordering. Use when deploys feel risky.

Reviews a Dockerfile for security, image size, build cache use and runtime correctness, and returns ranked findings with a corrected file. Use before shipping an image, or when one is too big.

Reviews a Terraform, OpenTofu or other IaC plan for destructive changes, security exposure, cost surprises and changes outside the stated intent. Use before running apply, especially in production.

Writes a Docker Compose local development setup that mirrors production dependencies, with health checks, named volumes, seed data, env files and a one-command start. Use when onboarding developers.

Plans and adds logs, metrics and traces using OpenTelemetry conventions, golden signals, useful log fields, cardinality limits and first dashboards. Use when a service is hard to debug in production.

Plans a game day or chaos exercise with failure scenarios, hypotheses, blast-radius limits, abort criteria, roles, an observation checklist and a follow-up review. Use to test resilience.

Turns a firing production alert into a severity call, the safest mitigation to try first, ranked hypotheses and the next checks. Use in the first minutes of an incident or page.

Writes a clear status update for an ongoing incident, tuned to customers, internal teams or executives, without speculation or promises the team cannot keep. Use for status pages, Slack and email.

Recovers commits, branches, stashes and staged files lost to a reset, rebase or dropped stash, using reflog and fsck after a backup, explaining each command. Use right after a git mistake.

Resolves merge, rebase or cherry-pick conflicts by reading both sides and their common base, keeps the intent of each, and asks when the intents contradict. Use when git stops on a conflict.

Writes a commit message that states what changed and why, in the repo's own convention, and flags staged changes that should be split. Use before committing.

Writes a pull request description that tells reviewers why the change exists, what to look at first, how to test it and what could break. Use when opening a PR.

Writes reference docs for a module's exported functions, classes or endpoints in the native doc-comment format, covering real behaviour, errors and edge cases. Use before a release.

Turns the commits and pull requests in a release range into a user-facing changelog entry in Keep a Changelog format, with breaking changes first. Use when cutting a release.

Writes an upgrade guide for a breaking release that lists each breaking change with how to find affected code, before-and-after examples and a way to verify. Use when shipping a major version.

Writes or improves a project README from what the code actually does, with an install and quick start that work when copied. Use for a new project or a README that has drifted.

Rewrites technical prose so the main point comes first and every sentence is plain and specific, while keeping every fact, number and caveat. Use on design notes, emails, RFC drafts and docs.

Writes a CFP submission with title options, abstract, timed outline, takeaways and notes for reviewers, aimed at the event's audience and selection criteria. Use for engineers and developer advocates.

Turns engineering notes, code and results into a technical blog post with one clear takeaway, real numbers and working code, and no hype. Use for engineering blogs and write-ups of a project.

Acts as a developer advocate who earns attention by teaching, builds demos that work on the first try, carries user feedback back to maintainers and discloses affiliation every time.

Explains an unfamiliar codebase. Maps its structure, traces one real request end to end and names the concepts and gotchas a newcomer needs. Use when joining a project or reading an unknown repo.

Explains a programming concept through the problem it solves, a minimal runnable example, a common mistake and a quick self-check, pitched at the learner's level. Use to learn or teach a concept.

Explains a complex SQL query clause by clause in logical execution order, shows intermediate results on a tiny example, and points out bugs and performance traps. Use when inheriting a query.

Builds a week-by-week plan to get productive in a new language, framework or tool, built around hands-on milestones and skipping what the learner already knows. Use when picking up a new stack.

Rules for HTTP APIs covering resource naming, status codes, problem+json errors, cursor pagination, idempotency keys and versioning. Load when designing or changing HTTP endpoints.

Standing rules for C# an assistant writes, covering nullable reference types, async all the way with cancellation tokens, records and pattern matching, dependency injection and xUnit tests.

Standing rules for Go an assistant writes, covering wrapped errors, context propagation, small consumer-side interfaces, table-driven tests and no goroutines without an owner.

Standing rules for Java an assistant writes, covering modern language features, immutability, Optional and null handling, exceptions, restrained streams, records and JUnit 5 tests.

Takes an English-only app to its first extra language in gated steps, from readiness scan and string extraction to formatting fixes, pseudo-localisation, translation hand-off and linguistic QA.

Designs the pipeline between a repo and translators, with key extraction, upload to a translation system or vendor, download of finished locales, CI checks for keys and fallbacks, and approvals.

Builds a product term base from UI strings, with definitions, do-not-translate terms and proposed translations per locale, so localization stays consistent. Use before the first translation round.

Designs form fields, validation and storage for personal names, postal addresses and phone numbers that work across countries. Use for international sign-up, checkout or shipping forms.

Reviews a coding agent session transcript for where it went wrong (bad assumptions, skipped verification, scope creep, looping) and turns each failure into an instruction-file or prompt change.

Writes a self-contained handoff note so a fresh agent or a teammate can continue the current task without the conversation history. Use before ending a long session, switching tools or delegating.

Writes a reusable agent skill (SKILL.md with frontmatter, steps, scripts and references) from a repeated task, with a trigger description models can match and a test plan. Use to package a workflow.

Writes or updates a repository's AGENTS.md with the verified commands, layout, conventions and boundaries a coding agent needs, and nothing generic. Use when setting up a repo for coding agents.

Analyses raw email headers for the delivery path, SPF, DKIM and DMARC results, alignment, spoofing signs and relay anomalies, explaining each finding in plain words for analysts and support staff.

Analyses a packet capture summary from a tool's output to identify protocols, suspicious connections, beaconing and data transfer patterns, and suggests filters and checks to inspect next.

Explains what a suspicious script or obfuscated command does for defenders, deobfuscating step by step, extracting defanged indicators and rating risk, without improving or weaponising it.

Builds a forensic timeline from parsed host and log artefacts, normalising time zones, correlating events, separating attacker actions from normal activity and listing evidence gaps.