LeanMeanCleanAppsLeanMeanCleanApps/CleanModelContextProtocol/.agents/skills/branches-and-pull-requests/SKILL.mdbranches-and-pull-requests
Skill1 starsChanged 6 days agoMITView on GitHub
Branch naming (feature/, fix/, chore/), how labels and release notes follow from the branch, the pull request template, and how changes get merged in the template repository. Use when creating a branch, writing a commit or opening a pull request.
In this repository40 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-a-use-caseSkill
- api-conventionsSkill
- cancellationSkill
- ci-for-your-solutionSkill
- ci-pipelineSkill
- clean-architecture-layersSkill
- configuration-and-environmentsSkill
- coverageSkill
- csharp-house-styleSkill
- data-access-ef-coreSkill
- database-migrationsSkill
- docker-and-composeSkill
- docs-and-voiceSkill
- errors-and-exceptionsSkill
- expose-a-use-caseSkill
- family-syncSkill
- health-checksSkill
- integration-testsSkill
- json-serializationSkill
- mapping-with-mapperlySkill
- mcp-inspectorSkill
- mediatorSkill
- optional-token-authSkill
- packages-and-dependenciesSkill
- pagingSkill
- presentation-integration-testsSkill
- releasesSkill
- sample-dataSkill
- security-findingsSkill
- serilogSkill
- telemetrySkill
- template-authoringSkill
- test-designSkill
- time-providerSkill
- unit-testsSkill
- validationSkill
- writing-a-skillSkill
- xml-docs-and-openapiSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
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: line 31
Write commit messages as a sentence about the change, in the imperative: "Validate the star rating on update".
- Very specific: line 33
If shared layers, skills or repository setup changed, say so.
- Very specific: line 34
Wait for every required check (ci-pipeline).
- Distinctive: line 41
Add AI attribution lines or tool footers to pull request descriptions.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Branches and pull requests
The rule
Every change goes through a pull request against main. A branch ruleset rejects any branch name except main, feature/..., fix/..., chore/... and dependabot/.... The prefix sets the release notes label automatically (.github/labeler.yml), and .github/release.yml groups the generated notes by label. The maintainer reviews and squash-merges; nobody merges their own pull request.
One pull request per completed feature, which tracks to one issue: the issue is cut at the size of the pull request worth reviewing. A decision made partway through a feature goes on that feature's branch, not a new pull request. A small, unrelated fix gets its own fix/ branch.
| Prefix | For | Label | Release notes section |
feature/ | Something new for users of the template | enhancement | New features |
fix/ | Something that was wrong | bug | Bug fixes |
chore/ | Tidying, dependencies, docs, pipeline | none from the name | Other changes |
Changed files add labels too: .github/**, Dockerfile or docker-compose.yml add build; a change made only of Markdown or docs/ adds documentation. Add breaking-change by hand when generated solutions or template options change in a way users will notice.
Where we track work
AGENTS.md ships with "Where we track work" not set, because it's for the teams who use the template. In the template repository itself, plans and handoffs live in issues in LeanMeanCleanApps/.github, on the Lean Mean Clean templates project. The planning skill in that repository has the details. Don't fill in the line in AGENTS.md here.
Steps
- Branch from an up-to-date
main:git switch -c fix/review-validation. Short, lowercase, hyphenated. - Write commit messages as a sentence about the change, in the imperative: "Validate the star rating on update".
- Open the pull request and fill in
.github/pull_request_template.md: a two or three sentence summary, the linked issue (Part oforCloses LeanMeanCleanApps/.github#<number>), the type of change, and whether the shared layers are touched. - If shared layers, skills or repository setup changed, say so; the same change has to go to all five templates (
family-sync). - Wait for every required check (
ci-pipeline). Fix failures with new commits; don't force-push over review comments.
Don't
- Push to
main, or use any other branch prefix. - Merge your own pull request.
- Bundle unrelated changes; they're easier to review apart.
- Add AI attribution lines or tool footers to pull request descriptions.
Check
The labels appear on the pull request a few seconds after it opens, and every required check is green.
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.