Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

Começar

dotfiles-commit

Estrelas3

Forks1

Atualizado24 de maio de 2026 às 01:47

Stage and commit changes in this dotfiles repo using Conventional Commits

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

chocoby

chocoby/dotfiles

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·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.

Mais deste repositório

mesmo repositório

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.