Dependency Update Triage

Turns a scary outdated-dependencies list into safe-now, review, and hold buckets.

Tested in MuseskillDev & automationinstructionsworkflowreport

by Muse Skills editors · Written for this directory

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

View source

Ready to copy.

Details

Type: skill
Category: Dev & automation
Version: 1.0.0
Added: 30 Sep 2026
Author: Muse Skills editorsWritten for this directory
Includes: instructionsworkflowreport
Source: github.com/…/dependency-update-triage.md

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

Before you install

A shared skill carries somebody else's instructions. Read the source before you install it.
Never paste an API key, password, or token into anything a skill asks for. Legitimate skills use Muse's own secure flows.
Installing copies the setup into your own environment. It gives the author nothing.

What it does

Dependency Update Triage takes the intimidating wall of an npm outdated or pip list --outdated report and turns it into a calm plan. Most developers handle dependency updates one of two ways: they update nothing for a year out of caution, or they update everything at once and spend a weekend untangling what broke. This skill offers a third way. It classifies every outdated package by jump type, checks changelogs and advisories for the ones that matter, and sorts the whole list into three buckets: safe now, needs review, and hold. Patches and quiet minors land in safe now, majors and mystery packages land in needs review, and deprecated or conflicting packages land on hold.

It never runs an upgrade or touches a file. It only reads, classifies, and reports, then hands you the exact commands in the right order so you approve each step. The boring updates disappear from your mental load in minutes, and the risky ones get the attention they actually deserve instead of your blanket anxiety.

What it includes

A parser flow for outdated output from npm, pip, Cargo, Composer, and similar tools
Patch, minor, and major jump classification for every package
Changelog and release-note review for major jumps
Deprecation, yank, and security advisory checks
The safe-now, needs-review, and hold bucket system
A risk-ordered upgrade plan with exact commands for approval

Example

Input: the output of npm outdated pasted in, listing 5 packages.

Output:

Safe now (2)
- lodash: 4.17.20 to 4.17.21. Jump: patch. Note: patch release only.
- debug: 4.3.2 to 4.4.1. Jump: minor. Note: no breaking changes listed.

Needs review (2)
- express: 4.18.2 to 5.1.0. Jump: major. Note: major with migration guide.
- minimatch: 9.0.3 to 9.0.5. Jump: patch. Note: CVE fixed in latest, verify tests.

Hold (1)
- moment: 2.29.4 to 2.30.1. Jump: minor. Note: deprecated, plan a replacement.

Suggested order: run the safe-now patch, then the safe-now minor, then review express.
1. npm install lodash@4.17.21
2. npm install debug@4.4.1
3. Review the express 5 migration guide before upgrading.

What this one touches

Read-only by default. It classifies updates and writes a report. Never runs an install, upgrade, or migration command, and never edits package files or lockfiles, unless you explicitly approve each command first.

Install

Copy this block and paste it into your Muse chat. Muse does the install and confirms when it's done.

Install prompt

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

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

Full source

This is the exact text Muse installs. Read it. That's the whole trust model.

SKILL.md

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

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

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