Run any Skill in Manus with one click

Get Started

dotfiles-commit

Stars3

Forks1

UpdatedMay 24, 2026 at 01:47

Stage and commit changes in this dotfiles repo using Conventional Commits

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

chocoby

chocoby/dotfiles

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

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

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.

More from this repository

same repository

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.