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

시작하기

commit

스타7

포크0

업데이트2026년 7월 14일 02:08

Read this skill before making git commits

설치

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

Manus에서 실행

출처

hockeybuggy

hockeybuggy/dotfiles

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

다운로드

Manus에서 실행

Determining the format

Run git log -n 30 --pretty=format:%s and look at recent subjects:

If most subjects use Conventional Commits (feat:, fix(scope):, etc.), follow that convention.
Otherwise, write a plain imperative subject (e.g., Fix the quoting of the clip command). Capitalize the first word, no trailing period.

Project CLAUDE.md or user instructions take precedence over what you infer from history. If they specify a style, follow it.

Subject

Imperative mood, no trailing period.
Keep it short. Match the repo's typical length; if unclear, aim for ~50 characters and stop at 72.
Wrap file names, variables, commands, and code references in backticks.

Body

Include a body when the subject doesn't say it all — typically for non-trivial changes. The body should answer: what was the state before, how does this change address it, and are there side effects.

Skip the body for trivial changes where the subject is self-explanatory (typo fixes, renames, simple config tweaks).

When you do write a body:

Wrap lines at ~72 characters.
Separate paragraphs with a blank line.
Use backticks around file names, variables, and code references.
Optionally add a final paragraph on alternatives considered, when the chosen approach isn't obvious.

Other notes

Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Check the current branch. If on main or master, ask the user to confirm they really want to commit there. If they don't, ask for the branch name they'd like to use and switch (or create) that branch before continuing.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
Run git log -n 30 --pretty=format:%s to determine the repo's commit style and commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Show the user the proposed commit message (subject and body) and wait for approval before creating the commit. Apply any requested edits and re-confirm. Use AskUserQuestion for a structured approve/edit prompt when available, otherwise plain text. If the user explicitly opts out of review for the current task (e.g. "just commit", "no need to review"), skip the prompt.
Run git commit -m "<subject>" (and -m "<body>" if needed).

이 저장소의 다른 Skills

같은 저장소

github

hockeybuggy/dotfiles

Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.

2026-07-247

isolating-test-stacks

hockeybuggy/dotfiles

Spin up throwaway service/database stacks for tests, migrations, and ingest without touching the user's real dev stack or live data. Use when a task runs `docker compose`, database migrations, ingest jobs, or any destructive command that could hit a shared or live service. Triggers on "run the migrations", "ingest the data", "spin up the stack", "run the integration tests", or any plan step that starts containers or writes to a database.

2026-07-247

use-pi-in-pane

hockeybuggy/dotfiles

Run the `pi` coding agent as a headless subagent (--mode json) inside a visible tmux pane so the user can watch it stream while the agent still captures and verifies its structured output. Use when asked to "run pi in a pane", "let me watch pi work", "run pi where I can see it", or to delegate to pi with a live view. Requires running inside tmux. For a fully headless run with no pane, use use-pi-subagent instead.

2026-07-247

use-pi-subagent

hockeybuggy/dotfiles

Invoke the `pi` coding agent as a non-interactive subagent from the shell — delegate a self-contained coding or analysis task to a fresh pi process and read its structured JSON output. Use when asked to "run pi", "use pi as a subagent", "delegate this to pi", or to orchestrate pi coder/reviewer agents (see prompt.md).

2026-07-247

caffeinate

hockeybuggy/dotfiles

Keep the computer awake for a set duration or while a command runs, using `caffeinate` on macOS. Use when the user wants to prevent sleep during a long-running task, download, or presentation.

2026-07-187

writing-handoffs

hockeybuggy/dotfiles

Writes a self-contained handoff document that briefs another agent or person to execute a scoped task without the originating context. Triggers when the user asks to "write a handoff", "hand this off", "brief another agent", "create a delegation doc", or prep work for a sub-agent / worktree agent to pick up. Emits a markdown file following a fixed template.

2026-07-167

name	commit
description	Read this skill before making git commits

Create a git commit for the current changes. Match the repo's existing commit style — don't impose a format the repo doesn't already use.

Determining the format

Run git log -n 30 --pretty=format:%s and look at recent subjects:

If most subjects use Conventional Commits (feat:, fix(scope):, etc.), follow that convention.
Otherwise, write a plain imperative subject (e.g., Fix the quoting of the clip command). Capitalize the first word, no trailing period.

Project CLAUDE.md or user instructions take precedence over what you infer from history. If they specify a style, follow it.

Subject

Imperative mood, no trailing period.
Keep it short. Match the repo's typical length; if unclear, aim for ~50 characters and stop at 72.
Wrap file names, variables, commands, and code references in backticks.

Body

Skip the body for trivial changes where the subject is self-explanatory (typo fixes, renames, simple config tweaks).

When you do write a body:

Wrap lines at ~72 characters.
Separate paragraphs with a blank line.
Use backticks around file names, variables, and code references.
Optionally add a final paragraph on alternatives considered, when the chosen approach isn't obvious.

Other notes

Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Check the current branch. If on main or master, ask the user to confirm they really want to commit there. If they don't, ask for the branch name they'd like to use and switch (or create) that branch before continuing.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
Run git log -n 30 --pretty=format:%s to determine the repo's commit style and commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Show the user the proposed commit message (subject and body) and wait for approval before creating the commit. Apply any requested edits and re-confirm. Use AskUserQuestion for a structured approve/edit prompt when available, otherwise plain text. If the user explicitly opts out of review for the current task (e.g. "just commit", "no need to review"), skip the prompt.
Run git commit -m "<subject>" (and -m "<body>" if needed).