commit

Étoiles0

Forks0

Mis à jour13 mai 2026 à 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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

anantjain-xyz

anantjain-xyz/symphony-ts

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

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.

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.

Plus depuis ce dépôt

même dépôt

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.