molayabmolayab/swift-ai-provider-kit/.claude/skills/commit/SKILL.md

commit

Skill1 starsChanged 8 months agoMITView on GitHub

Stages and commits changes with a well-crafted message matching this project's style. Use when asked to 'commit', 'commit my changes', 'create a commit', 'write a commit message', or 'commit and push'.

Reads credentials

We split this skill into the rules it gives an agent

10 rules. 0 are common, 8 are distinctive, and 2 are very specific to this project.

0
Common
Most of the 169 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific
could be automatic: a setting could enforce it

Distinctive:
When in doubt, ask the user which is the correct one to use.
line 21
Very specific:
If nothing is staged, check whether unstaged changes should be staged.
line 48
Distinctive:
Prefer staging specific files by name.
line 52
Distinctive:
Read git diff --staged in full.
line 59
Distinctive:
Use the heredoc form to avoid shell escaping issues with apostrophes or special characters.
line 78
Distinctive:
Run git log --oneline -3 and show the user the new commit alongside the two preceding ones so they can verify the message fits the project …
line 82
Distinctive:
Never amend a commit that has already been pushed
line 86
Distinctive:
Never force-push to main or master
line 87
Very specific:
Never skip hooks (--no-verify) — if a hook fails, diagnose and bring a plan to fix it
line 88
Distinctive:
Do not push unless the user explicitly asks
line 89

“Common” is measured: kept by at least 6 in 10 of the 169 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

You are a commit author for this Swift Package project. Your job is to inspect staged (and unstaged) changes, craft a commit message that matches the project's style exactly, and create the commit.

Commit style

<type>: <message>

Message rules:

Message about the commit changed in the repo: "Added", "Changed", "Improved" - Keep concise
72 characters max
No trailing period
type: prefix is optional and used loosely — only add it when the change is clearly one of thses types (fix:, docs:, feature:, refactor:, maint)
When in doubt, ask the user which is the correct one to use.

Never include:

Co-Authored-By trailers
AI attribution of any kind (claude, chatgpt, etc...)
Sign-off lines

Real examples from this project

Fix cancellation misreporting, tvOS location guard, and roadmap state
Added SwiftLint across sources and tests
docs: Overhaul README and promote Apple Intelligence in banner
chore: Remove .gitkeep from AppleIntelligenceProviderTests
feature: Add AppleIntelligenceProvider with native FoundationModels integration

Steps

1 — Assess state

git status
git diff --staged
git diff

If nothing is staged, check whether unstaged changes should be staged. If $ARGUMENTS gives a hint about intent, use it to decide which files to stage. Ask before staging files that look unrelated to the described change.

2 — Stage (if needed)

Prefer staging specific files by name. Never git add . blindly — check git status first and exclude:

.env files or any file containing secrets
Large binaries unrelated to the change
Unintended scratch files

3 — Inspect the diff

Read git diff --staged in full. For each changed file, identify:

What changed (added, removed, modified)
Why it changed (feature, bug fix, cleanup, dependency update, CI, docs)

Cross-reference with $ARGUMENTS if provided.

4 — Draft the message

Apply the style rules above. Choose the shortest accurate subject. Add a body only if the subject leaves important context unstated.

5 — Commit

git commit -m "$(cat <<'EOF'
<message>
EOF
)"

Use the heredoc form to avoid shell escaping issues with apostrophes or special characters.

6 — Confirm

Run git log --oneline -3 and show the user the new commit alongside the two preceding ones so they can verify the message fits the project style.

Safety rules

Never amend a commit that has already been pushed
Never force-push to main or master
Never skip hooks (--no-verify) — if a hook fails, diagnose and bring a plan to fix it
Do not push unless the user explicitly asks

Download now (ZIP)

Other versions189 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 189
microsoft/vscode★ 194ksame name
TryGhost/Ghost★ 56ksame name
ToolJet/ToolJet★ 41ksame name
ShareX/ShareX★ 41ksame name
openai/symphony★ 27ksame name
ccusage/ccusage★ 19ksame name
ryoppippi/ccusage★ 19ksame name
windmill-labs/windmill★ 18ksame name
EverMind-AI/EverOS★ 14ksame name
EverMind-AI/EverMemOS★ 14ksame name
179 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use validate-plan, act-on-feedback and 10 more.
Other files people use alongside this one.
- shawn-dumasSkill
  validate-plan
  Validate an orchestration plan after pre-flight certification. Runs adversarial review, deep review (verify prompt data against codebase), and PoC gate for risky approaches. Auto-invoked by orchestrate-* skills at Step 8.
  Also in 5 projects that use this
- MicrosoftSkill
  act-on-feedback
  Act on user feedback attached to the current session. Use when the user submits feedback on the session's changes via the Submit Feedback button.
  Also in 3 projects that use this
- decocmsSkill
  add-mcp-tools
  Guide for adding new MCP tools with consistent patterns for schemas, tool definitions, registry updates, and Better Auth integration
  Also in 3 projects that use this
- MicrosoftSkill
  generate-run-commands
  Generate or modify run commands for the current session. Use when the user wants to set up or update run commands that appear in the session's Run button.
  Also in 3 projects that use this
- decocmsSkill
  run-local-freestyle
  Run Studio locally with chats and task runs executing in real Freestyle sandboxes, reachable through an ngrok tunnel. Use when asked to "run locally with Freestyle", "test claude-code chats locally", "run the sandbox harness end to end", or to try daemon/harness-runner changes in a real sandbox.
  Also in 3 projects that use this
- mitsuhikoSkill
  oebb-scotty
  Austrian rail travel planner (ÖBB Scotty). Use when planning train journeys in Austria, checking departures/arrivals at stations, or looking for service disruptions. Covers ÖBB trains, S-Bahn, regional trains, and connections to neighboring countries.
  Also in 3 projects that use this
In this repository12 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- add-providerSkill
- add-toolSkill
- lintSkill
- pr-comment-fixerSkill
- swift-architecture-skillSkill
- swift-concurrency-proSkill
- swift-testing-proSkill
- swiftui-proSkill
- testSkill
- update-bannerSkill

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free

10 rules. 0 are common, 8 are distinctive, and 2 are very specific to this project.

Commit style

Real examples from this project

Steps

1 — Assess state

2 — Stage (if needed)

3 — Inspect the diff

4 — Draft the message

5 — Commit

6 — Confirm

Safety rules

Word for word · 0

Edited · 0

Wrote their own version · 189

validate-plan

act-on-feedback

add-mcp-tools

generate-run-commands

run-local-freestyle

oebb-scotty

Does it work?

No reviews yet

Your trail

Now do this for your own.