원클릭으로 Manus에서 모든 스킬 실행

veto-changelog

스타5

포크0

업데이트2026년 3월 7일 08:53

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, user-perspective writing, and version consistency with Cargo.toml.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

runkids

runkids/veto

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Workflow

Step 1: Determine Version Range

# Auto-detect latest tag
LATEST_TAG=$(git describe --tags --abbrev=0)
PREV_TAG=$(git describe --tags --abbrev=0 "${LATEST_TAG}^")
CARGO_VERSION=$(grep '^version' Cargo.toml | head -1 | cut -d'"' -f2)

echo "Generating changelog: $PREV_TAG → $LATEST_TAG"
echo "Cargo.toml version: $CARGO_VERSION"

Verify version consistency:

Tag version (without v prefix) should match Cargo.toml version
Warn if mismatch (the pre-push hook also checks this)

Step 2: Collect Commits

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

Step 3: Categorize Changes

Group by conventional commit type:

Prefix	Category
`feat`	New Features
`fix`	Bug Fixes
`refactor`	Refactoring
`style`	Code Style
`perf`	Performance
`test`	Tests
`chore`	Maintenance

Step 4: Read Existing Style

Read the most recent 2-3 entries in CHANGELOG.md to match tone and structure. Always match the latest entries.

Step 5: Write User-Facing Entry

Write from the user's perspective:

Include:

New rules or risk categories with examples
New CLI commands or flags with usage
New integrations (setup commands)
Bug fixes affecting user-visible behavior
Auth method changes

Exclude:

Internal test refactoring
Code formatting changes
CI/CD tweaks
Internal struct renames

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 commands
  ```bash
  veto command --flag    # usage example

Bug Fixes

Fixed specific user-visible behavior

Breaking Changes

Renamed old-flag to new-flag


Style rules:
- Version uses `[X.Y.Z]` without `v` prefix in heading
- Feature bullets use `**bold name** — em-dash description`
- Code blocks use `bash` language tag
- Only include sections that have content

## Rules

- **User perspective** — write for users, not developers
- **No fabricated links** — never invent URLs
- **Verify features exist** — grep source before claiming a feature was added
- **No internal noise** — exclude test-only, CI-only, or style-only changes
- **Version consistency** — verify Cargo.toml matches tag version

이 저장소의 다른 Skills

같은 저장소

veto-cli-e2e-test

runkids/veto

Run isolated E2E tests from ai_docs/tests runbooks against the veto release binary. Use this skill whenever the user asks to: run an E2E test, execute a test runbook, validate a feature end-to-end, create a new runbook, or test CLI behavior in the sandbox. If you need to run a multi-step CLI validation sequence (init → check → gate → verify), this is the skill. Prefer this over ad-hoc command sequences for any test that follows a runbook or needs reproducible results.

2026-03-075

veto-codebase-audit

runkids/veto

Cross-validate CLI flags, rules, tests, and integrations for consistency across the veto codebase. Use this skill whenever the user asks to: audit the codebase, check for consistency issues, find undocumented flags, verify test coverage, validate rule definitions, or check integration completeness. This is a read-only audit — it reports issues but never modifies files. Use after large refactors, before releases, or whenever you suspect code has drifted.

2026-03-075

veto-devcontainer

runkids/veto

Run CLI commands, tests, and debugging inside the veto devcontainer. Use this skill whenever you need to: execute veto CLI commands for verification, run cargo test, reproduce bugs, test rule matching, or perform any operation that requires an isolated Linux environment. If you are about to use Bash to run `veto`, `cargo test`, or `make test`, stop and use this skill first to ensure correct container execution in headless environments (no Touch ID, no keychain).

2026-03-075

veto-implement-feature

runkids/veto

Implement a feature or fix using TDD workflow in the veto Rust codebase. Use this skill whenever the user asks to: add a new rule category, implement a CLI subcommand, add an auth method, modify the risk engine, add a new integration (setup command), or write Rust code for veto. This skill enforces test-first development and follows veto's module conventions. If the request involves writing Rust code and tests, use this skill.

2026-03-075

name	veto-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, user-perspective writing, and version consistency with Cargo.toml.
argument-hint	[tag-version]
targets	["claude"]

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

Scope: This skill updates CHANGELOG.md only. It does NOT write Rust code or modify Cargo.toml.

Workflow

Step 1: Determine Version Range

# Auto-detect latest tag
LATEST_TAG=$(git describe --tags --abbrev=0)
PREV_TAG=$(git describe --tags --abbrev=0 "${LATEST_TAG}^")
CARGO_VERSION=$(grep '^version' Cargo.toml | head -1 | cut -d'"' -f2)

echo "Generating changelog: $PREV_TAG → $LATEST_TAG"
echo "Cargo.toml version: $CARGO_VERSION"

Verify version consistency:

Tag version (without v prefix) should match Cargo.toml version
Warn if mismatch (the pre-push hook also checks this)

Step 2: Collect Commits

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

Step 3: Categorize Changes

Group by conventional commit type:

Prefix	Category
`feat`	New Features
`fix`	Bug Fixes
`refactor`	Refactoring
`style`	Code Style
`perf`	Performance
`test`	Tests
`chore`	Maintenance

Step 4: Read Existing Style

Read the most recent 2-3 entries in CHANGELOG.md to match tone and structure. Always match the latest entries.

Step 5: Write User-Facing Entry

Write from the user's perspective:

Include:

New rules or risk categories with examples
New CLI commands or flags with usage
New integrations (setup commands)
Bug fixes affecting user-visible behavior
Auth method changes

Exclude:

Internal test refactoring
Code formatting changes
CI/CD tweaks
Internal struct renames

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 commands
  ```bash
  veto command --flag    # usage example

Bug Fixes

Fixed specific user-visible behavior

Breaking Changes

Renamed old-flag to new-flag


Style rules:
- Version uses `[X.Y.Z]` without `v` prefix in heading
- Feature bullets use `**bold name** — em-dash description`
- Code blocks use `bash` language tag
- Only include sections that have content

## Rules

- **User perspective** — write for users, not developers
- **No fabricated links** — never invent URLs
- **Verify features exist** — grep source before claiming a feature was added
- **No internal noise** — exclude test-only, CI-only, or style-only changes
- **Version consistency** — verify Cargo.toml matches tag version