一键在 Manus 中运行任何 Skill

commit

星标0

分支0

更新时间2026年3月17日 13:31

Generate and execute git commits with Conventional Commits format. Use when user says 'commit', 'コミットして', 'save changes', 'この変更をコミット', or has staged changes to commit. Do NOT use for amending existing commits, interactive rebase, or unstaging files.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

ysk1031

ysk1031/dotfiles

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Git Commit Skill

Generate a commit message for staged changes and let the user review/edit before committing.

Instructions

Phase 1: Analyze Changes (use Agent with subagent)

Call the Agent tool with:

subagent_type: "commit-composer"
description: "analyze staged changes"
prompt: Replace $ARGUMENTS in the agent's loaded prompt with the actual user arguments and execute.

The subagent will return the proposed commit message (or an error/warning).

Phase 2: User Confirmation (main agent)

If subagent returns "status": "NO_CHANGES" or "status": "NEEDS_SPLIT", display the message field and stop.

If subagent returns "status": "OK":

Use AskUserQuestion:
- question: Include the proposed commit message (from title and body fields) in the question text Example (no body): "提案コミットメッセージ:\n\n<title>\n\nこのコミットメッセージでよろしいですか？" Example (with body): "提案コミットメッセージ:\n\n<title>\n\n\n\nこのコミットメッセージでよろしいですか？"
- header: "Commit"
- options:
  1. label: "Accept", description: "このままコミットを実行"
  2. label: "Edit", description: "メッセージを編集（Otherで自由入力）"
  3. label: "Cancel", description: "コミットせずに終了"

If "Accept": Proceed to Phase 3 If "Edit": User provides custom message via "Other". Use that message for Phase 3 If "Cancel": Print "コミットをキャンセルしました。" and stop

Phase 3: Execute Commit (main agent with Bash)

Determine Co-Authored-By name: Use your own model name for the Co-Authored-By trailer. Format: Co-Authored-By: Claude <model> <noreply@anthropic.com> where <model> is your model name (e.g., "Opus 4.6", "Sonnet 4.5") as stated in your system prompt.

Execute the commit:

For title only:

git commit -m "$(cat <<'EOF'
<type>: <description>

Co-Authored-By: Claude <model> <noreply@anthropic.com>
EOF
)"

For title + body:

git commit -m "$(cat <<'EOF'
<type>: <description>

<body>

Co-Authored-By: Claude <model> <noreply@anthropic.com>
EOF
)"

Then verify: git status && git log -1

Rules

NEVER skip Co-Authored-By (always use your actual model name, never hardcode a specific version) — ensures traceability of AI-generated commits and enables audit of change history
NEVER use --amend unless explicitly requested — amend rewrites the previous commit, risking unintended data loss
NEVER use --no-verify — pre-commit hooks enforce project quality standards; bypassing them can introduce lint errors and security issues
Keep first line under 72 characters — industry-standard convention to prevent truncation in git log and GitHub UI
Body should wrap at 72 characters — ensures readability in terminals and git log output

Examples

Example 1: 通常のコミット

User says: "コミットして" Actions:

commit-composer がステージ済み変更を分析
Conventional Commits形式のメッセージを提案
ユーザー確認後コミット実行 Result: feat: add user authentication flow のようなコミットが作成される

Example 2: --force付きコミット

User says: "-f でコミット" Actions:

粒度チェックをスキップ
即座にコミットメッセージを提案 Result: 粒度に関わらず単一コミットとして作成される

Troubleshooting

"No staged changes"

Cause: ステージされた変更がない Solution: git add <files> でファイルをステージングしてから再実行

"NEEDS_SPLIT"

Cause: ステージされた変更が大きすぎて単一コミットに不適切 Solution: git add -p で変更を分割してステージングし、複数コミットに分ける

同仓库更多 Skills

同仓库

daily-report

ysk1031/dotfiles

Aggregate today's Claude Code session logs and GitHub activity into a personal reflection-style daily report (what I did / what I was thinking / what I struggled with). Use whenever the user says '日報', 'daily report', '今日の振り返り', '今日何やった', '今日まとめて', or wants a self-reflective summary of a single day's development work. This is the right skill anytime the scope is a single day — even if the user doesn't say '日報' explicitly. Distinct from [[weekly-report]] (which covers a multi-day business week with aggregate stats); prefer daily-report for single-day scopes. Do NOT use for non-development journaling, sprint planning, or weekly/monthly reviews.

2026-06-270

obsidian-learning-note

ysk1031/dotfiles

Summarize the learnings from the current Claude Code session and save them as a new Markdown note in the user's Obsidian vault at ~/Documents/Obsidian/SyncedNotes/. Use when the user explicitly asks to capture session insights to Obsidian — phrases like '今の学びをObsidianに保存して', 'この学びをまとめて', '学びをノートにして', 'Obsidianにメモして', 'save the learnings to Obsidian'. Extracts insights across debugging solutions, newly-encountered tech/tools/patterns, codebase-specific knowledge, and workflow improvements, then writes one consolidated note. Do NOT use for activity-style daily summaries (use [[daily-report]] instead), for appending to an existing note, or for non-learning content.

2026-06-270

session-handoff

ysk1031/dotfiles

