Run any Skill in Manus with one click

mdproof-changelog

Stars14

Forks0

UpdatedMarch 10, 2026 at 11:51

Generate CHANGELOG.md entry from recent commits in conventional format. Use this skill whenever the user asks to: write release notes, generate a changelog, prepare a version release, document what changed between tags, or create a new CHANGELOG entry. Do NOT manually edit CHANGELOG.md without this skill — it ensures proper formatting and user-perspective writing.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

runkids

runkids/mdproof

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	mdproof-changelog
description	Generate CHANGELOG.md entry from recent commits in conventional format. Use this skill whenever the user asks to: write release notes, generate a changelog, prepare a version release, document what changed between tags, or create a new CHANGELOG entry. Do NOT manually edit CHANGELOG.md without this skill — it ensures proper formatting and user-perspective writing.
argument-hint	[tag-version]
targets	["claude","codex"]

Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., v0.1.0) or omit to auto-detect via git describe --tags --abbrev=0.

Scope: This skill updates CHANGELOG.md. It does NOT write code (use implement-feature).

Workflow

Step 1: Determine Version Range

# Auto-detect latest tag
LATEST_TAG=$(git describe --tags --abbrev=0)
# Find previous tag
PREV_TAG=$(git describe --tags --abbrev=0 "${LATEST_TAG}^")

echo "Generating changelog: $PREV_TAG → $LATEST_TAG"

Step 2: Collect Commits

git log "${PREV_TAG}..${LATEST_TAG}" --oneline --no-merges

Step 3: Categorize Changes

Group commits by conventional commit type:

Prefix	Category
`feat`	New Features
`fix`	Bug Fixes
`refactor`	Refactoring
`docs`	Documentation
`perf`	Performance
`test`	Tests
`chore`	Maintenance

Step 4: Read Existing Entries for Style Reference

Before writing, read the most recent entries in CHANGELOG.md to match the established tone and structure. Always match the latest style.

Step 5: Write User-Facing Entry

Write from the user's perspective. Only include changes users will notice.

Include:

New features with usage examples (CLI flags, code blocks)
Bug fixes that affected user-visible behavior
Breaking changes (renames, removed flags)
Performance improvements users would notice

Exclude:

Internal test changes
Implementation details (error propagation, internal structs)
Dev toolchain changes (Makefile cleanup)
Pure code refactoring

Step 6: Update CHANGELOG.md

Insert new entry at the top, after the header:

## [X.Y.Z] - YYYY-MM-DD

### New Features

