com um clique
commit
Commit session changes with intelligent splitting for large changesets
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ê.
Menu
Commit session changes with intelligent splitting for large changesets
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ê.
Baseado na classificação ocupacional SOC
| name | commit |
| disable-model-invocation | true |
| description | Commit session changes with intelligent splitting for large changesets |
| argument-hint | [--dry-run] [--single] [--all] [--message <msg>] |
Analyze uncommitted changes, group them intelligently by logic (not just paths), and create well-structured commits.
Respond and reason in whatever language the user addressed you in — write user-facing text (the commit plan, the execution summary, questions, error messages) in that language and think in it too.
Critical exception — commit messages are ALWAYS in English, regardless of the user's language. The user's language affects only the report shown to the user, never the text written into git. Likewise, never translate code, identifiers, file paths, or commands.
--amend — always create a new commit.Co-Authored-By: lines,
"Generated with Claude" / "🤖 Generated with..." footers, or any text crediting an AI model
or tool. Commit messages contain only the change description.If the change relates to a build-backlog task (one of .buildloop/build-plan/tasks/T###-*.md), include the
task id and what was done in the commit message — the id as a [T###] tag in the subject line. This
makes each commit traceable to the task it advances. build-product checkpoint commits always pass
the id of the task they finalize.
<type>: <description> [T012]. Put what was done in the body if the subject
doesn't capture it.build-product invocation that triggered the commit, or from the task
whose files the change implements; if a change clearly maps to no task, treat it as not-backlog-related.Arguments provided via $ARGUMENTS:
Examples:
/commit - Auto-analyze and commit (split if needed)/commit --dry-run - Preview what would be committed/commit --single - Force single commit/commit --message "feat: Add user auth" - Use specific messageBy default, ONLY commit files that were changed during this session. Do NOT commit pre-existing uncommitted changes.
How to determine session changes:
gitStatus snapshot taken at session start. Parse the list of dirty files from it.git status --porcelain now to get the current dirty files.Override: If the user explicitly asks to commit all changes (e.g., /commit --all), skip this filter and commit everything.
# Get all changed files (then filter to session-only as per Step 0)
git status --porcelain
# Get recent commits for style reference
git log --oneline -10 --format='%s'
# Get diff ONLY for session-changed files (pass file paths explicitly)
git diff HEAD -- <session-changed-file1> <session-changed-file2> ...
Key insight: Distinguish between core changes and ripple effects.
Core changes (commit separately):
Ripple changes (group together):
Detection patterns:
A. Detect ripple patterns first:
Example: Button.tsx changes Button props interface
+ 20 files updating Button usage
Commit 1: "refactor: Add variant prop to Button component"
- components/ui/Button.tsx (the definition)
- types/components.ts (if types changed)
Commit 2: "refactor: Update Button usages for new variant prop"
- All 20 files with usage updates
B. Group by logical feature:
types/*.ts + components/*.tsx + hooks/*.tsapp/api/*/route.ts + components/*hooks/use*.ts + components using itC. Path-based fallback:
| Path Pattern | Category |
|---|---|
components/** | Components |
app/** | Pages/Routes |
lib/** | Utilities |
hooks/** | Hooks |
types/** | Types |
utils/** | Utilities |
styles/** | Styles |
public/** | Assets |
Single commit when:
--single flag provided, OR--message flag providedMulti-commit when:
Commit messages are always written in English (see Language).
Do NOT include any co-author or attribution trailers (no Co-Authored-By:, no "Generated with
Claude" footer, no AI/model credit). The message holds only <type>: <description> and an
optional body.
Format:
<type>: <Short description (imperative, <70 chars)> [<task-id> if backlog-related]
<Optional body explaining why / what was done>
Types:
feat: - New functionalityfix: - Bug fixesrefactor: - Code restructuringchore: - Maintenance, toolingdocs: - Documentationtest: - Test changesstyle: - Styling changes (CSS, formatting)For each commit group:
git add . or git add -A):git add path/to/file1.tsx path/to/file2.ts
git commit -m "$(cat <<'EOF'
feat: Add authentication service
Implement OAuth2 flow with refresh token support.
EOF
)"
git log -1 --oneline
All user-facing text below is rendered in the user's language. The commit messages embedded in it stay in English.
## Commit Plan (Dry Run)
**Files changed**: 25
**Proposed commits**: 2
### Commit 1: Core Change
**Type**: refactor
**Files** (2):
- components/ui/Button.tsx
- types/components.ts
**Message**:
> refactor: Add size prop to Button component
---
### Commit 2: Usage Updates
**Type**: refactor
**Files** (23):
- components/header/NavButton.tsx
- components/forms/SubmitButton.tsx
- ... (21 more files)
**Message**:
> refactor: Update Button usages with size prop
---
Run `/commit` to execute.
## Commits Created
### Commit 1/2
$ git add components/ui/Button.tsx types/components.ts
$ git commit -m "refactor: Add size prop..."
[main abc1234] refactor: Add size prop to Button component
2 files changed, 25 insertions(+), 8 deletions(-)
### Commit 2/2
$ git add components/header/NavButton.tsx ...
$ git commit -m "refactor: Update Button usages..."
[main def5678] refactor: Update Button usages with size prop
23 files changed, 46 insertions(+), 46 deletions(-)
---
**Summary**: Created 2 commits
def5678 refactor: Update Button usages with size prop
abc1234 refactor: Add size prop to Button component
| Scenario | Action |
|---|---|
| No changes | Report "No changes to commit" and exit |
| Pre-commit hook fails | Show error, offer to fix, create NEW commit (never amend) |
| Merge conflicts | Report files with conflicts, ask user to resolve |
If commit fails due to pre-commit hooks:
User: /commit
Claude: Analyzing uncommitted changes...
$ git status --porcelain
M components/ui/Card.tsx
M types/ui.ts
M components/dashboard/StatsCard.tsx
M components/dashboard/UserCard.tsx
M components/products/ProductCard.tsx
M app/page.tsx
... (15 more files)
Analyzing diffs...
Detected ripple pattern:
- Card.tsx: Changed Card component props (added `elevated` prop)
- types/ui.ts: Added CardProps type update
- 15 other files: Updating Card usage
Splitting into 2 commits:
### Commit 1/2: Core Change
$ git add components/ui/Card.tsx types/ui.ts
$ git commit -m "$(cat <<'EOF'
feat: Add elevated prop to Card component
Add visual elevation option with shadow effects.
EOF
)"
[main a1b2c3d] feat: Add elevated prop to Card component
2 files changed, 18 insertions(+), 4 deletions(-)
### Commit 2/2: Usage Updates
$ git add components/dashboard/StatsCard.tsx components/dashboard/UserCard.tsx ...
$ git commit -m "$(cat <<'EOF'
refactor: Update Card usages with elevated prop
EOF
)"
[main d4e5f6g] refactor: Update Card usages with elevated prop
15 files changed, 30 insertions(+), 15 deletions(-)
---
**Summary**: Created 2 commits
d4e5f6g refactor: Update Card usages with elevated prop
a1b2c3d feat: Add elevated prop to Card component
User: /commit
Claude: Analyzing uncommitted changes...
$ git status --porcelain
M components/forms/LoginForm.tsx
Found 1 changed file. Creating single commit...
$ git add components/forms/LoginForm.tsx
$ git commit -m "$(cat <<'EOF'
fix: Handle empty email validation gracefully
Add check for empty string before email format validation.
EOF
)"
[main x1y2z3a] fix: Handle empty email validation gracefully
1 file changed, 5 insertions(+), 2 deletions(-)
---
**Summary**: Created 1 commit
x1y2z3a fix: Handle empty email validation gracefully
Webinar DEMO variant of the release phase — runs the real SECURITY audit (the star of this act) and prints a pre-deploy CHECKLIST, for a live before/after demo. Use only for the vibe-coding course demo, NOT for real releases (that's release-product). By default it spawns the genuine audit-security skill as a fresh, read-only subagent and renders its findings as a green/red pre-deploy checklist — the payoff being to SHOW that the method finds real security problems before shipping (leaked keys, missing auth, injection) versus a vibe-coder who just deploys and hopes. Performance is OPTIONAL (--with-performance). REPORT-ONLY: it does NOT file rework tasks, does NOT loop fixes, and does NOT cut a release / bump versions. Reuses the real audit; only the fix/ship machinery is stripped.
Webinar DEMO variant of the spec pipeline — the REAL staged flow (gather-context → product requirements → architecture → dev-architecture), just compressed, NOT the full create-project-spec. Use only for the vibe-coding course demo. It runs four real, SEQUENTIAL stages with an approval gate between each: (1) gather-context interviews the user AND critically pushes back on what they propose; (2) it drafts the functional/product requirements and stops for ok/not-ok; (3) it proposes an architecture (options + trust boundaries) and stops for ok/not-ok; (4) it proposes the dev-architecture (the verification tooling — e.g. Playwright — the build act later uses) and stops. Shorter than the real pipeline (no research subagents, no adversarial-review subagents, no dual outputs, drops validate-idea/user-flows/design phases) but keeps the staged, gated, critical structure. Writes the same filenames the build/release demos read, so the three acts chain.
Webinar DEMO variant of the build loop — builds ONE feature with the real implementer/verifier two-agent mechanism, for a live before/after demo. Use only for the vibe-coding course demo, NOT for real builds (that's build-product). It skips the kanban planning entirely: it writes a single throwaway task file for the feature you name, spawns the real implementer agent to build it, then spawns the SEPARATE, fresh verifier agent to independently find bugs and hand them back — the whole point being to SHOW the second agent catching real bugs in the first agent's work, versus a naive 'it works, ship it'. HARD-CAPPED at 2 implement↔verify iterations (usually 1 is enough) so it fits a webinar slot. Reuses the genuine agents/mechanism — only the surrounding kanban is stripped.
Design the development-time architecture that lets the product be built fast and well with AI: how to run the whole product locally (Docker Compose topology, local stand-ins for cloud/managed services with prod-equivalent APIs, seed data), how it is tested in an AI-drivable way (test levels + purpose-built developer/test scripts + an e2e harness an agent can run and verify, e.g. Playwright for web), how concurrent access to the single shared local environment is coordinated (lock and/or per-run isolation), and how the AI tooling is configured for the chosen stack (Claude Code config, which Anthropic plugins/skills to install, MCP servers, other agents) — including the custom, project-local Claude Code skills to author that wrap those dev/test scripts and the e2e harness so future agents run the verification loop by name — backed by research into the current tools and an adversarial review pass. Use after design-architecture (reads .buildloop/project-spec/architecture.research.md and .buildloop/project-spec/us
Turn the finished project spec into a buildable backlog. Use after setup-dev-environment, as the planning step of the build/development phase, to read the committed feature set (.buildloop/project-spec/product-requirements.research.md), the user flows, the architecture, and the dev-architecture (incl. its developer/test scripts and the custom project skills that wrap them, which become build-out/authoring tasks), and emit a kanban backlog under .buildloop/build-plan/: one markdown file per task (type, status, blockers, acceptance criteria, provenance), plus a derived board.md and a short plan.summary.md. Single pass — each task's blocked_by list IS the dependency graph; there is no parallel scheduling. For an existing project (project_type: existing) it runs in delta mode: it diffs the target spec against the reverse-engineered codebase-map and emits ONLY the gap (rework for divergent code, new tasks for unbuilt features, verify tasks for adopted features, a quality-gate setup task), marking already-matching
Turn the dev-architecture spec into a real, runnable local environment. Use after the project-spec pipeline (reads .buildloop/project-spec/dev-architecture.research.md and architecture.research.md + adr/*), as the first step of the build/development phase, to scaffold the repo and bring up the inner loop: install tooling, init the repo (.gitignore, project CLAUDE.md, settings.json), write the Docker Compose stack + seed data + one-command bring-up, wire the AI tooling (MCP servers, plugins), and scaffold skeleton stubs of the developer/test scripts and the custom project skills (.claude/skills/) the dev-architecture specified. Runs an internal plan → approve → execute: it plans everything but auto-executes only repo-local scaffolding; global installs, API keys, and Claude plugins run only with explicit confirmation. Idempotent (safe to re-run), detect-state-first. For an existing project (project_type: existing) it runs in adopt mode: it reads the reverse-engineered codebase-map, adopts and extends what's alr