作業セッションの終わりに、次の作業セッションが前提知識ゼロで再開できる「引き継ぎ doc（markdown 1本）＋そのまま貼れるキックオフメッセージ」を生成する。狙いは、会話の自動要約（compaction）では失われがちな情報——下した判断とその理由、採用／却下した規約・選択肢、実際に使った検証コマンドやツールチェーンのハマり所、コードや git から再導出できないプロジェクト固有の方針、残作業と保留理由——を正確に残すこと。次のような場面では、明示的に "doc" や "引き継ぎ" という語が無くても積極的に発火する: 「引き継ぎ／handoff を作って」「別のセッション・別チャットに渡したい／そっちで続きをやる」「次のセッション用にまとめて」「(会話の)context・コンテキストがいっぱい／そろそろ限界」「このまま /clear・compact する前に今の状態を残したい」「compact すべきか doc に残すべきか迷う」「今日はここまで／作業を中断する／一区切りつけるので、明日や後で再開する自分が迷わず続けられるよう状態を残して」。一方、次は対象外なので発火しない: 関数の切り出し・リネーム・1ファイル内のリファクタなどコード整理そのもの；PR 説明文・コミットメッセージ・README・設計ドキュメント (design doc) など一般の文書作成；Slack などへの作業報告・分報のまとめ；退職や担当交代に伴う人・チームへの業務引き継ぎ資料；「もっとファイルを読んで文脈(context)を把握して直して」のような、会話の context 枯渇ではなくコード理解を指す依頼。

2026-06-230

ysk1031/dotfiles

Create a GitHub Pull Request with auto-generated title and description. Use when user says 'PR作って', 'create PR', 'プルリクエスト', or wants to push and open a pull request. Do NOT use for reviewing existing PRs, merging PRs, or updating PR descriptions.

2026-06-110

design

ysk1031/dotfiles

Design an implementation plan and refine it through human annotation cycles. Use when user says '設計して', '計画を立てて', 'plan the implementation', 'how should I implement', or wants to plan before coding. Do NOT use for direct implementation, code review, or research without planning.

2026-03-170

develop

ysk1031/dotfiles

Run the full research → design → implement pipeline end-to-end. Use when user says '開発して', 'build this feature', '新機能を作って', '一気通貫で実装', or wants the complete workflow from investigation to implementation. Do NOT use for research-only, design-only, or implementing an existing plan — use /research, /design, or /implement respectively.

2026-03-170

name	commit
description	Generate and execute git commits with Conventional Commits format. Use when user says 'commit', 'コミットして', 'save changes', 'この変更をコミット', or has staged changes to commit. Do NOT use for amending existing commits, interactive rebase, or unstaging files.
allowed-tools	Agent, AskUserQuestion, Bash
argument-hint	[--force/-f to skip granularity check] [optional commit message hint]
metadata	{"author":"ysk1031","version":"1.0.0"}

Git Commit Skill

Generate a commit message for staged changes and let the user review/edit before committing.

Instructions

Phase 1: Analyze Changes (use Agent with subagent)

Call the Agent tool with:

subagent_type: "commit-composer"
description: "analyze staged changes"
prompt: Replace $ARGUMENTS in the agent's loaded prompt with the actual user arguments and execute.

The subagent will return the proposed commit message (or an error/warning).

Phase 2: User Confirmation (main agent)

If subagent returns "status": "NO_CHANGES" or "status": "NEEDS_SPLIT", display the message field and stop.

If subagent returns "status": "OK":

Use AskUserQuestion:
- question: Include the proposed commit message (from title and body fields) in the question text Example (no body): "提案コミットメッセージ:\n\n<title>\n\nこのコミットメッセージでよろしいですか？" Example (with body): "提案コミットメッセージ:\n\n<title>\n\n\n\nこのコミットメッセージでよろしいですか？"
- header: "Commit"
- options:
  1. label: "Accept", description: "このままコミットを実行"
  2. label: "Edit", description: "メッセージを編集（Otherで自由入力）"
  3. label: "Cancel", description: "コミットせずに終了"

If "Accept": Proceed to Phase 3 If "Edit": User provides custom message via "Other". Use that message for Phase 3 If "Cancel": Print "コミットをキャンセルしました。" and stop

Phase 3: Execute Commit (main agent with Bash)

Execute the commit:

For title only:

git commit -m "$(cat <<'EOF'
<type>: <description>

Co-Authored-By: Claude <model> <noreply@anthropic.com>
EOF
)"

For title + body:

git commit -m "$(cat <<'EOF'
<type>: <description>

<body>

Co-Authored-By: Claude <model> <noreply@anthropic.com>
EOF
)"

Then verify: git status && git log -1

Rules

NEVER skip Co-Authored-By (always use your actual model name, never hardcode a specific version) — ensures traceability of AI-generated commits and enables audit of change history
NEVER use --amend unless explicitly requested — amend rewrites the previous commit, risking unintended data loss
NEVER use --no-verify — pre-commit hooks enforce project quality standards; bypassing them can introduce lint errors and security issues
Keep first line under 72 characters — industry-standard convention to prevent truncation in git log and GitHub UI
Body should wrap at 72 characters — ensures readability in terminals and git log output

Examples

Example 1: 通常のコミット

User says: "コミットして" Actions:

commit-composer がステージ済み変更を分析
Conventional Commits形式のメッセージを提案
ユーザー確認後コミット実行 Result: feat: add user authentication flow のようなコミットが作成される

Example 2: --force付きコミット

User says: "-f でコミット" Actions:

粒度チェックをスキップ
即座にコミットメッセージを提案 Result: 粒度に関わらず単一コミットとして作成される

Troubleshooting

"No staged changes"

Cause: ステージされた変更がない Solution: git add <files> でファイルをステージングしてから再実行

"NEEDS_SPLIT"

Cause: ステージされた変更が大きすぎて単一コミットに不適切 Solution: git add -p で変更を分割してステージングし、複数コミットに分ける