- **Feature name** — description with `inline code` for flags
  ```bash
  mdproof --new-flag file.md    # usage example

Bug Fixes

Fixed specific user-visible behavior — with context

Breaking Changes

Renamed old-flag to new-flag


Key style points:
- Version numbers use `[X.Y.Z]` without `v` prefix
- Feature bullets use `**bold name** — em-dash description` format
- Only include sections that have content

## Rules

- **User perspective** — write for users, not developers
- **No fabricated links** — never invent URLs or references
- **Verify features exist** — grep source before claiming a feature
- **No internal noise** — exclude test-only or refactor-only changes
- **Conventional format** — follow existing CHANGELOG.md style

More from this repository

same repository

mdproof

runkids/mdproof

Use when: writing E2E, integration, or smoke tests; verifying CLI tools, APIs, or deployments; creating executable documentation; running existing runbook or proof files; or after implementing a feature to verify it works. Activate when the project has *_runbook.md/*_proof.md files, a mdproof.json config, or the user mentions mdproof/runbook/proof. Executable runbook runner — turns Markdown into real tests with bash execution, 6 assertion types (substring, regex, exit_code, jq, negation, snapshot), and source-aware failure reporting that points to the exact Markdown file and line.

2026-04-0814

mdproof-cli-e2e-test

runkids/mdproof

Write and run E2E test runbooks that exercise the mdproof CLI itself. Use this skill whenever you need to: verify a new feature works end-to-end, validate a bug fix via a reproducible markdown runbook, test CLI flags (--dry-run, --fail-fast, --steps, --report json, --output), regression-test assertion types (substring, regex, exit_code, jq, snapshot), or confirm that parser/executor changes didn't break real-world runbook files. This skill produces .md files in runbooks/ that mdproof can run against itself — the tool testing itself. If you're about to write or run an E2E test for mdproof, use this skill first.

2026-03-1314

mdproof-devcontainer

runkids/mdproof

Run CLI commands, tests, and debugging inside the mdproof devcontainer. Use this skill whenever you need to: execute mdproof CLI commands, run Go tests (unit or integration), reproduce bugs, test new features, run E2E runbooks, or perform any operation that requires a Linux container environment. mdproof refuses to execute outside Docker by design — the devcontainer is the correct place to run and test it. If you are about to use Bash to run `mdproof`, `go test`, or `make test`, stop and use this skill first to ensure correct container execution.

2026-03-1314

mdproof-update-docs

runkids/mdproof

Update all documentation (skills/, docs/, README.md, CHANGELOG.md) to match recent code changes, cross-validating every flag and config field against Go source. Use this skill whenever the user asks to: update docs, sync docs with code, document a new flag or config option, fix stale docs, or refresh documentation after implementing a feature. This skill covers: docs/ (user-facing guides: cli-reference.md, writing-runbooks.md, advanced.md), skills/SKILL.md (AI agent skill), skills/references/ (assertions, advanced features), README.md (project overview), and CHANGELOG.md. If you just implemented a feature and need to update documentation, this is the skill to use. Never manually edit docs without cross-validating against Go source first.

2026-03-1314

mdproof-implement-feature

runkids/mdproof

Implement a feature from a spec file or description using TDD workflow. Use this skill whenever the user asks to: add a new CLI flag, implement a feature, build new functionality, create a new internal package, add an assertion type, extend the parser, or write Go code for mdproof. This skill enforces test-first development and proper package structure. If the request involves writing Go code and tests, use this skill — even if the user doesn't explicitly say "implement".

2026-03-1014

name	mdproof-changelog
description	Generate CHANGELOG.md entry from recent commits in conventional format. Use this skill whenever the user asks to: write release notes, generate a changelog, prepare a version release, document what changed between tags, or create a new CHANGELOG entry. Do NOT manually edit CHANGELOG.md without this skill — it ensures proper formatting and user-perspective writing.
argument-hint	[tag-version]
targets	["claude","codex"]

Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., v0.1.0) or omit to auto-detect via git describe --tags --abbrev=0.

Scope: This skill updates CHANGELOG.md. It does NOT write code (use implement-feature).

Workflow

Step 1: Determine Version Range

# Auto-detect latest tag
LATEST_TAG=$(git describe --tags --abbrev=0)
# Find previous tag
PREV_TAG=$(git describe --tags --abbrev=0 "${LATEST_TAG}^")

echo "Generating changelog: $PREV_TAG → $LATEST_TAG"

Step 2: Collect Commits

git log "${PREV_TAG}..${LATEST_TAG}" --oneline --no-merges

Step 3: Categorize Changes

Group commits by conventional commit type:

Prefix	Category
`feat`	New Features
`fix`	Bug Fixes
`refactor`	Refactoring
`docs`	Documentation
`perf`	Performance
`test`	Tests
`chore`	Maintenance

Step 4: Read Existing Entries for Style Reference

Before writing, read the most recent entries in CHANGELOG.md to match the established tone and structure. Always match the latest style.

Step 5: Write User-Facing Entry

Write from the user's perspective. Only include changes users will notice.

Include:

New features with usage examples (CLI flags, code blocks)
Bug fixes that affected user-visible behavior
Breaking changes (renames, removed flags)
Performance improvements users would notice

Exclude:

Internal test changes
Implementation details (error propagation, internal structs)
Dev toolchain changes (Makefile cleanup)
Pure code refactoring

Step 6: Update CHANGELOG.md

Insert new entry at the top, after the header:

## [X.Y.Z] - YYYY-MM-DD

### New Features

- **Feature name** — description with `inline code` for flags
  ```bash
  mdproof --new-flag file.md    # usage example

Bug Fixes

Fixed specific user-visible behavior — with context

Breaking Changes

Renamed old-flag to new-flag


Key style points:
- Version numbers use `[X.Y.Z]` without `v` prefix
- Feature bullets use `**bold name** — em-dash description` format
- Only include sections that have content

## Rules

- **User perspective** — write for users, not developers
- **No fabricated links** — never invent URLs or references
- **Verify features exist** — grep source before claiming a feature
- **No internal noise** — exclude test-only or refactor-only changes
- **Conventional format** — follow existing CHANGELOG.md style