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, looping until checks are green and every comment is handled. Use after opening a PR when CI is red, reviewers have left comments, or the branch conflicts with its base.
Monitor one open PR until it is merged — each tick detect CI failures, review comments, staleness, and conflicts, delegate the fixing to pr-fix, re-arm auto-merge, and stop at merge. Use after open-pr to drive a PR to merged with near-zero steering, via a native loop when one exists or one bounded tick per resume…
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).…
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 when given a design doc or feature goal to deliver end-to-end as a stack of small PRs, or to resume an active stack. Decompose into acceptance criteria and an interface-first PR plan, delegate build and monitor work, keep durable state, use native loop/goal harnesses when available, use capability-based monitor…
Verify a change is ready to ship by checking it against its acceptance criteria and running the repo's own quality gates in order, then report a pass/fail verdict with the exact failures. Use to decide go/no-go right before shipping — when you want a pass/fail verdict against acceptance criteria and the repo's quality…
Write or edit prose in author's voice, or check that a draft sounds like them. Use for blog posts, design and strategy docs, PR descriptions, commits and review comments, chat / agent instructions, peer feedback, or any first-person writing on their behalf, and whenever an agent is producing text that will go out…
★not rated 3 7d agoA83 tokens
originalMIT
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: