Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

$pwd:

mdproof-changelog

Name: Mdproof Changelog
Author: runkids

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

Exécuter dans Manus

$ git log --oneline --stat

stars:13

forks:0

updated:10 mars 2026 à 11:51

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

related-skills.json

même dépôt

mdproof.md

from "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-0813

mdproof-cli-e2e-test.md

from "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-1313

mdproof-devcontainer.md

from "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-1313

mdproof-update-docs.md

from "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-1313

mdproof-implement-feature.md

from "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-1013

package.json

"author": "runkids"

"repository": "runkids/mdproof"

Ouvrir le dépôt GitHub Voir les dépôts du créateur

$ install --global

$ download --local

Exécuter dans Manus

$ useful --forSOC

Développeurs de logicielsProfessions informatiques et mathématiques15-1252L4

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

mdproof-changelog

Workflow

Step 1: Determine Version Range

Step 2: Collect Commits

Step 3: Categorize Changes

Step 4: Read Existing Entries for Style Reference

Step 5: Write User-Facing Entry

Step 6: Update CHANGELOG.md

Bug Fixes

Breaking Changes

Plus depuis ce dépôt

Plus depuis ce dépôt

Workflow

Step 1: Determine Version Range

Step 2: Collect Commits

Step 3: Categorize Changes

Step 4: Read Existing Entries for Style Reference

Step 5: Write User-Facing Entry

Step 6: Update CHANGELOG.md

Bug Fixes

Breaking Changes