New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Shift Commit Rules

by shift-editor in shift-editor/shift

Rules for writing git commits in the Shift font editor repo: Conventional Commits subjects, user-facing changelog wording, concise subjects and logical commit boundaries.

Apache-2.0Auto-check: notesDevelopment

Install Shift Commit Rules

skills CLI
$ npx skills add shift-editor/shift --skill commit -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install shift-editor/shift commit --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/shift-editor/shift.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.codex/skills/commit .claude/skills/commit && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
commit
GitHub stars
343
Token cost
~1.4k tokens
SKILL.md length
674 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
Apache-2.0

At a glance

Rules for writing git commits in the Shift font editor repo: Conventional Commits subjects, user-facing changelog wording, concise subjects and logical commit boundaries.

  • Works in 8 steps: Confirm the user's stated goal. Ask for… → Inspect git status, unstaged and staged… → Identify secrets, generated files,… → …
  • Committing changes in the Shift repository
  • SKILL.md covers Commit syntax, Allowed types, Subject rules and Commit bodies, plus 3 more sections
  • Calls git

What it does

The aim is a git log --oneline that explains the project and gives Release Please clean input. Every subject uses Conventional Commits: a type, an optional scope, an optional exclamation mark and a concise imperative description. Ten types are allowed (feat, fix, perf, refactor, test, docs, build, ci, style and chore), and only feat, fix and perf reach the public changelog, so those subjects are written for users rather than as file-level summaries.

Subjects stay within 72 characters, aiming for 50, with lowercase after the colon, imperative mood and no trailing period, emoji, agent prefix or generated-by attribution. A bang or a BREAKING CHANGE footer is used only when callers, documents or workflows must change. The product version and generated release sections are never bumped by hand in an ordinary feature pull request, because Release Please owns them, and a Release-As footer needs your explicit approval.

When your agent uses it

  • Committing changes in the Shift repository
  • Drafting a commit message that feeds the changelog
  • Splitting work into logical commits before opening a pull request
  • Marking a breaking change correctly

Example prompts

  • “Commit my staged changes in Shift with a proper subject line.”
  • “Split these edits into logical commits and write messages that suit the release notes.”
  • “Write a fix commit for the failed-export bug that preserves workspace edits.”

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. Confirm the user's stated goal. Ask for a one-line explanation only when the purpose is genuinely unclear.
  2. Inspect git status, unstaged and staged diffs, and recent commit subjects.
  3. Identify secrets, generated files, unrelated work, and the logical commit boundaries.
  4. If multiple commits are needed and the user has not already approved the plan, propose the ordered subjects and wait.
  5. Run the focused tests and repository checks appropriate to each change. For desktop user-flow or rendering changes, complete the E2E…
  6. Stage explicit paths or hunks. Never use git add . or git add -A.
  7. Commit without bypassing hooks.
  8. Inspect git status and the resulting commit after each commit.

What it can do on your machine

Read from SKILL.md and the folder at commit e7dacfa. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Shift Commit Rules loads about 1.4k tokens when it runs. Until then it costs about 75 tokens; SKILL.md has 674 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~75
When it runs · the whole SKILL.md, loaded when a task matches
~1.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:98
    mmit credentials, tokens, certificates, `.env` files, or suspicious generated secrets.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from shift-editor/shift at commit e7dacfa, republished under its Apache-2.0 licence (© shift-editor). 674 words, ~1,434 tokens.

