github-workflow
Skill4 starsChanged 34 days agoCC0-1.0View on GitHub
Git and GitHub conventions for branches, commits, PRs, and releases. Use when changing code in a Git repository, branching, committing, writing commit or PR messages, merging a PR, or tagging a release.
23 other projects use a version of this.
Adopted by
Most recently taken up by
- Gogo-Bytes/blogtheir own version, first seen Nov 8, 2026
- yaqob3653/vlypse-skillstheir own version, first seen Nov 8, 2026
- MMACABRE/SKILLStheir own version, first seen Nov 8, 2026
- AlvaroVFon/skillstheir own version, first seen Nov 1, 2026
- MattoYuzuru/yuzuru-skillstheir own version, first seen Oct 25, 2026
- lcx9451/dsh-engineering-skill-packtheir own version, first seen Oct 25, 2026
Used with
Projects with it also use marketing-psychology, copywriting and 4 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
SentrySkillmarketing-psychology
When the user wants to apply psychological principles, mental models, or behavioral science to marketing. Also use when the user mentions 'psychology,' 'mental models,' 'cognitive bias,' 'persuasion,' 'behavioral science,' 'why people buy,' 'decision-making,' or 'consumer behavior.' This skill provides 70+ mental models organized for marketing application.
Also in 3 projects that use this
SupabaseSkillcopywriting
Write or audit UI copy (buttons, labels, empty states, error messages, tooltips, form text) anywhere in the monorepo. Load it before shipping or reviewing any user-facing text — including when copy is incidental to the task, like a new feature that adds buttons, toasts, dialogs, or validation messages.
Also in 3 projects that use this
Microsoft AzureSkillgit-workflow
Squad branching model: dev-first workflow with insiders preview channel
Also in 3 projects that use this
- SentrySkill
skill-creator
Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.
Also in 4 projects that use this
GoogleSkillcode-review
Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.
Also in 3 projects that use this
BlockSkillfrontend-design
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
Also in 3 projects that use this
Other versions23 projects use a version of this.
Word for word · 1
- berkeley-humanoids/skills★ 4100% same
Edited · 0
None found.
Wrote their own version · 22
- massCodeIO/massCode★ 7.1ksame name
- huynhsontung/Screenbox★ 4.7ksame name
- Mindrally/skills★ 275same name
- amanning3390/hermeshub★ 48same name
- drewid74/ai_skills★ 8same name
- rloisell/rl-agents-n-skills★ 8same name
- zajca/pohunek★ 8same name
- Kur1sulab/blackbox★ 3same name
- lcx9451/dsh-engineering-skill-pack★ 3same name
- AlvaroVFon/skills★ 2same name
12 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.
In this repository8 other files it gives its agents.
- clean-codingSkill
- grounded-researchSkill
- paper-figuresSkill
- pixi-workspaceSkill
- research-code-validationSkill
- robotics-conventionsSkill
- ros2-conventionsSkill
- ste-writingSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
20 rules. 0 are common, 17 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 15 edited versions we read keep these.
17
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
If the repository has its own conventions, follow them.
- Distinctive: line 11
Keep all communication concise.
- Distinctive: line 12
Follow the engineering taste of Linus Torvalds: simplicity, clarity, correctness, and maintainability.
- Very specific: line 15
Keep main protected. Make changes on short-lived branches such as feat/, fix/, refactor/.
- Very specific: line 16
Prefer trunk-based development: merge small changes into main often.
- Distinctive: line 19
Commit in small steps during development, not only at the end.
- Very specific: line 20
Follow Conventional Commits: type(scope): imperative summary.
- Distinctive: line 22
When possible, make sure that each commit builds and passes the tests.
- Distinctive: line 23
Write a concise, precise subject line, ideally 72 characters or fewer.
- Distinctive: line 24
Add a body only when it is necessary to explain the motivation, a non-obvious decision, or a consequence.
- Distinctive: line 26
Do not write wordy narratives, generic summaries, or unnecessary bullet lists.
- Distinctive: line 30
Put one focused change in each PR.
- Distinctive: line 31
Use the Conventional Commits format for the PR title.
- Distinctive: line 32
Keep the PR description concise and minimal.
- Distinctive: line 33
If relevant, state important trade-offs, breaking changes, or limitations.
- Distinctive: line 34
Do not write boilerplate, self-congratulation, implementation diaries, or redundant file-by-file descriptions.
- Distinctive: line 37
Use Rebase and merge to keep atomic commits on main.
- Distinctive: line 38
Delete the branch after the merge.
- Distinctive: line 42
When practical, automate the changelog and GitHub Releases.
- Distinctive: line 43
Create a release branch only to stabilize or maintain a release for larger projects.
“Common” is measured: kept by at least 6 in 10 of the 15 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.
Files
GitHub Workflow
If the repository has its own conventions, follow them. Otherwise, use these defaults.
Principles
- Keep all communication concise. Write only what is necessary. Remove filler, repetition, and obvious explanations.
- Follow the engineering taste of Linus Torvalds: simplicity, clarity, correctness, and maintainability.
Branches
- Keep
mainprotected. Make changes on short-lived branches such asfeat/,fix/,refactor/. - Prefer trunk-based development: merge small changes into
mainoften. Avoid a permanentdevelopbranch.
Commits
- Commit in small steps during development, not only at the end.
- Follow Conventional Commits:
type(scope): imperative summary. - Make each commit one logical, self-contained change.
- When possible, make sure that each commit builds and passes the tests. This rule lets
git bisecttest every commit. - Write a concise, precise subject line, ideally 72 characters or fewer.
- Add a body only when it is necessary to explain the motivation, a non-obvious decision, or a consequence.
- Explain why. Do not repeat what the diff already shows.
- Do not write wordy narratives, generic summaries, or unnecessary bullet lists.
- You can rewrite your own unmerged branch. Push the rewritten branch with
--force-with-lease.
Pull Requests
- Put one focused change in each PR.
- Use the Conventional Commits format for the PR title.
- Keep the PR description concise and minimal. Do not include anything obvious or not applicable.
- If relevant, state important trade-offs, breaking changes, or limitations.
- Do not write boilerplate, self-congratulation, implementation diaries, or redundant file-by-file descriptions.
- Open the PR as a draft early, so that each feature branch has an associated PR.
- Push review fixes as fixup commits (
git commit --fixup). Before the merge, usegit rebase --autosquashto combine each fixup commit with the commit that it fixes. - Use Rebase and merge to keep atomic commits on
main. If the whole PR is one logical change, use Squash and merge. - Delete the branch after the merge.
Releases
- Use Semantic Versioning.
- When practical, automate the changelog and GitHub Releases.
- Create a release branch only to stabilize or maintain a release for larger projects.
- Merge each fix into
mainfirst. If a release branch also needs the fix, cherry-pick it to that branch.
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
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.