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

commit-all

스타2,307

포크345

업데이트2026년 4월 9일 19:35

Use this skill when the user asks to "commit all", "commit everything", or wants all outstanding changes committed. Groups unrelated changes into separate, well-described commits instead of one catch-all commit.

설치

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

Manus에서 실행

출처

spacedriveapp

spacedriveapp/spacebot

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

다운로드

Manus에서 실행

Commit All

Goal

Commit every outstanding change in the working tree — but group unrelated changes into separate, informative commits so the git history stays useful.

Workflow

Survey all changes. Run git status and git diff (staged + unstaged) to see the full picture. Include untracked files.
Identify logical groups. Cluster files by the change they belong to. A "group" is a set of files that were modified for the same reason (e.g. a bug fix, a new feature, a config tweak, a dependency update). Use file paths, diff content, and your understanding of the codebase to decide.
Order commits. Infra/config/dependency changes first, then library/core changes, then feature/UI changes, then docs/polish.
For each group, create one commit:
- Stage only the files belonging to that group (git add <file> ...). Never use git add -A or git add ..
- Write a concise, informative commit message that describes what changed and why. Follow the repo's existing commit style (check git log --oneline -10).
- Do not lump unrelated changes together just because they're small.
Verify. After all commits, run git status to confirm the tree is clean. Run git log --oneline -n <N> (where N = number of commits created) to show the user what was committed.

Commit Message Rules

Keep the subject line under 72 characters.
Use imperative mood ("add", "fix", "update", not "added", "fixes").
If a change is trivial (whitespace, typo, formatting), it's fine to batch those into one commit labeled accordingly.
End every commit message with the Co-Authored-By trailer.

Hard Rules

Never combine unrelated changes in one commit.
Never skip or discard changes — everything gets committed.
Never use git add -A or git add ..
Do not push. Only commit locally.
Do not commit files that look like they contain secrets (.env, credentials, tokens). Warn the user about those instead.

이 저장소의 다른 Skills

같은 저장소

wiki-writing

spacedriveapp/spacebot

Use when creating or substantially editing wiki pages. Covers language, tone, structure, page type selection, linking discipline, and what separates a useful wiki article from filler.

2026-04-082.3k

writing-guide

spacedriveapp/spacebot

Use when writing or editing any Spacebot copy — README sections, docs, release notes, marketing text, design doc summaries. Covers voice, tone, patterns to avoid, and what good Spacebot writing sounds like.

2026-04-052.3k

prompt-review

spacedriveapp/spacebot

This skill should be used when the user asks to "review the prompt", "audit the system prompt", "check prompt quality", "inspect what the LLM sees", "debug prompt issues", or "find prompt engineering problems". Pulls the live rendered prompt via the API, explains how it's composed, and reviews it for issues.

2026-03-212.3k

release-bump-changelog

spacedriveapp/spacebot

Use this skill when preparing a release bump or updating release notes. It writes a launch-style release story from the actual change set, then runs `cargo bump` so the generated GitHub notes and the marketing copy land together in `CHANGELOG.md`.

2026-03-042.3k

async-state-safety

spacedriveapp/spacebot

This skill should be used when the user asks to change "worker lifecycle", "cancellation", "retrigger behavior", "state machine", "delivery receipts", "timeouts", or "race conditions". Enforces explicit async/state invariants and targeted race-safe verification.

2026-02-262.3k

messaging-adapter-parity

spacedriveapp/spacebot

This skill should be used when the user asks to change "Slack adapter", "Telegram adapter", "Discord adapter", "Webhook adapter", "status delivery", "message routing", or "delivery receipts". Enforces cross-adapter parity and explicit delivery semantics.

2026-02-262.3k

name	commit-all
description	Use this skill when the user asks to "commit all", "commit everything", or wants all outstanding changes committed. Groups unrelated changes into separate, well-described commits instead of one catch-all commit.

Commit All

Goal

Commit every outstanding change in the working tree — but group unrelated changes into separate, informative commits so the git history stays useful.

Workflow

Survey all changes. Run git status and git diff (staged + unstaged) to see the full picture. Include untracked files.
Identify logical groups. Cluster files by the change they belong to. A "group" is a set of files that were modified for the same reason (e.g. a bug fix, a new feature, a config tweak, a dependency update). Use file paths, diff content, and your understanding of the codebase to decide.
Order commits. Infra/config/dependency changes first, then library/core changes, then feature/UI changes, then docs/polish.
For each group, create one commit:
- Stage only the files belonging to that group (git add <file> ...). Never use git add -A or git add ..
- Write a concise, informative commit message that describes what changed and why. Follow the repo's existing commit style (check git log --oneline -10).
- Do not lump unrelated changes together just because they're small.
Verify. After all commits, run git status to confirm the tree is clean. Run git log --oneline -n <N> (where N = number of commits created) to show the user what was committed.

Commit Message Rules

Keep the subject line under 72 characters.
Use imperative mood ("add", "fix", "update", not "added", "fixes").
If a change is trivial (whitespace, typo, formatting), it's fine to batch those into one commit labeled accordingly.
End every commit message with the Co-Authored-By trailer.

Hard Rules

Never combine unrelated changes in one commit.
Never skip or discard changes — everything gets committed.
Never use git add -A or git add ..
Do not push. Only commit locally.
Do not commit files that look like they contain secrets (.env, credentials, tokens). Warn the user about those instead.