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

deb-scripts-commits

スター29

フォーク0

更新日2026年3月31日 22:11

Use when writing Git commit messages or PR titles for changes in deb_scripts. Covers conventional commits, raw plain-text output, English-only output, and the supported modes single_commit, squash_commit, pr_title, and commit_with_body.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

thegrayfoxxx

thegrayfoxxx/deb_scripts

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

ダウンロード

Manusで実行

Commit and PR messages

Use this skill when the user asks for a commit message, squash commit, PR title, or commit body.

Output contract

Output raw plain text only.
Output in English only.
Do not use Markdown.
Do not use code fences.
Do not use bullets, quotes, or explanations.
Write exactly one result.

Modes

The requested mode should be one of:

single_commit
squash_commit
pr_title
commit_with_body

Mode rules

`single_commit`

Use Conventional Commits format: <type>: <subject>
Allowed types: feat, fix, docs, style, refactor, perf, test, chore, build, ci
Keep subject under 50 characters
Use imperative mood
Do not end subject with punctuation
Do not include a body unless it adds useful context

`squash_commit`

Use Conventional Commits format: <type>: <subject>
Allowed types: feat, fix, docs, style, refactor, perf, test, chore, build, ci
Keep subject under 50 characters
Use imperative mood
Do not end subject with punctuation
Summarize the final combined result, not intermediate steps
Do not include a body unless it adds useful context

`pr_title`

Write a short PR title
Keep it under 72 characters
Use imperative mood
Do not end with punctuation
Make it specific and outcome-focused

`commit_with_body`

Use Conventional Commits format
Format:

<type>: <subject>

<body>

Allowed types: feat, fix, docs, style, refactor, perf, test, chore, build, ci
Keep subject under 50 characters
Use imperative mood
Do not end subject with punctuation
Include a concise body only when it adds useful context
Focus on what changed and why, not low-level implementation details

Selection rules

Base the message only on the provided diff or commit list.
Prefer the smallest accurate commit type.
For squash commits, describe the net result.
For PR titles, optimize for fast comprehension rather than strict Conventional Commits formatting.
When creating commits, keep each commit as small as possible while staying logically complete.
Group only files that belong to the same change.
A commit may include source changes plus the tests and helper updates required for that exact behavior.
Do not mix unrelated docs, refactors, logging changes, and feature work in the same commit.

Versioning and tags

Before creating any commit, explicitly check whether the staged change set warrants a version bump.
Make that version-bump decision first, then create the commit.
When a logically complete change set should produce a release version bump, update the project version with uv version --bump ....
Use semantic versioning logic:
- patch: fixes, small compatible improvements, docs-only releases only if the project policy requires it
- minor: backward-compatible features or meaningful user-visible additions
- major: breaking changes
Use:
- uv version --bump patch
- uv version --bump minor
- uv version --bump major
If an exact version is required, use uv version <value>.
Keep the version bump in the same logical commit set or release step as the change it represents.
When a release bump is made, update documentation references to the project version in the same change set.
At minimum, sync the version shown in the detailed documentation and any release-facing README text that surfaces the current version.
When a release bump is made, create the matching Git tag for that version immediately unless the user explicitly does not want tagging.
Treat the tag as part of the release workflow, not as an optional follow-up.
Use the project version after the bump as the tag name, prefixed with v, for example v2.1.3.
After creating the tag, explicitly propose the push commands for the current branch and the new tag.
Default push guidance should be:
- git push origin <current-branch>
- git push origin vX.Y.Z
If the branch is already confirmed to be up to date on origin, still propose the tag push command and mention that the branch push is only needed if local commits are not yet on the remote.
Do not bump the version for every commit by default; do it only when the change logically represents a release-worthy increment.
If no bump is needed, keep the commit versionless by design rather than skipping the check.

このリポジトリの他の Skills

同じリポジトリ

deb-scripts-maintainer

thegrayfoxxx/deb_scripts

Use when working in the deb_scripts repository on existing code, bug fixes, refactors, CLI behavior, interactive menus, logging, or documentation updates. Covers the project architecture, service contracts, safety constraints, and the expected testing workflow.

2026-03-3129

deb-scripts-testing

thegrayfoxxx/deb_scripts

Use when adding or changing tests in deb_scripts, or when deciding how to validate a code change. Covers unit, integration, and system test selection, expected smoke checks, and how to verify CLI and interactive behavior without over-testing unrelated paths.

2026-03-3129

deb-scripts-planning

thegrayfoxxx/deb_scripts

Use when the user wants a plan-first workflow in deb_scripts, asks for a clear execution plan before any changes, or expects work to be performed step by step against an explicit plan with checkpoints.

