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

시작하기

dotfiles-commit

스타3

포크1

업데이트2026년 5월 24일 01:47

Stage and commit changes in this dotfiles repo using Conventional Commits

설치

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

Manus에서 실행

출처

chocoby

chocoby/dotfiles

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

다운로드

Manus에서 실행

Dotfiles Commit

Use this skill when the user wants to commit changes in this dotfiles repository.

Commit Message Convention

Format: <type>(<scope>): <subject> — single line, no body, no footer, no trailing period.

<type>: see Type Guidelines below.
<scope>: lowercase component name from the mapping table (omit only when truly cross-cutting).
<subject>: imperative mood, lowercase first word, concise.

Examples:

feat(tmux): enable extended keys
feat(ghostty): enable left Option key as Alt
feat(mise): install gnupg on macOS
feat(git): add git-commit-with-claude script and gcic alias
fix(homebrew): correct package name
chore(claude): update permissions
chore(chezmoi): add zsh to brew bundle
refactor(neovim): migrate nvim-treesitter to main branch

Scope Mapping

Determine the scope from changed file paths:

Path pattern	Scope
`dot_config/nvim/` or `nvim`	`neovim`
`dot_config/ghostty/`	`ghostty`
`dot_config/tmux/` or `dot_tmux`	`tmux`
`.mise.toml` or `mise/`	`mise`
`.claude/` or `dot_claude/`	`claude`
`dot_config/starship.toml`	`starship`
`Brewfile` or homebrew-related	`homebrew`
`.chezmoi*` or chezmoi config	`chezmoi`
`dot_config/git/` or `.gitconfig`	`git`
Multiple components	Use the primary one, or omit scope if truly cross-cutting

Type Guidelines

feat — new config, new feature, new tool enabled
fix — correct a bug or broken config
docs — documentation only (README, CLAUDE.md, skill docs, comments)
refactor — restructure without behavior change (e.g. migrate to new API/branch)
chore — maintenance: dependency/version bumps, permissions, housekeeping
revert — undo a previous change

When in doubt between feat and chore: user-visible behavior change → feat; internal upkeep → chore.

Workflow

Run git status to see what has changed.
Run git diff (unstaged) and git diff --cached (staged) to understand the changes.
Identify the scope(s) from the file paths using the mapping table.
Determine the most appropriate type from the guidelines.
Craft a concise subject in imperative mood (lowercase first word, no trailing period).
Show the proposed commit message to the user and ask for confirmation before committing.
Stage the relevant files (git add) — prefer specific files over git add -A.
Commit with the agreed message.

Rules

Always confirm the commit message with the user before committing.
Never use git add -A without listing what will be staged.
Do not push unless the user explicitly requests it.
Keep the subject short — one line, no trailing punctuation.
If changes span multiple scopes, prefer the primary scope or split into separate commits.

이 저장소의 다른 Skills

같은 저장소

push-draft-pr

chocoby/dotfiles

Push the current git branch and open a pull request (draft by default) with a concise, reviewer-focused Japanese description. Use whenever the user wants to push and open a PR for the current branch, asks to create/open/send up a PR or draft PR, or wants a reviewer-focused PR description generated — including casual Japanese phrasings like 「pr 作って」「PR 出して」「push して PR 出して」「draft PR を作って」「PR の description を考えて」. Default to draft; the workflow itself confirms with the user before creating.

2026-06-103

implement-issue

chocoby/dotfiles

Notion リンクまたは GitHub issue を起点に、最新のメインブランチからブランチを切って実装し、/simplify → 全テスト確認 → /push-draft-pr まで通すスキル。チケット (Notion / GitHub issue) を渡して「これを実装して PR まで出して」と頼むときに使う。「implement-issue」「この issue 実装して」「Notion 読んで作業して PR 出して」等で起動。読み込みから draft PR 作成まで自律実行する。

2026-06-043

Dotfiles Commit

Use this skill when the user wants to commit changes in this dotfiles repository.

Commit Message Convention

Format: <type>(<scope>): <subject> — single line, no body, no footer, no trailing period.

<type>: see Type Guidelines below.

<scope>: lowercase component name from the mapping table (omit only when truly cross-cutting).

<subject>: imperative mood, lowercase first word, concise.

Examples:

feat(tmux): enable extended keys

feat(ghostty): enable left Option key as Alt

feat(mise): install gnupg on macOS

feat(git): add git-commit-with-claude script and gcic alias

fix(homebrew): correct package name

chore(claude): update permissions

chore(chezmoi): add zsh to brew bundle

refactor(neovim): migrate nvim-treesitter to main branch

Scope Mapping

Determine the scope from changed file paths:

Path pattern

Scope

dot_config/nvim/ or nvim

neovim

dot_config/ghostty/

ghostty

dot_config/tmux/ or dot_tmux

tmux

.mise.toml or mise/

mise

.claude/ or dot_claude/

claude

dot_config/starship.toml

starship

Brewfile or homebrew-related

homebrew

.chezmoi* or chezmoi config

chezmoi

dot_config/git/ or .gitconfig

git

Multiple components

Use the primary one, or omit scope if truly cross-cutting

Type Guidelines

feat — new config, new feature, new tool enabled

fix — correct a bug or broken config

docs — documentation only (README, CLAUDE.md, skill docs, comments)

refactor — restructure without behavior change (e.g. migrate to new API/branch)

chore — maintenance: dependency/version bumps, permissions, housekeeping

revert — undo a previous change

When in doubt between feat and chore: user-visible behavior change → feat; internal upkeep → chore.

Workflow

Run git status to see what has changed.

Run git diff (unstaged) and git diff --cached (staged) to understand the changes.

Identify the scope(s) from the file paths using the mapping table.

Determine the most appropriate type from the guidelines.

Craft a concise subject in imperative mood (lowercase first word, no trailing period).

Show the proposed commit message to the user and ask for confirmation before committing.

Stage the relevant files (git add) — prefer specific files over git add -A.

Commit with the agreed message.

Rules

Always confirm the commit message with the user before committing.

Never use git add -A without listing what will be staged.

Do not push unless the user explicitly requests it.

Keep the subject short — one line, no trailing punctuation.

If changes span multiple scopes, prefer the primary scope or split into separate commits.

name	dotfiles-commit
description	Stage and commit changes in this dotfiles repo using Conventional Commits