Download SKILL.mdSave it as .claude/skills/commit/SKILL.md (or your agent's skills folder).
name
commit
description
Canonical rules for writing git commits in the Shift codebase. Use whenever the user asks to commit, stage and commit, create a pull request that requires commits, or draft a commit message. Enforces Conventional Commits, release-note quality, concise subjects, and logical commit boundaries.

/commit — How Shift commits are written

The goal is a git log --oneline that explains the project and gives Release Please clean input.

Commit syntax

Every subject uses Conventional Commits:

text
<type>[optional scope][optional !]: <concise imperative description>

Examples:

text
feat: add isolated Nightly builds
fix(workspace): preserve edits after failed export
refactor(renderer): share retained glyph ownership
feat(document)!: reject legacy workspace schemas

Use ! or a BREAKING CHANGE: footer only when callers, documents, or user workflows must change. Alpha permits breaking changes, but the commit must still explain them.

Allowed types

TypeUse forPublic changelog
featNew user-visible functionalityYes
fixUser-visible bug fixYes
perfMeasurable performance improvementYes
refactorCode change with no intended behavior changeNo
testTests without production behavior changesNo
docsDocumentation onlyNo
buildPackaging, build scripts, native compilationNo
ciCI and release workflowsNo
styleFormatting only, not UI appearanceNo
choreDependencies, tooling, and repository housekeepingNo

Release Please uses merged conventional commits to update CHANGELOG.md, versions, tags, and GitHub release notes. Write feat, fix, and perf subjects for users rather than as file-level implementation summaries.

Do not manually bump the product version or edit generated release sections in an ordinary feature pull request. Release Please owns those changes in its release pull request. Use a Release-As: X.Y.Z footer only after the user explicitly approves a milestone transition.

Subject rules

  • Maximum 72 characters including type and scope; aim for 50.
  • Lowercase after the colon.
  • Imperative mood: add, preserve, reject; not added or adds.
  • No trailing period, emoji, agent prefix, or generated-by attribution.
  • Avoid file paths and symbol names unless they are essential to understanding the change.
  • Never prefix a subject with [codex] or another agent label.

Commit bodies

Most commits do not need a body. Add one when the constraint, consequence, migration, or reason is not clear from the subject.

  • Leave one blank line after the subject.
  • Wrap prose near 72 characters.
  • Explain why and non-obvious consequences; do not narrate the diff.
  • Put BREAKING CHANGE: and Release-As: footers after the body when approved and required.

Logical boundaries

Every commit is one reviewable change. Keep production code with the tests and focused documentation that prove or explain it.

Split when changes have independent reasons to exist, especially:

  • unrelated subsystems or behaviors;
  • file moves mixed with later logic changes;
  • generated output independent of hand-written changes;
  • broad formatting mixed with behavior;
  • repository tooling unrelated to the product change.

When the correct split is unclear, propose the subjects and path groups before staging. Do not create artificial test-only commits when the tests belong to the behavior they cover.

Show full SKILL.md (271 more words)Show less

Process

  1. Confirm the user's stated goal. Ask for a one-line explanation only when the purpose is genuinely unclear.
  2. Inspect git status, unstaged and staged diffs, and recent commit subjects.
  3. Identify secrets, generated files, unrelated work, and the logical commit boundaries.
  4. If multiple commits are needed and the user has not already approved the plan, propose the ordered subjects and wait.
  5. Run the focused tests and repository checks appropriate to each change. For desktop user-flow or rendering changes, complete the E2E impact check in apps/desktop/e2e/README.md: search existing specs by affected surface, run the smallest relevant Playwright project/file/title filter, inspect intentional snapshot updates, and state any relevant E2E coverage not run.
  6. Stage explicit paths or hunks. Never use git add . or git add -A.
  7. Commit without bypassing hooks.
  8. Inspect git status and the resulting commit after each commit.

A request to create a pull request authorizes the commits needed for the clearly stated PR goal. It does not authorize including unrelated dirty work.

Hard rules

  • Never commit unless the user asked for a commit or for a pull request that requires it.
  • Never bypass hooks with --no-verify or disable signing unless the user explicitly requests it.
  • If a commit hook fails, fix the cause and rerun the commit. If a committed change later needs correction, add a new commit rather than amending unless the user asks to rewrite local history.
  • Never commit credentials, tokens, certificates, .env files, or suspicious generated secrets.
  • Never push unless the user asks to push or create/update a pull request.
  • Never add agent attribution or co-author trailers unless the user asks.

© shift-editor, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .codex/skills/commit of shift-editor/shift.

Open the folder on GitHubat commit e7dacfa

Compare with similar skills

Shift Commit Rules next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Shift Commit Rules compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Shift Commit Rules this skillshift-editor/shift343—~1.4kAutomated safety check: NotesApache-2.0
Git Workflow and Versioningaddyosmani/agent-skills102k2 repos~3.5kAutomated safety check: NotesMIT
React Router Pull Request Creatorremix-run/react-router57k—~2.5kAutomated safety check: PassMIT
Verdaccio Pull Request Workflowverdaccio/verdaccio18k—~1.9kAutomated safety check: PassMIT
pybind11 Release Preparationpybind/pybind1118k—~1.7kAutomated safety check: PassCustom licence
AionUi Version BumpiOfficeAI/AionUi33k—~2.1kAutomated safety check: PassApache-2.0

Similar skills

  • Git Workflow and Versioning

    addyosmani/agent-skills

    Sets git habits for every change: short-lived branches, atomic commits with descriptive messages, clean pull requests, plus versioning, tagging and changelogs for releases.

    102k GitHub starsUsed in 2 repos~3.5k tokens
    DevelopmentAuto-check: notes

  • React Router Pull Request Creator

    remix-run/react-router

    Packages finished React Router work into a draft pull request: branch, commit, push, a written PR body and the right GitHub labels.

    57k GitHub stars~2.5k tokensUpdated today
    DevelopmentAuto-check passed

  • Verdaccio Pull Request Workflow

    verdaccio/verdaccio

    Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines.

    18k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed

  • pybind11 Release Preparation

    pybind/pybind11

    Opens the pybind11 release-preparation pull request: picking the release base, bumping the version in common.h and integrating the changelog, following docs/release.rst.

    18k GitHub stars~1.7k tokensUpdated today
    DevelopmentAuto-check passed

  • AionUi Version Bump

    iOfficeAI/AionUi

    Automates an AionUi release: checks the latest AionCore release and its artifacts, updates package.json, writes the changelog, opens a PR and tags the release.

    33k GitHub stars~2.1k tokensUpdated 28 days ago
    DevelopmentAuto-check passed

  • Emoji Commit Conventions

    baptisteArno/typebot.io

    Sets the repository's convention for commit messages and pull request titles: one emoji prefix for the main intent, a concise title and clean follow-up commits.

    11k GitHub stars~424 tokensUpdated yesterday
    DevelopmentAuto-check passed

More from shift-editor/shift

All 14 skills in this repo

  • Dead Code Removal with Knip

    shift-editor/shift

    Finds unused files, exports and class members with Knip, then verifies each candidate through reference tracing before removing anything, never using knip --fix.

    343 GitHub stars~1.8k tokensUpdated today
    Auto-check passed

  • Shift Subsystem Docs

    shift-editor/shift

    Updates or creates DOCS.md files for Shift subsystems, recording the architecture invariants and constraints that cannot be learned from reading the source.

    343 GitHub stars~1.9k tokensUpdated today
    Auto-check passed

  • Adversarial Docs Audit

    shift-editor/shift

    Fact-checks DOCS.md files against the source code, testing each concrete claim and sorting it as true, false, stale or unverifiable.

    343 GitHub stars~818 tokensUpdated today
    Auto-check passed

  • Shift Issue Writer

    shift-editor/shift

    Sets the rules for finding, writing and updating Shift GitHub issues: search for duplicates first, use outcome-focused titles and testable acceptance criteria.

    343 GitHub stars~1.4k tokensUpdated today
    Auto-check passed

  • Shift JSDoc Contracts

    shift-editor/shift

    Guides writing JSDoc for Shift exported APIs as a stable caller contract, covering ownership, lifetime, side effects and nullability that TypeScript types cannot express.

    343 GitHub stars~3.7k tokensUpdated today
    Auto-check passed

  • Shift Pull Request Rules

    shift-editor/shift

    Rules for preparing, opening and updating pull requests in the Shift repository: Conventional Commit titles, Release Please effects, evidence-based bodies and UI screenshots.

    343 GitHub stars~2.1k tokensUpdated today
    Auto-check: notes

Works with

Categories

Questions about Shift Commit Rules

What does Shift Commit Rules do?

Rules for writing git commits in the Shift font editor repo: Conventional Commits subjects, user-facing changelog wording, concise subjects and logical commit boundaries. The aim is a git log --oneline that explains the project and gives Release Please clean input. Every subject uses Conventional Commits: a type, an optional scope, an optional exclamation mark and a concise imperative description.

When should I use Shift Commit Rules?

Shift Commit Rules fits situations like: committing changes in the Shift repository; drafting a commit message that feeds the changelog; splitting work into logical commits before opening a pull request; marking a breaking change correctly.

How do I install Shift Commit Rules in Claude Code?

Run `npx skills add shift-editor/shift --skill commit -a claude-code`. Or copy the skill folder (.codex/skills/commit in shift-editor/shift) into .claude/skills/commit in your project. Claude Code loads it when a task matches its description.

How do I install Shift Commit Rules in Codex?

Run `npx skills add shift-editor/shift --skill commit -a codex`. Or copy the skill folder (.codex/skills/commit in shift-editor/shift) into .agents/skills/commit in your project. Codex loads it when a task matches its description.

Can I use Shift Commit Rules in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add shift-editor/shift --skill commit -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/commit, .gemini/skills/commit, .github/skills/commit and .opencode/skills/commit in your project.

What does Shift Commit Rules need to run?

Going by SKILL.md and its folder, Shift Commit Rules needs the command-line tools its instructions call (git).

Does Shift Commit Rules access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Shift Commit Rules safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Shift Commit Rules use?

Shift Commit Rules is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Shift Commit Rules use?

About 1.4k tokens (SKILL.md is roughly 5.7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Shift Commit Rules?

Skills that share tags, products or a category with Shift Commit Rules: Git Workflow and Versioning (addyosmani/agent-skills, 102k stars), React Router Pull Request Creator (remix-run/react-router, 57k stars), Verdaccio Pull Request Workflow (verdaccio/verdaccio, 18k stars) and pybind11 Release Preparation (pybind/pybind11, 18k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Shift Commit Rules?

shift-editor (a GitHub organization) maintains it in shift-editor/shift, which has 343 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 6, 2026.

Source: shift-editor/shift on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.