Dev & automation

Code review and automation skills for people who ship software.

15 of 15 skills

type

Release Notes Writer
Turns commits and merged PRs since the last tag into a changelog draft worth shipping.
skillinstructionsworkflowchangelog-templatemigration-notes
by Muse Skills editors · Written for this directory
ViewInstall the "Release Notes Writer" skill. Its full source is below. Create it at ~/workspace/skills/release-notes-writer/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: release-notes-writer description: Turns commits and merged PRs since the last tag into a clean changelog or release-notes draft, grouped by breaking changes, features, fixes, and chores. Trigger phrases: "write release notes", "draft a changelog", "summarize this release", "what changed since v", "cut release notes". --- # Purpose Do one narrow job: turn the raw history since your last release tag into release notes a human would be proud to ship. Point it at a repo and a tag (or the previous release), and it reads the commits and merged PRs in between, groups the changes by impact (breaking changes, new features, fixes, chores), and drafts notes written for the reader of the release, not the author of the commit. It names what changed, who it affects, and how to migrate when behavior changed. # Workflow 1. Identify the range: the previous release tag and the current HEAD (or the new tag you are about to cut). Confirm both with the user if they are ambiguous. 2. Collect the raw material: commit subjects since the previous tag, plus merged PR titles and labels when the repo uses them. 3. Sort every change into groups: Breaking changes, New features, Fixes, Chores and internals. Reword cryptic commit subjects into plain descriptions of what changed and why it matters to the person using the software. 4. For breaking changes, add a migration note: what the old behavior was, what the new behavior is, and the smallest change a user must make. 5. Draft the notes in a standard shape: version header, highlights line (the two or three changes that matter most), then the grouped lists. Keep each bullet to one line. 6. Present the draft and ask which entries to cut or keep before finalizing. Never invent changes that are not in the commit history. # Output Contract - A version header with the new tag and date - A highlights line: the two or three most important changes - Grouped bullets: Breaking changes, New features, Fixes, Chores - Migration notes attached to every breaking change - A note on any commit that could not be classified, rather than dropping it silently # Operating Rules - Never invent a change that is not in the commits or merged PRs. - Never bury a breaking change in the fixes list; it always gets its own group and a migration note. - Write for the reader of the release, not the author of the commit: plain words, no internal jargon. - Keep bullets to one line; cut entries the user flags as noise. - Ask which tag range to use when it is ambiguous, instead of guessing.
Release Radar
Watches the repos you name and summarizes new releases, skipping the noise.
skillinstructionsworkflowrepo-watch-list
by Muse Skills editors · Written for this directory
ViewInstall the "Release Radar" skill. Its full source is below. Create it at ~/workspace/skills/release-radar/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: release-radar description: Watch a list of repos for new releases and get a short summary of the ones that matter to you. Trigger phrases: "what did I miss", "repo updates", "new releases", "check release radar". --- # Purpose Do one narrow job: keep you current on the projects you actually use. You name the repos you care about, and on each check the skill looks for releases newer than the last check, reads the release notes, and gives you a short rundown of what changed and why it might matter. Everything it reports is marked as seen, so you never read the same release twice. # Workflow 1. Set up your watch list: repo names (owner/name) plus one line on why each matters to you, for example "my blog's framework" or "the linter in CI". Add or remove entries anytime. 2. On each run, check every repo for releases newer than the last recorded check. Record a timestamp and the newest release seen per repo. 3. For each new release, read the release notes and write a two to four line plain-language summary: the version, the headline change, and who should care. Flag breaking changes, security fixes, and new features. 4. Rank the summaries: breaking changes first, then security fixes, then features, then everything else. Bugfix-only patch releases get one line, never a paragraph. 5. Mark everything reviewed as seen, so the next check reports only what is new. A repo with no new release is not mentioned; silence is the correct output for a quiet week. 6. When release notes are vague, say so and link the release page instead of guessing what changed. # Output Contract - Per repo with a new release: version, headline summary (2-4 lines), and flags: breaking change, security fix, or feature - Order: breaking changes, then security fixes, then features, then patch notes - Quiet repos: omitted entirely - End with the count of repos checked and the count with new releases Keep the whole digest under 25 lines unless the user asks for more. # Operating Rules - Never invent release details. If the release notes are empty or vague, link the release page and say the notes are thin. - Never mark a release as seen without reporting it first. - Do not clone repositories or run code; read release metadata only. - Never access private repositories unless the user explicitly names the repo and provides a way to read it in this session. - Never recommend upgrading a dependency. Describe what changed; the user decides. - If a check fails for a repo (rate limit, moved repo, 404), report the repo name and the failure, and try again next run.
Dependency Update Triage
Turns a scary outdated-dependencies list into safe-now, review, and hold buckets.
Tested in Museskillinstructionsworkflowreport
by Muse Skills editors · Written for this directory
ViewInstall the "Dependency Update Triage" skill. Its full source is below. Create it at ~/workspace/skills/dependency-update-triage/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: dependency-update-triage description: Classify outdated dependencies into safe-now, needs-review, and hold buckets from package manager output, with an upgrade order. Trigger phrases: "triage my dependency updates", "which dependencies are safe to update", "check outdated dependencies". --- # Purpose An outdated-dependencies list is a wall of version numbers that hides the two or three updates that actually matter. Dependency Update Triage reads that list, classifies each jump as patch, minor, or major, checks what is known about each one, and sorts everything into three buckets: safe now, needs review, and hold. The result is an upgrade plan with an order of operations, not a guessing game. # Workflow 1. Collect the outdated list. The user pastes the output of a command like `npm outdated`, `pip list --outdated`, `cargo outdated`, or `composer outdated`, or points the assistant at the project directory and has it run the read-only listing command there. 2. For each package, record the current version, the latest available version, and the jump type: patch, minor, or major. 3. For every major jump, look at the actual changelog or release notes. Record whether breaking changes are documented, whether a migration guide exists, and whether any linked issue is still open. 4. Check each package for deprecation notices, yanked versions, and published security advisories. Note the source of each finding. 5. Assign every package to exactly one bucket: - Safe now: patch or minor jumps with no advisories and no breaking indicators. - Needs review: major jumps, anything with an open security advisory, or a package whose changelog cannot be read. - Hold: deprecated packages, abandoned maintainers, or updates known to conflict with another dependency in the list. 6. Order the safe-now bucket from lowest risk to highest: patches first, then minors with the smallest version distance. 7. Write the report in the Output Contract shape and send it. # Output Contract One line per package, grouped by bucket in this order: Safe now, Needs review, Hold. Each line carries: - Package: name - Current to latest: "1.4.2 to 1.4.9" - Jump: patch, minor, or major - Note: one short reason for the bucket (for example, "major with migration guide" or "CVE-2026-1140 fixed in latest") End with a suggested order: apply Safe now first, lowest risk to highest, then tackle Needs review one at a time. Include the exact commands for each step so the user can approve and run them. # Operating Rules - Never run an install, upgrade, or migration command without the user approving that exact command first. - Never edit package.json, requirements files, Cargo.toml, lockfiles, or vendored code. Classification is read-only work. - Never invent changelog contents. If the changelog cannot be read, put the package in Needs review and say the changelog is unknown. - Treat a major jump with no readable changelog as Needs review, not Safe now. - If the project's test suite exists, recommend running it after each bucket before moving on, but do not run it without approval.
Git Commit Writer
Your diff in, conventional-commit message out.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall the "Git Commit Writer" prompt pack. Its full source is below. Save it to ~/workspace/prompts/git-commit-writer.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack writes a conventional commit message from your diff. Paste it into Muse along with the diff. > Write a conventional commit message for this diff. Format: > type(scope): short imperative summary, max 72 chars. Then a > body of 2-4 lines explaining what changed and why, not how, > the diff shows the how. Rules: (1) pick the right type > (feat, fix, docs, refactor, test, chore), (2) if the diff > mixes unrelated changes, say so and suggest splitting into > two commits instead of writing one message, (3) flag anything > that looks like a secret or credential in the diff before > anything else, (4) no filler words like "various" or > "updates". Do not commit; just write the message.
README Writer
Points at a repo, gets a real README draft: setup, usage, config.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall the "README Writer" prompt pack. Its full source is below. Save it to ~/workspace/prompts/readme-writer.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack drafts a README from a repository. Paste it into Muse along with the repo path or contents. > Write a README for this repo. Structure: (1) one-paragraph > what and why, (2) quickstart, the exact commands to go from > clone to running, (3) configuration, every env var and > config file with what it does, (4) usage, the main commands > or API with one example each, (5) development, how to run > tests and contribute. Rules: every command must come from > the repo itself (package.json, Makefile, docs), never > invent a command, (2) mark anything you couldn't verify with > [unverified], (3) keep it scannable, headers, code blocks, > no paragraphs over 4 lines. Do not commit; just draft it.
Test Case Generator
Paste a function, get the test cases including the edge cases you'd skip.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall the "Test Case Generator" prompt pack. Its full source is below. Save it to ~/workspace/prompts/test-case-generator.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack generates test cases for a function. Paste it into Muse along with the function code. > Write test cases for this function in [framework]. Cover: > (1) the happy path with realistic inputs, (2) edge cases: > empty, null, zero, boundaries, and max sizes, (3) error > cases, invalid inputs and what the function should do with > each, and (4) one test for the bug most likely to hide here, > with a comment saying why it's likely. Rules: each test gets > a name that says what's being verified, no testing the > framework itself, and if the function is untestable as > written (hidden dependencies, no seams), say so and suggest > the smallest refactor that fixes it instead of writing > brittle tests.
Error Message Translator
Paste a stack trace; get what it actually means and likely fixes.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall the "Error Message Translator" prompt pack. Its full source is below. Save it to ~/workspace/prompts/error-message-translator.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack turns a cryptic error into a human explanation. Paste it into Muse along with the error text. > Translate this error message into plain English. Tell me: > (1) what the error actually means, in one sentence, (2) the > three most likely causes, ranked, with how to check each, > (3) the single most probable fix to try first, and (4) what > to search for if that fix doesn't work. Assume I know the > language but not this specific failure. Do not run anything; > reason from the message text.
New-Repo Setup Doctor
Fresh-repo checklist that ends 'works on my machine' syndrome.
Tested in Museskillinstructionsworkflowchecklist
by Muse Skills editors · Written for this directory
ViewInstall the "New-Repo Setup Doctor" skill. Its full source is below. Create it at ~/workspace/skills/new-repo-setup-doctor/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: new-repo-setup-doctor description: Diagnose a fresh repo checkout that won't build or run, environment, dependencies, and config checks in order, with the fix for each failure. Trigger phrases: "this repo won't build", "help me set up this repo", "diagnose my dev environment". --- # Purpose Fresh checkouts fail for boring reasons: wrong runtime version, missing env vars, a step the README forgot. This skill runs the checks in the order that finds the boring reason fastest. # Workflow 1. Ask the user for the repo path (or use the current directory) and what "working" means: builds, tests pass, dev server starts. 2. Run the checks in order, stopping at the first failure with its fix: - Runtime version vs. what the repo declares (.nvmrc, .python-version, go.mod, package.json engines) - Package manager and lockfile present; dependencies installed (node_modules, venv, etc.) - Required env vars / config files (.env.example vs .env) - External services the README mentions (database, redis) reachable or clearly mocked - Build / test / dev-server command from the README 3. For each failure: what failed, why it matters, the exact command or edit to fix it. Then re-run the check. 4. Report in the Output Contract shape. # Output Contract - Verdict: working, or the step it fails at - Checks: pass/fail per check, one line each - Fixes applied: what was changed, in order - Still broken: the failing step, the error, and the next thing to try # Operating Rules - Read-only diagnosis first. Propose every fix before running it; apply only what the user approves. - Never invent credentials. Missing secrets get a "create this" instruction, not a placeholder that gets committed. - Never commit, push, or force-install. The repo's history is the user's. - If the README's setup steps are wrong, say so and note the correction: that feedback is half the value.
SQL Explainer
Paste a query; get a plain-English walkthrough of what it does.
Tested in Museprompt packprompt-text
by Muse Skills editors · Written for this directory
ViewInstall the "SQL Explainer" prompt pack. Its full source is below. Save it to ~/workspace/prompts/sql-explainer.md (create the folder if needed). Then confirm it is installed and show me the full text. --- SOURCE --- This prompt pack turns any SQL query into a plain-English walkthrough. Paste it into Muse along with your query. > Explain this SQL query in plain English. Walk through it > clause by clause in execution order (not written order): > what each part filters, joins, or computes, and what the > final result set looks like. Then give: (1) a one-sentence > summary of what the query answers, (2) any performance > red flags you see: full table scans, unindexed joins, > SELECT *, N+1 patterns, and (3) one suggested rewrite if > a red flag is serious. Assume I know basic SQL. Do not > run the query; explain it from the text.
API Debugger
Paste the request and the error; get an ordered diagnosis checklist.
Tested in Museskillinstructionsworkflowdiagnosis-checklist
by Muse Skills editors · Written for this directory
ViewInstall the "API Debugger" skill. Its full source is below. Create it at ~/workspace/skills/api-debugger/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: api-debugger description: Diagnose a failing API call from the request and the error: an ordered checklist from most to least likely cause. Trigger phrases: "debug this API call", "why is this request failing", "diagnose this error". --- # Purpose Turn "it returns a 400 and I don't know why" into an ordered list of things to check, most likely first, instead of random guessing. # Workflow 1. Read what the user pastes: the request (method, URL, headers with secrets redacted, body) and the full error (status code, response body, and any SDK or client error text). 2. Classify the failure: auth (401/403), client error (400/404/ 422), server error (5xx), network/timeout, or SDK misuse. 3. Build the checklist ordered by likelihood for that class: - Auth: expired token, wrong scope, key in the wrong header, clock skew. - Client error: malformed body field, wrong content type, missing required param, URL encoding issue. - Server error: retry with backoff, check the provider status page, isolate with a minimal request. - Network: DNS, proxy, TLS version, firewall. 4. For each item, give the one concrete check to run ("decode the JWT at jwt.io and read the exp claim" beats "check your token"). 5. Report in the Output Contract shape. # Output Contract - Classification: one line (auth / client / server / network / SDK misuse) - Checklist: ordered items, each with the concrete check to run - Fastest test: the single quickest check that would confirm or rule out the top hypothesis # Operating Rules - Never ask for a real API key, token, or credential. If the user pastes one, tell them to revoke it and redact before continuing. - Never send any request on the user's behalf. Diagnosis only. - Order by likelihood, not by category textbook order. The most probable cause goes first. - If the error text is too thin to classify, say which two pieces of information would unblock the diagnosis.
Changelog Compiler
Weekly: commits in, release-notes draft out.
Tested in Museworkflowinstructionsworkflowschedule
by Muse Skills editors · Written for this directory
ViewSet up the "Changelog Compiler" workflow. Its full source is below. Default schedule: Friday at 17:00 local time. Ask me to confirm or change this time before you create the recurring job. Once I confirm, create the job and ask me which repos to include. Tell me the job name and the confirmed schedule when it is set up. --- SOURCE --- name: changelog-compiler description: Weekly digest of git history turned into a release-notes draft, grouped for humans. Trigger phrases: "compile the changelog", "what shipped this week", "draft the release notes". schedule: weekly, Friday at 17:00 local time (cron: 0 17 * * 5). Confirm the time with the user before the first scheduled run. trigger: the scheduled time, or a manual "compile the changelog" request. repo_list: the repos to include, set once with the user and remembered. steps: 1. Read the commit history since the last run for each repo in the list. 2. Drop noise: merge commits, version bumps, typo-only commits, and CI config churn, unless the user asks otherwise. 3. Group the rest for humans: Added, Changed, Fixed. One bullet per change, written as an outcome ("Checkout retries failed payments automatically"), never as a commit message. 4. Flag anything that looks breaking: migration, removed endpoint, changed default, renamed config. Put these first under a "Heads up" section. 5. Write the draft in the Output shape and send it. If nothing shippable landed, say so in one line. output: - Heads up (breaking or migration-worthy changes, if any) - Added / Changed / Fixed sections, one outcome-bullet each - Quiet weeks: "Nothing shippable this week." rules: - Never invent a change. Every bullet must trace to a real commit. - Outcomes, not commit messages. Rewrite ruthlessly. - Never commit, tag, or publish the changelog. Draft only. - Run only on the confirmed schedule or when asked.
Code Reviewer
Reviews a diff against its surrounding code and ranks bugs before style.
Tested in Museskillinstructionsworkflow
by Muse Skills editors · Written for this directory
ViewInstall the "Code Reviewer" skill. Its full source is below. Create it at ~/workspace/skills/code-reviewer/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: code-reviewer description: Repo-aware code review of a diff. Reads the changed lines and the surrounding file, then reports correctness bugs first, security issues second, and a minimal fix for each. Trigger phrases: "review this diff", "review my changes", "code review this", "check this PR for bugs". --- # Purpose Review a code change with the context of the repo around it, not the diff alone. Rank findings by what breaks the program first, then by what an attacker could exploit. # Workflow 1. Read the diff. List every file and line range it changes. 2. For each changed file, read the full file, not only the changed lines. Read a function the diff calls or that calls the diff, when the file does not show enough context. 3. Check each changed line for a correctness bug: wrong logic, an off-by-one, a null or undefined path the code does not handle, a type mismatch, a race condition, a resource the code does not release. 4. Check each changed line for a security issue: unvalidated input, a secret in source, an injection path, a missing authorization check, a dependency with a known vulnerability. 5. For each finding, write the smallest diff that fixes it. Do not redesign the function around the fix. 6. Order the findings: all correctness bugs first, ranked by how badly the program breaks; then all security issues, ranked by how easily an attacker reaches them. 7. Do not edit the repo. Return the findings and the proposed patches as text. # Output Contract A numbered list. Each entry has: - `file:line` of the finding. - The failure scenario: the input or sequence that triggers the bug, in one or two sentences. - The proposed fix, as a unified diff hunk (`---`/`+++`/`@@`) scoped to the smallest change that resolves it. Correctness findings appear before security findings. Within each group, order by severity, most severe first. If the diff has no findings, say so in one line and stop. # Operating Rules - Never write, edit, or stage a file. Every fix ships as a proposed patch, never applied. - Never run a linter, test suite, or build step that writes to the repo or a remote. - Never invent a finding the code does not support. Cite the exact line for each one. - Never ask the user for a credential, API key, or token. - Never contact a third-party service (a dependency database, a CVE feed) unless the user has already connected one and asks for it by name. - Style, naming, and formatting issues are out of scope. Report them only if asked, and keep them in a separate section after the ranked list.
PR Description Writer
Paste a diff; get a clear PR title and description.
Tested in Museprompt packinstructionspr-template
by Muse Skills editors · Written for this directory
ViewInstall the "PR Description Writer" prompt pack. Its full source is below. Save it at ~/workspace/prompts/pr-description-writer.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "write my PR description", "draft a pull request", "summarize these changes for a PR". --- SOURCE --- # PR Description Writer How to use: paste a diff, a commit list, or a plain-English summary of what changed. It returns a PR title and description in the template below. Trigger phrases: "write my PR description", "draft a pull request", "summarize these changes for a PR". Save it as a reusable prompt pack named "PR Description Writer". ## The prompt Write the title and description for this pull request. Read the diff or summary I paste and produce: **Title:** one line, imperative mood, under 72 characters ("Add retry logic to checkout", not "fixed stuff"). **Description, in this shape:** - **What:** 2-3 sentences on what changed and why. - **How:** the approach in one short paragraph. Name the key files or modules touched. - **Testing:** how it was verified (tests added, manual steps, or "not yet tested" stated plainly). - **Risk / rollout:** anything reviewers should watch for: migrations, flag flips, breaking changes. Write "None" if there is nothing. Rules: describe outcomes, not file-by-file narration. If the change is unclear from the diff, ask one clarifying question instead of guessing. Keep the whole description under 250 words.
Regex Smith
Describe the pattern in English; get a tested regex with examples.
Tested in Museskillinstructionsworkflowtest-cases
by Muse Skills editors · Written for this directory
ViewInstall the "Regex Smith" skill. Its full source is below. Create it at ~/workspace/skills/regex-smith/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. --- SOURCE --- --- name: regex-smith description: Turn a plain-English pattern description into a tested regular expression, with match and non-match examples. Trigger phrases: "build me a regex", "regex for this pattern", "write a regex that". --- # Purpose Produce correct regular expressions without the trial-and-error. The user describes the pattern in plain English; the skill returns the regex plus proof it works. # Workflow 1. Read the user's description. Identify: what must match, what must NOT match, and the flavor (JavaScript, Python, PCRE: ask if it matters and wasn't stated). 2. Write the regex. Prefer readability: named groups where the flavor supports them, and a brief annotation of each part. 3. Test it mentally against at least 3 strings that should match and 3 that should not, including edge cases (empty string, boundary characters, unicode if relevant). 4. Report in the Output Contract shape. # Output Contract - Regex: in a code block, with the flavor labeled - Annotated: one line per major part explaining what it does - Should match: 3+ example strings - Should not match: 3+ example strings - Caveats: one line on what the regex deliberately does not handle # Operating Rules - Never return a regex without the match/non-match examples. - If the description is ambiguous (for example, "a date" without a format), ask which format before writing. - Prefer the simplest regex that satisfies the examples; say when a stricter version exists and what it costs in readability. - Nothing is executed anywhere; the "tests" are worked examples, labeled as such.
Standup Writer
Yesterday's commits plus today's calendar become a tight standup update.
Tested in Museprompt packinstructionsstandup-template
by Muse Skills editors · Written for this directory
ViewInstall the "Standup Writer" prompt pack. Its full source is below. Save it at ~/workspace/prompts/standup-writer.md exactly as given, with the frontmatter (name and description) and the prompt body. Do not run it now. Then confirm it is saved and tell me the trigger phrases: "write my standup", "draft my daily update", "prepare my standup". --- SOURCE --- # Standup Writer How to use: run each morning before standup. It reads yesterday's git history and today's calendar, then drafts the update in yesterday / today / blockers shape. Trigger phrases: "write my standup", "draft my daily update", "prepare my standup". ## The prompt Draft my standup update. Read the git log for the last working day across my active repos, and my calendar for today. Write it in this exact shape: - **Yesterday:** 2-4 bullets, grouped by repo or project. Describe outcomes, not commit messages ("finished the checkout retry logic", not "fix tests"). - **Today:** 2-3 bullets from today's calendar and the natural next steps of yesterday's work. - **Blockers:** only real blockers. If none, write "None." Rules: never invent work. If a commit message is unclear, describe it plainly or omit it. Keep the whole update under 150 words. Ask which repos count as "active" the first time; remember the answer for future runs.