alisterpineda/swe
Software-engineering workflow skills: diagnose bugs from tickets, specs, or a description down to their root cause, turn a design conversation into a spec file, plan how to build a spec, tickets, or an agreed design against the real code, step by step with the test each step writes first, implement it with the session's model orchestrating worker subagents on a cheaper model, review code for correctness, the repo's written standards, and conformance to a spec, then commit with staging and message conventions and write the PR title and description.
Review a diff for bugs, the repo's written standards, and spec conformance, with every finding verified before the report. Report-only; with no target, reviews staged changes, else all uncommitted ones.
Commit changes: stage the task's files by name, write the message, and run the commit. Use whenever the user asks to commit changes, make a commit, or write a commit message, even if they don't mention staging or formatting.
Investigate one or more bugs down to their root cause, without fixing them. A bug can come from GitHub issues, Azure DevOps work items, a spec whose code misbehaves, a bug-report file, a free-text description, or the conversation, and related items can go in one run. Reproduces where it can, labels each root cause confirmed, likely, or hypothesis, groups the items by cause, and hands off to /swe:plan through an Agreed fix block, or adds the fix's criteria to the target spec. Usage: /swe:diagnose [target …] [context]. User-invoked only.
Ticket-fetch engine for other skills: reads GitHub issues and Azure DevOps work items, read-only, and returns each one normalized, with every author marked on-project or outsider and outsider text flagged held back. Call it when a skill's instructions name it, with the ticket URLs as arguments.
Implement decided work: a plan, a spec, GitHub issues, Azure DevOps work items, or what the conversation agreed. The session's model orchestrates: it splits the work into units, hands each well-specified unit to a worker subagent on a cheaper model, builds the tiny and the judgment-heavy ones itself, and checks every unit itself before the next starts. Leaves every change uncommitted. Usage: /swe:implement [--worker-model <name>] [target …] [context]. User-invoked only.
Write an implementation plan: how to build a spec, GitHub issues, Azure DevOps work items, or what the conversation agreed, worked out against the real code. One file, under .scratch/ (or an existing, gitignored .local/) unless the repo's instructions name a location: goal, acceptance criteria, decisions, cautious readings, checks, slices only for work bigger than one session, and numbered steps that each name their criteria, files and symbols, the test to write first, and the check that shows the step is done. Asks only about choices a user would notice: once before drafting, and again only when a review finding needs one. An independent subagent reviews the plan, up to 3 rounds. Changes no code. Usage: /swe:plan [target …] [context]. User-invoked only.
Write a pull-request title and description for a branch's net change and print them for pasting; it doesn't open the PR. Use whenever the user asks for a PR title, description, or write-up, or needs the text for a PR they're about to open, even casually ("write me a PR", "what should the PR say"). Not for summarizing or reviewing a PR that already exists.
Turn the current conversation into a spec file, under .scratch/ (or an existing, gitignored .local/) unless the repo's instructions name a location: problem, goals, decisions, acceptance criteria, open questions, or the sections of the repo's own spec template. Usage: /swe:spec [context], where context narrows the scope and names the file. User-invoked only.