Use this skill whenever the user wants to capture, clone, or codify their own (or someone's) writing voice into a reusable skill. Trigger phrases include: "build a write-like-me skill", "build a sound-like-me skill", "analyze how I write", "make agents write or draft in my voice", "learn my style from my docs and…
Turn a vague or underspecified task into a crisp requirements + testable acceptance-criteria document by closing the gap between what was asked and what is actually wanted. Use at the start of any non-trivial task before planning, whenever the goal is fuzzy ("make it faster", "make it more robust", "add validation")…
Create a single well-formed git commit from the working changes, following the repo's AGENTS.md and recent commit-message conventions. Use when the caller wants only to commit — not push and not open a PR (for that, use open-pr).
Deliver one change end to end as a single pull request — clarify → plan → implement → simplify → review → validate → open-pr — resuming from wherever it left off. Use to take a task from intent to an open, mergeable PR with each phase run as a focused sub-agent. This is the default workflow the binary launches when…
Build a verified, read-only understanding of a codebase or a slice of it — entry points, code flow, architecture, module boundaries, dependencies, data flow, build/test systems, and existing patterns. A shared sub-skill that clarify, plan, implement, and review call on demand when they need codebase context; not…
Execute an implementation plan (from plan) task by task, writing the code and tests and leaving the system green at every step. Use once you have an agreed plan or a clear next slice of work to build. It does not plan and does not open a PR — it turns a plan into working, tested code.
Stage, commit, push, and open a pull request following the author's repository and AGENTS.md conventions — repo-style commit messages, a prose PR summary, and a Testing Done command list. Use when work is finished and the caller wants it committed and a PR opened. Supports --draft and an optional local review before…
Turn a clarified requirements artifact into a concrete, executable implementation plan — a decisive architecture blueprint and a phased build sequence with exact file paths. Use after requirements are pinned down (e.g. by clarify) and before writing code, whenever a multi-step change needs a design and a task…
Bring a PR to mergeable — fix CI failures, address review comments, and resolve merge conflicts. Runs either from a supplied watcher worklist (delegated mode, one pass) or from its own assessment (direct mode, looping until clear). Use after opening a PR when CI is red, reviewers have left comments, or the branch…
Handle one pull request attention event end to end — read the watcher digest, triage it, delegate the fixing to pr-fix, re-observe the pull request, and exit. Use when the PR watcher wakes you, or run it manually for a one-shot check of an open PR.
Review a change for correctness, quality, and guideline compliance using a library of specialized reviewer roles. Use before opening a PR, after finishing a chunk of work, or to review an existing PR. Two output modes — a local severity-ranked report for a fix loop (default), or inline GitHub comments (--comment).…
Review code for adherence to project guidelines, style guides, and best practices. Use after writing or modifying code, especially before committing changes or creating pull requests. Checks for style violations, potential issues, and adherence to the patterns in the repo's guideline files. The reviewer needs to know…
Analyze code comments for accuracy, completeness, and long-term maintainability. Use after generating large documentation comments or docstrings, before finalizing changes that add or modify comments, when reviewing existing comments for technical debt or comment rot, and when verifying that comments accurately…
Review a change against the history of the code it touches. Use git blame and log to catch changes that contradict why the surrounding code exists — reintroducing a fixed bug, removing a guard that was added on purpose, or undoing a deliberate decision. Reports only high-confidence findings backed by a specific past…
Review a set of changes for test coverage quality and completeness. Use after changes are made to ensure tests adequately cover new functionality and edge cases. Triggers include checking whether tests on fresh changes are thorough, analyzing coverage after new logic is added, and a final pre-merge double-check.
Review a change against prior pull requests. Use the PR/commit history to catch an approach that was already tried, discussed, or reverted — so the change does not re-litigate a settled decision or redo work that was rejected. Reports only high-confidence findings backed by a specific prior PR or revert.
Security review of a change. Use when the diff touches a trust boundary, parses input, handles auth/authz, moves user or secret data, shells out, or feeds untrusted text to an LLM. Runs a fast STRIDE pass and reports only high-confidence, exploitable findings with a concrete fix.
Review code changes to identify silent failures, inadequate error handling, and inappropriate fallback behavior. Use proactively after completing work that involves error handling, catch blocks, fallback logic, or any code that could suppress errors.
Expert analysis of type design. Use when introducing a new type to ensure it follows best practices for encapsulation and invariant expression, when reviewing all types being added in a change, and when refactoring existing types to improve their design quality. Provides both qualitative feedback and quantitative…
Reduce complexity in recently changed code — cut needless abstraction, dead code, and duplication; improve names and structure — WITHOUT changing behavior. Quality only; it does not hunt for bugs (use review for that). Use after implementing a chunk of work, before review, or whenever a diff feels more complicated…
Use only for a standalone stack explicitly launched with relay --workflow stack-ship; never invoke inside a tech-lead-managed Relay program. Decompose one goal into small PRs, delegate build and monitor work, surface author decisions, and auto-merge only after human approval.
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: