symphony-commit

Estrelas11

Forks1

Atualizado17 de julho de 2026 às 05:27

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.

Instalação

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ê.

Fonte

anantjain-xyz

anantjain-xyz/symphony-rust

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	symphony-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, .symphony-workspace-ready, and locally injected fallback skills under .agents/skills/symphony-* or .claude/skills must stay unstaged unless the issue explicitly asks to install or change Symphony skills. Exception: .symphony/screenshots/<name>.png is intentionally staged only by the symphony-screenshot skill's temporary evidence commit (which also --no-verifys, the only place that's allowed); that skill then creates a cleanup revert commit so the files do not remain in the latest tree while the evidence commit remains in branch history.
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.

Mais deste repositório

mesmo repositório

symphony-pull

anantjain-xyz/symphony-rust

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-07-2711

symphony-push

anantjain-xyz/symphony-rust

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-07-2711

symphony-pull

anantjain-xyz/symphony-rust

2026-07-2711

symphony-push

anantjain-xyz/symphony-rust

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-07-2711

symphony-land

anantjain-xyz/symphony-rust

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-07-1711

symphony-pr-feedback

anantjain-xyz/symphony-rust

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-07-1711

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, .symphony-workspace-ready, and locally injected fallback skills under .agents/skills/symphony-* or .claude/skills must stay unstaged unless the issue explicitly asks to install or change Symphony skills. Exception: .symphony/screenshots/<name>.png is intentionally staged only by the symphony-screenshot skill's temporary evidence commit (which also --no-verifys, the only place that's allowed); that skill then creates a cleanup revert commit so the files do not remain in the latest tree while the evidence commit remains in branch history.

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.