swe

Plugin swe from marketplace agent-toolbox in kpeez/agent-toolbox. Commands read from the repo's manifest — 3 days ago.

Skills (59)

• architect

  Sketch types, signatures, and module structure in parallel competing designs before code, then stay in the loop while implementation fills in. Use for 'architect this', or code that crosses a function boundary where jumping to code would lock in the wrong shape.

• benchmark-checklist

  Vet a performance number (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it.

• blast-radius

  Find what a change could break beyond its diff, and prove the one fact it is safe because of by running real code. Use for 'blast radius', 'what could this break', or a risky diff before it ships.

• codebase-design

  Design a consequential new interface, or review existing module boundaries and propose deepening refactors that cut coupling and caller complexity. Report-only for reviews; implementation is separate.

• correct

  Stop a repeated agent mistake by fixing its class at the highest level that works: architecture, types, lint or check, test, docs last. Use when the user corrects a mistake agents have made before, or asks to encode a lesson.

• create-formal-verification-skill

  Formally verify one property where a bug costs the most and tests reach the least, then generate a project-local skill that rechecks it. Use for /create-formal-verification-skill, \"model-check this race\", \"prove this invariant\", or when concurrency, retries, state machines, parsers, or unsafe co

• diagnose

  Investigate bugs and performance regressions using focused evidence. Use when asked to diagnose, debug, or explain a failure.

• external-agents

  Run workers on another agent CLI, such as OpenCode or Antigravity `agy`: a few small questions in parallel, or a whole spec delegated for implementation that Claude then reviews and fixes. Use when the user asks for OpenCode, Antigravity, or agy workers, a swarm or second opinion on one, or to hand

• figure-it-out

  Design a bespoke, auditable playbook when no swe playbook fits or the work is large: a migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions.

• go-deeper

  Make a new task deeper, not bigger, before you start: what a top expert would do, the rawest source, the real methods and tools, and a check outside you and the user. Use first on any new task, request, or proposal. Skip chat, quick facts, and fully specified mechanical edits.

• handoff

  Write the current state of the work to its handoff file so a new session can continue it. Use when the user asks for a handoff, or before a session ends with work left to do.

• help

  Guide the user through swe setup, /swe:swe-mode, and the choice of a skill, playbook, or principle for a task. Type /swe:help with a question.

• how

  Explain how code works now: a subsystem's architecture, its runtime flow, or a walkthrough before you change it. Also for placement, ownership, and layering questions such as 'where should this live'. Use why for motivation.

• implement

  Implement an authorized feature or fix through relevant verification. Use for scoped code changes.

• in-your-own-words

  Restate in your own words the user's goals and the problem they are trying to solve.

• interview-user

  Interview the user, one round of questions at a time, until no plan or design decision is open. Use for 'help me decide', 'figure out the approach', 'interview me', 'hash this out', or before you build on scope or design the user has not decided.

• ketchup-video

  Catch the user up like /ketchup, with a short subtitled video of slides for what happened and the waiting calls as text under it. Use for /swe:ketchup-video.

• ketchup

  Catch the user up on what changed in this chat since their last message, in plain words and small visuals. List every item waiting on them with what they need to decide it from the reply alone.

• log-decisions

  Keep an append-only log of each decision in a long, multi-phase, or unattended run, so a reviewer can audit the work later. Use when the user asks for a decision log, or before such a run starts.

• maintain-formal-verification-skill

  Bring a project's formal verification back in line with the code after the code changes: find the commits that touched verified code, update the model, harness, or properties to describe the code as it is now, rerun, and say whether each failure is drift in the verification or a bug in the code. Use

• no-comments

  Spawn Comment Sicko to delete comments, fix the accepted findings, and offer encodings for claimed constraints.

• principle-ancillary-fixes

  When you find an issue outside the task, such as a stale doc, a conflict, a bug, or an unrelated failing check, decide whether to fix it now or report it.

• principle-attack-the-premise

  When two or more fixes that share one premise have failed the same check, stop fixing, write the premise down, and test it before the next fix.

• principle-boundary-discipline

  When you wire validation, error handling, or framework adapters, concentrate guards at system boundaries, trust internal types, and keep business logic in pure functions.

• principle-build-the-lever

  When work is not trivial, such as edits, a migration, an analysis, or a check, build the script, codemod, or generator that does it or proves it instead of working by hand.

• principle-encode-lessons-in-structure

  When you catch yourself writing the same instruction a second time, or see a recurring correction, encode the rule as a lint, metadata flag, runtime check, or script instead of more text.

• principle-exhaust-the-design-space

  When you face a novel UI interaction or architectural decision with no precedent in the codebase, build two or three competing prototypes and compare them side by side before you commit.

• principle-experience-first

  When a product, UX, or feature-scope tradeoff comes up, choose the user's experience over implementation convenience and ship fewer polished features over more rough ones.

• principle-explain-the-number

  Before you measure, and before you trust, report, or act on a number you measured, such as a speedup, a regression, a throughput, a latency, or an eval result, find what limits it and rule out that it measured something else.

• principle-fix-root-causes

  When you debug a failure or are about to apply a fix, trace the symptom back to the first place the system went wrong and fix it there. A guard is a fix only when the state it handles is legitimate.

• principle-foundational-thinking

  Before you write logic, choose the core types and data structures, decide what comes before what, and ask what concurrent actors share, so that the downstream code becomes obvious.

• principle-guard-the-context-window

  When context fills up with large outputs, long files, repeated reads, or fan-out planning, route the bulk to subagents and keep only summaries in the main thread.

• principle-laziness-protocol

  When you refactor, size a diff, or want to add an abstraction, a layer, or a threaded signal, bias toward deletion and the smallest change that solves the problem.

• principle-make-operations-idempotent

  When you design a command, a lifecycle step, a job, a retry, or a processing loop that runs amid crashes, restarts, and retries, make every rerun reach the same end state.

• principle-migrate-callers-then-delete-legacy-apis

  When a new internal API or module shape replaces an old one while old callers still exist, migrate every caller and delete the old API in the same wave.

• principle-minimize-reader-load

  When you review or shape code that is hard to trace, count the layers a reader must follow and the state they must hold, then collapse wrappers and shrink mutable scope.

• principle-model-the-domain

  When you write stateful logic, or code branches a lot or repeats a shape assumption across files, encode the domain in a data structure instead of scattered conditionals. In existing code, find implicit state machines and make them explicit.

• principle-never-block-on-the-human

  When you want to ask \"should I do X?\" about reversible work, do X, present the result, and let the human course-correct afterward.

• principle-outcome-oriented-execution

  During a planned rewrite or migration with explicit phase boundaries, converge on the target architecture instead of keeping intermediate states smooth with throwaway compatibility code.

• principle-prove-it-works

  Before you claim that a task is done or a change works, check the real artifact through its real entry point and give a VERIFIED, NOT VERIFIED, or INCONCLUSIVE verdict.

• principle-redesign-from-first-principles

  When you integrate a new requirement into an existing design, redesign as if the requirement had been a foundational assumption from the start instead of bolting it on.

• principle-separate-before-serializing-shared-state

  When concurrent workers, processes, or agents might write the same file, branch, key, or state object, remove the sharing first and serialize only when one shared writer is a real invariant.

• principle-sequence-verifiable-units

  When work has several steps, such as a sweep, a migration, or a run of similar edits, or when you stack commits and PRs, split it into small units and check each before the next.

• principle-subtract-before-you-add

  When you sequence an addition, a refactor, or a rewrite, remove dead code, redundant checks, and stub references first, then build on the simpler base.

• principle-test-behavior-not-implementation

  When you write, change, or keep a test, assert what the code's users can observe, so that the test fails when that behavior breaks and keeps passing when only the internals change.

• principle-type-system-discipline

  When you design types, review a function signature, or write code in a statically typed language, make the compiler reject impossible states, mixed-up primitives, and unhandled variants.

• recall

  Rebuild your recent working context from this project's chat history, handoff file, live state, and the shared record, then hand back a tight current-state brief.

• reflect

  Run three parallel reviewers over this session's transcript, surface durable learnings, and route each to a concrete skill edit or a structural fix.

• ship-pr

  Commit, push, and open or update a draft PR; fix a failing PR check or CI, review threads, or conflicts on an open PR; mark a PR ready or merge it.

• statechart

  Check a TLA+ model of a system that moves between states, such as a product flow, a protocol, or a service, and draw it as a Mermaid statechart. The report gives the shortest path to each state that breaks a rule. Use for /swe:statechart, or to show a bug as a path through states.

• swarm

  Fan out N parallel workers, drain them, and return one report. Use for parallel coverage matrices, races, gauntlets, exploration partitions, and verifier lanes.

• swe-mode

  Route a software task to its playbook and track every step. Use for /swe:swe-mode, or when the user asks which swe workflow fits a task.

• testing-code

  Gate, design, and audit tests. Use before adding or rewriting any permanent test, for probes, TDD, regression coverage, testing strategy, and judging a diff's tests. Also for reviewing or pruning existing test suites.

• typescript-best-practices

  TypeScript best practices. Use when reading or editing any .ts or .tsx file.

• verification-skill

  Create or maintain this project's verification skill: a reusable way to launch, drive, and observe the real app, plus a feature map. Use when the user asks for a verification skill or to audit one.

• wait-what

  Re-pitch the last message with more context in simpler words. Use when the user says they do not follow, or asks to re-pitch.

• why

  Trace why code, a config, or a decision exists through git and gh history, Linear, Slack, and project docs, with a confidence tier on every claim. Use for design rationale or regression history; not for how code works now.

• writing-for-agents

  Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.

• writing

  Write or edit prose: a README, a docs page, a skill or AGENTS.md, a PR body, a commit message, a handoff, a plan, or a reply. Use when you create or edit one, or when a change makes one stale.

Subagents (2)

• comment-sicko

  A deranged comment-hater that savors deletion and condemns workaround code. Deletes comments in a scoped diff and flags the code they excuse.

• daedalus

  Executes one bounded workspace task under caller-supplied constraints, including code, tests, documentation, and tracker tasks.

Hooks (3)

• SessionStart

  cat "$CLAUDE_PLUGIN_ROOT"/hooks/session-start.md

• PostCompact

  python3 "$CLAUDE_PLUGIN_ROOT"/scripts/handoff.py hook

• PreToolUse

  python3 "$CLAUDE_PLUGIN_ROOT"/skills/ship-pr/scripts/pr_body.py hook

Similar plugins