sudo-labs-uk/sudo
A curated product workflow with planning, implementation, review, verification, release and prose skills.
Check a finished change against the acceptance criteria written into its ticket, as a fresh agent that took no part in the build, and report evidence per criterion.
Rewrite, check, or draft prose so it carries no AI writing tells, reads plainly on the first read, and keeps every source fact. Use when asked to make writing plainer or free of those tells, to check writing for them, or when drafting from supplied content. Use ce-promote for channel-specific marketing copy.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Cut a release: check the branch is clean and green, work out the version from what changed, write the notes from the merged work, tag it, and publish.
Audit a design against Dieter Rams' ten "Good design is..." principles, then hand off a /make-plan prompt for one of three outcomes — new design, refine design, or redesign. Use when the user says "audit this design", "design review", "check this UI against Rams", "is this UI good", "critique this design", "design audit", or asks for a critique that should lead to a plan.
A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.
Rewrite AI-sounding text so it reads like the writer without changing what it says. Use when editing or reviewing prose for AI tells: not-X-but-Y contrasts, one-line closers, staged openers, forced triads, dashes everywhere, inflated claims, sales language, stock AI words, bold labels, or filler. Based on Wikipedia's "Signs of AI writing."
Implement the result of /to-spec and /to-tickets in code.
Map a codebase into feature-grouped flowcharts, identify duplicated concerns across features, and propose a unified architecture. Use when asked to "find the ideal path," unify duplicated systems, or audit architecture before a refactor. Emits a proposed unified flowchart plus per-system /make-plan prompts.
Use when writing a PR body.
Help the user understand the current topic visually with concise diagrams, code-shape sketches, and focused HTML artifacts.
Configure a repo for the sudo skills: the Linear team the specs go to, the GitHub repo the tickets go to, and the stack. Run once per repo, before the other skills.
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Turn the current conversation into a spec and publish it to Linear: no interview, just synthesis of what you've already discussed.
Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published as GitHub issues with native blocking links.
Verify what a user actually sees after a UI change: drive the running app, capture each state as a screenshot, and report what matched the acceptance criteria and what did not.