2026-03-3129

deb-scripts-system-commands

thegrayfoxxx/deb_scripts

Use when adding or changing apt, systemctl, ufw, sysctl, curl, rm, or other host-level command execution in deb_scripts. Covers safe subprocess patterns, post-command verification, and what to log versus what to keep in debug output.

2026-03-3129

deb-scripts-cli-ux

thegrayfoxxx/deb_scripts

Use when changing menu text, prompts, status messages, confirmations, or user-facing CLI output in deb_scripts. Covers concise operator-focused messaging, menu consistency, and avoiding duplicate or noisy output across interactive and non-interactive flows.

2026-03-3129

deb-scripts-logging

thegrayfoxxx/deb_scripts

Use when changing logs, CLI output, or interactive messages in deb_scripts. Covers log levels, separation between user-facing console output and debug/file logs, and CLI UX rules to avoid noisy operational telemetry.

2026-03-3129

name	deb-scripts-commits
description	Use when writing Git commit messages or PR titles for changes in deb_scripts. Covers conventional commits, raw plain-text output, English-only output, and the supported modes single_commit, squash_commit, pr_title, and commit_with_body.

Commit and PR messages

Use this skill when the user asks for a commit message, squash commit, PR title, or commit body.

Output contract

Output raw plain text only.
Output in English only.
Do not use Markdown.
Do not use code fences.
Do not use bullets, quotes, or explanations.
Write exactly one result.

Modes

The requested mode should be one of:

single_commit
squash_commit
pr_title
commit_with_body

Mode rules

`single_commit`

Use Conventional Commits format: <type>: <subject>
Allowed types: feat, fix, docs, style, refactor, perf, test, chore, build, ci
Keep subject under 50 characters
Use imperative mood
Do not end subject with punctuation
Do not include a body unless it adds useful context

`squash_commit`

Use Conventional Commits format: <type>: <subject>
Allowed types: feat, fix, docs, style, refactor, perf, test, chore, build, ci
Keep subject under 50 characters
Use imperative mood
Do not end subject with punctuation
Summarize the final combined result, not intermediate steps
Do not include a body unless it adds useful context

`pr_title`

Write a short PR title
Keep it under 72 characters
Use imperative mood
Do not end with punctuation
Make it specific and outcome-focused

`commit_with_body`

Use Conventional Commits format
Format:

<type>: <subject>

<body>

Allowed types: feat, fix, docs, style, refactor, perf, test, chore, build, ci
Keep subject under 50 characters
Use imperative mood
Do not end subject with punctuation
Include a concise body only when it adds useful context
Focus on what changed and why, not low-level implementation details

Selection rules

Base the message only on the provided diff or commit list.
Prefer the smallest accurate commit type.
For squash commits, describe the net result.
For PR titles, optimize for fast comprehension rather than strict Conventional Commits formatting.
When creating commits, keep each commit as small as possible while staying logically complete.
Group only files that belong to the same change.
A commit may include source changes plus the tests and helper updates required for that exact behavior.
Do not mix unrelated docs, refactors, logging changes, and feature work in the same commit.

Versioning and tags

Before creating any commit, explicitly check whether the staged change set warrants a version bump.
Make that version-bump decision first, then create the commit.
When a logically complete change set should produce a release version bump, update the project version with uv version --bump ....
Use semantic versioning logic:
- patch: fixes, small compatible improvements, docs-only releases only if the project policy requires it
- minor: backward-compatible features or meaningful user-visible additions
- major: breaking changes
Use:
- uv version --bump patch
- uv version --bump minor
- uv version --bump major
If an exact version is required, use uv version <value>.
Keep the version bump in the same logical commit set or release step as the change it represents.
When a release bump is made, update documentation references to the project version in the same change set.
At minimum, sync the version shown in the detailed documentation and any release-facing README text that surfaces the current version.
When a release bump is made, create the matching Git tag for that version immediately unless the user explicitly does not want tagging.
Treat the tag as part of the release workflow, not as an optional follow-up.
Use the project version after the bump as the tag name, prefixed with v, for example v2.1.3.
After creating the tag, explicitly propose the push commands for the current branch and the new tag.
Default push guidance should be:
- git push origin <current-branch>
- git push origin vX.Y.Z
If the branch is already confirmed to be up to date on origin, still propose the tag push command and mention that the branch push is only needed if local commits are not yet on the remote.
Do not bump the version for every commit by default; do it only when the change logically represents a release-worthy increment.
If no bump is needed, keep the commit versionless by design rather than skipping the check.