commit

星标0

分支0

更新时间2026年5月13日 16:57

Create a well-formed git commit from the current changes. Use when finalizing staged work, preparing a commit message, or splitting in-progress work into reviewable history.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

anantjain-xyz

anantjain-xyz/symphony-ts

打开 GitHub 仓库查看创作者相关仓库

下载

Commit

Goals

Produce a commit whose subject and body match the actual staged diff and the session's intent.
Follow the repo's existing convention (run git log --oneline -20 first; conventional-commit prefixes are common but the leading-identifier style — SYM-31: etc. — also appears).
Never --no-verify. If a hook fails, fix the underlying problem and create a new commit.

Inputs

git status, git diff, git diff --staged for actual changes.
Recent commit messages on the branch and in origin/main for style.
The Symphony Workpad on the current Linear issue for scope/intent.

Steps

Inspect: git status, git diff, git diff --staged.
Stage intended changes by name (git add <paths>). Avoid git add -A / git add . — they sweep in .env, credentials, large binaries, or artifacts you didn't mean to ship.
Sanity-check newly staged files. Build artifacts, logs, screenshots, and .symphony-workspace-ready must stay unstaged. Exception: .symphony/screenshots/<name>.png is intentionally staged by the screenshot skill's throwaway commit (which also --no-verifys, the only place that's allowed) and is removed by the same skill's force-push step.
Pick a subject (≤ 72 chars, imperative mood, no trailing period). Match the dominant style on the branch — usually <TYPE>(<scope>): <summary> or <IDENTIFIER>: <summary>.
Write the body via heredoc so newlines are literal:
- One short paragraph (the why, plus tradeoffs if non-obvious).
- Optional bullets summarizing what changed across multiple files.
Verify the message describes only what's staged. If the message and the diff disagree, fix the index — not the message.
Run git commit -F <file> (or the heredoc form) so newlines are real, not literal \n.

Template

<type>(<scope>): <short imperative summary>

<one-paragraph rationale: why this change, what it unblocks, any tradeoff>

- <key change 1>
- <key change 2>

Don't

Don't use git commit -m "$(printf 'a\nb')" — it's brittle. Use a heredoc.
Don't amend a published commit unless explicitly asked.
Don't bypass hooks (--no-verify, --no-gpg-sign). If a hook fails, fix the cause.

同仓库更多 Skills

同仓库

screenshot

anantjain-xyz/symphony-ts

Capture Playwright screenshots of a user-facing change and embed them in the GitHub PR description via a temporary commit + force-push. Use whenever the workflow asks for proof-of-testing screenshots on a user-facing change.

2026-05-130

workpad

anantjain-xyz/symphony-ts

Manage the single Symphony Workpad comment on a Linear issue — find or bootstrap, update in place, or reset (Rework). Use whenever the workflow needs to read or write the workpad. Includes the GraphQL `commentUpdate` workaround for the known Linear MCP `save_comment` duplication bug.

2026-05-130

land

anantjain-xyz/symphony-ts

Squash-merge the issue's PR once it's approved and green. Use only when the issue is in the `Merging` state — Symphony's status router gates entry.

2026-04-300

pr-feedback

anantjain-xyz/symphony-ts

Sweep the PR for actionable reviewer feedback (top-level comments, inline review comments, review states) and resolve every item before moving to In Review. Use after every push that might have triggered review, and as the gate before transitioning the issue to In Review.

2026-04-270

pull

anantjain-xyz/symphony-ts

Sync the current branch with origin/main via merge (not rebase) and resolve any conflicts. Use whenever Symphony's workflow says "merge origin/main into the branch" — at Step 1 setup, before push, and as part of the Land procedure.

2026-04-270

push

anantjain-xyz/symphony-ts

Push the current branch to origin and ensure a PR exists for it (creating or updating one), with the symphony label applied. Use when the workflow says "push" or "open a PR".

2026-04-270

Commit

Goals

Produce a commit whose subject and body match the actual staged diff and the session's intent.

Follow the repo's existing convention (run git log --oneline -20 first; conventional-commit prefixes are common but the leading-identifier style — SYM-31: etc. — also appears).

Never --no-verify. If a hook fails, fix the underlying problem and create a new commit.

Inputs

git status, git diff, git diff --staged for actual changes.

Recent commit messages on the branch and in origin/main for style.

The Symphony Workpad on the current Linear issue for scope/intent.

Steps

Inspect: git status, git diff, git diff --staged.

Stage intended changes by name (git add <paths>). Avoid git add -A / git add . — they sweep in .env, credentials, large binaries, or artifacts you didn't mean to ship.

Sanity-check newly staged files. Build artifacts, logs, screenshots, and .symphony-workspace-ready must stay unstaged. Exception: .symphony/screenshots/<name>.png is intentionally staged by the screenshot skill's throwaway commit (which also --no-verifys, the only place that's allowed) and is removed by the same skill's force-push step.

Pick a subject (≤ 72 chars, imperative mood, no trailing period). Match the dominant style on the branch — usually <TYPE>(<scope>): <summary> or <IDENTIFIER>: <summary>.

Write the body via heredoc so newlines are literal:

One short paragraph (the why, plus tradeoffs if non-obvious).
Optional bullets summarizing what changed across multiple files.

Verify the message describes only what's staged. If the message and the diff disagree, fix the index — not the message.

Run git commit -F <file> (or the heredoc form) so newlines are real, not literal \n.

Template

<type>(<scope>): <short imperative summary> <one-paragraph rationale: why this change, what it unblocks, any tradeoff> - <key change 1> - <key change 2>

Don't

Don't use git commit -m "$(printf 'a\nb')" — it's brittle. Use a heredoc.

Don't amend a published commit unless explicitly asked.

Don't bypass hooks (--no-verify, --no-gpg-sign). If a hook fails, fix the cause.

name	commit
description	Create a well-formed git commit from the current changes. Use when finalizing staged work, preparing a commit message, or splitting in-progress work into reviewable history.