git-workflow
Branch names, commit messages, pushing and opening a pull request, and working with the task tracker. Use when branching, committing, pushing or opening a PR.
72
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Git Workflow
Never push to main. Every change goes through a branch and a pull request, and a person merges it.
| Branch | From main: <type>/<slug>, or <type>/<issue-id>-<slug> when there is an issue. Types: feat, fix, refactor, perf, docs, chore |
| Commits | Small and atomic, with an imperative subject — the issue ID first when there is one (TAS-42: Fix token refresh) |
| History | Never --force or --amend on a shared branch; --force-with-lease on your own only |
| Secrets | None in commits, pull request bodies or output; a leaked one is rotated at once |
Deliver
-
Commit, then push:
git push -u origin <branch>. -
Open the pull request with its body in a file — an inline
--bodybreaks on backticks and quotes in zsh:cat > /tmp/pr-body.md << 'EOF' Resolves TAS-42 ## Changes - ... EOF GH_PAGER=cat gh pr create --base main --title "TAS-42: Short description" --body-file /tmp/pr-body.md -
Do not merge it. Link it from the tracker issue when there is one.
The tracker
When the project uses one, its conventions are in .opencastle/project/<tracker>-config.md and the skill bound to the task-management slot. Without its tools in this session, list the issues you would have created — title and acceptance criteria — in your answer, and carry on.
- Repository
monkilabs/opencastle
- Revision
3942f46
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.