Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

commit-changes

Estrelas1

Forks0

Atualizado26 de abril de 2026 às 21:25

Generate a smart commit message from staged or unstaged changes and create a commit. Use when the user wants to commit their work with a meaningful message.

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

kevinreber

kevinreber/claude-code-configs

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	commit-changes
description	Generate a smart commit message from staged or unstaged changes and create a commit. Use when the user wants to commit their work with a meaningful message.

Commit Changes

Analyze current changes and generate a meaningful commit message following Conventional Commits specification.

Instructions

Check for changes:
- Run git status to see what files have changed
- If there are unstaged changes, ask user if they want to stage all or specific files
Stage files if needed:
- If user wants to stage all: git add -A
- If specific files: git add <files>
Analyze staged changes:
- Run git diff --cached --stat to see what's staged
- Run git diff --cached to see detailed changes
- Analyze the changes to understand what was done
Show diff preview to user:
- Run git diff --cached to get the full staged diff
- Present the diff to the user so they can review exactly what will be committed
- Ask if they want to proceed or make any changes before continuing
Generate commit message following Conventional Commits:

Format:
```
<type>(<scope>): <subject>

<body>

<footer>
```
Types:
- feat: New feature
- fix: Bug fix
- docs: Documentation only
- style: Formatting, missing semicolons, etc.
- refactor: Code change that neither fixes a bug nor adds a feature
- perf: Performance improvement
- test: Adding or updating tests
- chore: Maintenance tasks, dependency updates
- ci: CI/CD changes
- build: Build system changes
Guidelines:
- Subject line: max 50 characters, imperative mood (e.g., "add", "fix", "update")
- Body: wrap at 72 characters, explain what and why (not how)
- Reference issues when applicable (e.g., "Closes #123", "Fixes #456")
- Add Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> in footer

Present the commit message:

Suggested commit message:

feat(auth): add OAuth2 login support

Implement Google and GitHub OAuth2 providers for user authentication.
This replaces the legacy session-based auth system.

- Add OAuth2 configuration endpoints
- Implement token refresh logic
- Update user model with provider fields

Closes #123

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Ask for approval:
- Show the generated message to the user
- Ask if they want to commit with this message or modify it
Create the commit:
- Use HEREDOC format for proper multi-line message:
```
git commit -m "$(cat <<'EOF'
<commit message here>
EOF
)"
```
Confirm success:
- Run git log -1 --oneline to show the commit was created
- Display the commit hash and message

Important Notes

Always analyze the actual changes, don't guess
Subject should be clear and concise (max 50 chars)
Use imperative mood: "add feature" not "added feature"
Body should explain WHY, not just WHAT
Break down complex changes into bullet points
Always add the Co-Authored-By footer
Use HEREDOC for multi-line commit messages
If changes span multiple concerns, suggest splitting into multiple commits
Reference issue numbers when relevant (e.g., JIRA tickets, GitHub issues)

Mais deste repositório

mesmo repositório

fable

kevinreber/claude-code-configs

Adopt Fable-class working discipline for this session — outcome-first communication, finish-the-turn autonomy, parallel tool use, faithful reporting. Use when the user says "/fable", "fable mode", "act like fable", or wants a smaller model (Opus, Sonnet) to work with the discipline of a Mythos-class model. Also invocable from other skills as a style preamble for long or high-stakes tasks.

2026-07-091

daily-recap-v2

kevinreber/claude-code-configs

Full workday recap across all tools — Jira, GitHub, Slack, Confluence, Google Docs, and Claude Code activity. Stores all data in SQLite with Turso sync for remote access. For Claude-only activity tracking, use /daily-review-v2 instead.

2026-05-171

daily-review-v2

kevinreber/claude-code-configs

Claude Code activity tracking with SQLite/Turso storage — standup, weekly rollups, project reports, brag doc, friction tracking, goal tracking, heatmap, export. Data syncs to Turso for remote access. For full workday recap across all tools, use /daily-recap-v2 instead.

2026-05-171

genericize

kevinreber/claude-code-configs

Transform a work-specific or company-specific skill/config into a generic, portable version. Replaces proprietary tools, internal URLs, and company references with generic equivalents while preserving the useful patterns and structure. Use when porting a work skill to the public config repo.

2026-04-291

sync-from-global

kevinreber/claude-code-configs

Sync ~/.claude/ global configs into this repo, sanitizing work-specific content (LinkedIn plugins, Captain MCP, work email, internal URLs). Use when the user wants to refresh this repo from their global Claude configs, pull in newly added skills/commands, or update sanitization rules. Two-pass flow with diff review before commit.

2026-04-291

brain

kevinreber/claude-code-configs

Deep discussion mode. No code changes, no file edits, no commands — pure thinking, exploration, and idea bouncing. Use when you want to explore a concept, design something, debate tradeoffs, or just think out loud. Claude will push back, ask questions, and present alternatives. Changes only happen if you explicitly say so.

2026-04-261

Commit Changes

Analyze current changes and generate a meaningful commit message following Conventional Commits specification.

Instructions

Check for changes:

Run git status to see what files have changed
If there are unstaged changes, ask user if they want to stage all or specific files

Stage files if needed:

If user wants to stage all: git add -A
If specific files: git add <files>

Analyze staged changes:

Run git diff --cached --stat to see what's staged
Run git diff --cached to see detailed changes
Analyze the changes to understand what was done

Show diff preview to user:

Run git diff --cached to get the full staged diff
Present the diff to the user so they can review exactly what will be committed
Ask if they want to proceed or make any changes before continuing

Generate commit message following Conventional Commits:

Format:

<type>(<scope>): <subject>

<body>

<footer>

Types:

feat: New feature
fix: Bug fix
docs: Documentation only
style: Formatting, missing semicolons, etc.
refactor: Code change that neither fixes a bug nor adds a feature
perf: Performance improvement
test: Adding or updating tests
chore: Maintenance tasks, dependency updates
ci: CI/CD changes
build: Build system changes

Guidelines:

Subject line: max 50 characters, imperative mood (e.g., "add", "fix", "update")
Body: wrap at 72 characters, explain what and why (not how)
Reference issues when applicable (e.g., "Closes #123", "Fixes #456")
Add Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> in footer

Present the commit message:

Suggested commit message:

feat(auth): add OAuth2 login support

Implement Google and GitHub OAuth2 providers for user authentication.
This replaces the legacy session-based auth system.

- Add OAuth2 configuration endpoints
- Implement token refresh logic
- Update user model with provider fields

Closes #123

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Ask for approval:

Show the generated message to the user
Ask if they want to commit with this message or modify it

Create the commit:

Use HEREDOC format for proper multi-line message:

git commit -m "$(cat <<'EOF'
<commit message here>
EOF
)"

Confirm success:

Run git log -1 --oneline to show the commit was created
Display the commit hash and message

Important Notes

Always analyze the actual changes, don't guess

Subject should be clear and concise (max 50 chars)

Use imperative mood: "add feature" not "added feature"

Body should explain WHY, not just WHAT

Break down complex changes into bullet points

Always add the Co-Authored-By footer

Use HEREDOC for multi-line commit messages

If changes span multiple concerns, suggest splitting into multiple commits

Reference issue numbers when relevant (e.g., JIRA tickets, GitHub issues)