Skill

git

Enforces custom git conventions: prefix-free branch names, backticked code identifiers (esp. Go pkgs) in commits, GitHub issue queries/refs, minimal PR descriptions without CI snapshots.

Git

Github

git-workflow

npx claudepluginhub maragudk/fabrik --plugin fabrik

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Most of git usage is what you already know, so depend on that. This skill is just a refinement.

SKILL.md

Similar Skills

cache-components

139.4k

Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.

cache-components

pdf

131.6k

Processes PDFs: extracts text/tables/images, merges/splits/rotates pages, adds watermarks, creates/fills forms, encrypts/decrypts, OCRs scans. Activates on PDF mentions or output requests.

11 files

document-skills

Stats

Stars7

Forks0

Last CommitApr 30, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

git

Most of git usage is what you already know, so depend on that. This skill is just a refinement.

Branch naming

Just name the branch a short sentence separated with dashes. Example: add-some-feature. Don't use feat/, hotfix/ etc. prefixes.

Commit messages

Always enclose code identifiers with backticks. Example: "Add html.UserPage component"

Always refer to Go code identifiers including the package name, like in html.UserPage above. Fields and methods on structs can be referred with model.User.Name.

Ask me about any Github issues that should be referenced, and wait for my response before committing. Reference them at the end of the commit message like this: "See #123, #234". If the commit fixes one or more issues, use "Fixes #123, fixes #234" instead (the double "fixes" is important for Github to actually close the issue).

Don't mention that you've updated tests, that's assumed.

Pull request descriptions

Don't include sections that mirror what CI reports. Test Plan, Quality Gates, "ran build/lint/tests, all green" status -- skip them all. CI is the source of truth; freezing a snapshot into the PR body is noise.

Skip the "## Summary" header too -- just write the bullet points directly.

git

Most of git usage is what you already know, so depend on that. This skill is just a refinement.

Branch naming

Just name the branch a short sentence separated with dashes. Example: add-some-feature. Don't use feat/, hotfix/ etc. prefixes.

Commit messages

Always enclose code identifiers with backticks. Example: "Add html.UserPage component"
Always refer to Go code identifiers including the package name, like in html.UserPage above. Fields and methods on structs can be referred with model.User.Name.
Ask me about any Github issues that should be referenced, and wait for my response before committing. Reference them at the end of the commit message like this: "See #123, #234". If the commit fixes one or more issues, use "Fixes #123, fixes #234" instead (the double "fixes" is important for Github to actually close the issue).
Don't mention that you've updated tests, that's assumed.

Pull request descriptions

Don't include sections that mirror what CI reports. Test Plan, Quality Gates, "ran build/lint/tests, all green" status -- skip them all. CI is the source of truth; freezing a snapshot into the PR body is noise.
Skip the "## Summary" header too -- just write the bullet points directly.