From cape
Create atomic git commits with conventional commit format and selective staging. Use whenever the user wants to commit changes — explicit requests ("commit this", "make a commit", "let's commit", "/cape:commit") and implicit ones ("we're done, save this", "wrap this up"). Also use when another cape skill finishes a unit of work and needs to commit. Covers staging decisions, splitting large diffs into separate logical commits, and writing thorough commit messages that explain the change. Do NOT use for pushing, creating PRs, or branch operations.
npx claudepluginhub sqve/cape --plugin capeThis skill uses the workspace's default tool permissions.
<skill_overview> Stage selectively and commit one logical change at a time using conventional commit
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
<skill_overview> Stage selectively and commit one logical change at a time using conventional commit format. Reads the diff, groups changes by concern, proposes staging and a message, then commits after approval. </skill_overview>
<rigidity_level> MEDIUM FREEDOM — Adapt message style and body depth to project conventions. The staging plan, conventional format, and user confirmation before committing are non-negotiable. </rigidity_level>
<when_to_use>
Don't use for:
--no-confirm is also passed.<critical_rules>
--no-verify unless the user explicitly askstype(scope): subject matching project conventions</critical_rules>
<the_process>
cape git context
git diff HEAD
From recentLog, note the project's commit conventions — type prefixes used, whether scope is
common, subject line style, whether bodies are used.
If there are no changes to commit, tell the user and stop.
Read through all changes and identify logical groups — sets of changes that belong to a single concern. A logical group might be:
Signs that changes should be separate commits:
feat and chore mixed together)If everything belongs to one logical change, proceed to step 3 with a single group. If multiple groups exist, present them and handle each as a separate commit cycle (steps 3-5), starting with the most foundational change.
Present the plan:
Staging: path/to/file.ts, path/to/other.ts
Message: type(scope): subject line
Optional body explaining why this change was made,
not what it does (the diff shows the what).
Conventional commit format:
| Type | When to use |
|---|---|
feat | New functionality |
fix | Bug fix |
chore | Maintenance, config, dependencies, tooling |
refactor | Restructuring without behavior change |
docs | Documentation only |
test | Test-only changes |
style | Formatting, whitespace (no logic change) |
perf | Performance improvement |
Subject line rules:
Scope is optional. Use it when the change is clearly scoped to a module, feature, or directory. Derive scope from the project's recent commits — if the project uses scopes, follow the pattern; if it doesn't, omit.
Body is warranted when:
When writing the body, explain why the change was made, not what it does. The diff already shows the what.
Staging rules:
git add . or git add -A.env, credentials, secrets)You MUST stop here and get user approval before committing.
Wait for user approval. If the user edits the message or staging, apply their changes exactly. If
they reject entirely, ask what they'd prefer. Do not call git commit until the user approves.
Stage and commit using the CLI:
cape commit path/to/file.ts path/to/other.ts -m "$(cat <<'EOF'
type(scope): subject line
Body if warranted.
EOF
)"
The CLI validates the message format, detects sensitive files, and stages + commits in one operation.
If the commit fails (pre-commit hook, lint error):
After a successful commit, show:
git status --short to confirm stateIf there are remaining changes from another logical group, loop back to step 3 for the next commit.
</the_process>
Single logical change, no scope needed$ git diff HEAD
- changes to .gitignore and plugin.json
Staging: .gitignore, plugin.json
Message: chore: add gitignore and update plugin config
Two files, one concern (project setup), no scope needed.
Mixed concerns requiring split$ git diff HEAD
- new auth middleware (src/auth.ts, tests/auth.test.ts)
- unrelated typo fix in README.md
Group 1 (commit first):
Staging: src/auth.ts, tests/auth.test.ts
Message: feat(auth): add authentication middleware
Group 2:
Staging: README.md
Message: docs: fix typo in readme
Two unrelated changes split into two commits.
Change that warrants a bodyStaging: src/cache.ts, src/config.ts
Message: refactor(cache): replace LRU with TTL-based eviction
LRU eviction caused stale entries to persist when access patterns
were uniform. TTL guarantees freshness regardless of access frequency.
The subject says what changed; the body explains why.
<key_principles>
recentLog from context and follow existing conventions</key_principles>
<anti_patterns>
After presenting the staging plan and message, NEVER:
Present findings completely, then immediately proceed to the confirm step (or execute if
--no-confirm).
</anti_patterns>