ワンクリックでManusで任意のスキルを実行

$pwd:

veto-changelog

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

Manusで実行

$ git log --oneline --stat

stars:5

forks:0

updated:2026年3月7日 08:53

SKILL.md

readonly

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

related-skills.json

同じリポジトリ

veto-cli-e2e-test.md

from "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.md

from "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.md

from "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.md

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

package.json

"author": "runkids"

"repository": "runkids/veto"

GitHub リポジトリを開く Creator のリポジトリを見る

$ install --global

$ download --local

Manusで実行

$ useful --forSOC

ソフトウェア開発者コンピュータ・数学職15-1252L4

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

veto-changelog

Workflow

Step 1: Determine Version Range

Step 2: Collect Commits

Step 3: Categorize Changes

Step 4: Read Existing Style

Step 5: Write User-Facing Entry

Step 6: Update CHANGELOG.md

Bug Fixes

Breaking Changes

このリポジトリの他の Skills

このリポジトリの他の Skills

Workflow

Step 1: Determine Version Range

Step 2: Collect Commits

Step 3: Categorize Changes

Step 4: Read Existing Style

Step 5: Write User-Facing Entry

Step 6: Update CHANGELOG.md

Bug Fixes

Breaking Changes