Claude Skills by ronaknnathani

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 PRs", "generate a voice profile from my github", "stop the agent sounding like a robot when it writes for me", "turn my docs and PRs into a personal style guide". It gathers a corpus...

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"), or whenever you cannot predict how the user would judge "done". Its output feeds `plan`. (For tidying existing code, use `simplify`, not clarify.)

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 you create a new project (`relay "<task>"`).

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 invoked directly by users. Never edits anything.

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 push.

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 breakdown. Its output feeds `implement`.

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 conflicts with its base.

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.

Use when you need to rebase the current branch onto main, resolve merge conflicts, and force-push

Use when a project's PR is merged and you want to clean up the worktree while preserving notes and plans

Use when checking the status of active or archived development projects

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). Scores every finding for confidence, filters the noise, and delegates each role adversarially.

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 than the problem it solves. Triggers on "clean this up" / "tidy this" / "refactor this" when code already exists; for an underspecified goal with no code yet, use `clarify`.

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.

Manage a Relay program as the CEO-facing tech lead: shape goals and contracts, prioritize dependency-aware work, dispatch senior worker agents, and surface every decision without writing production code or merging.

Capture, list, and complete repo-scoped todos

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 gates (lint/build/test), not a code critique (use `review` for that). It reports — it does not fix (route failures to `pr-fix`/`implement`) and does not ship.

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 under their name and needs to sound like them, not like a generated reply.