Git conventions

Skill mathiasbourgoin/roster/.agents/skills/git-conventions

Apply git workflow conventions — commits, branches, PRs.From its SKILL.md

Install

npx -y skills add mathiasbourgoin/roster --skill git-conventions

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.0 KB, as published. Nobody here has run it

Git Conventions

Apply standardized git conventions for the action described in $ARGUMENTS (e.g., "commit this", "create PR", "new branch for auth feature").

Steps

Identify the action requested in $ARGUMENTS (commit, branch, PR, or full workflow).
Apply the relevant convention sections below.
Execute the git command(s) following the format.

Commit Format

<type>: <description>

Types: feat, fix, refactor, docs, test, chore, perf, ci

Description: imperative mood, lowercase, no period, under 72 chars.
Body (optional): blank line after subject, wrap at 80 chars, explain why not what.
Footer (optional): Closes #123, BREAKING CHANGE: <description>.

Examples:

feat: add JWT authentication middleware
fix: prevent null pointer in user lookup
refactor: extract validation into shared module

Branch Naming

<type>/<short-description>

Kebab-case description, max 4 words.
Examples: feat/add-auth, fix/null-pointer, refactor/extract-validation
For issue-linked work: feat/123-add-auth

PR Workflow

When creating a PR:

Ensure the branch is pushed with git push -u origin <branch>.
Use gh pr create with this template:

## Summary
- <1-3 bullet points describing what and why>

## Test plan
- [ ] <specific verification step>
- [ ] <edge case checked>
- [ ] <regression check>

Title: same format as commit subject (<type>: <description>), under 70 chars.
Request reviewers if the user specifies them.

Commit Workflow

When committing:

Run git status and git diff --staged to understand what's staged.
If nothing staged, help the user stage relevant files (prefer explicit paths over git add .).
Draft commit message following the format above.

Use a HEREDOC for the message:

git commit -m "$(cat <<'EOF'
<type>: <description>
EOF
)"

Run git status after to confirm success.

Rules

Never force-push to main or master.
Always push with -u to set upstream tracking.
Never use git add . or git add -A — stage specific files.
Never skip pre-commit hooks (--no-verify).
Never commit .env, credentials, or secrets — warn the user if these are staged.
PR descriptions must be comprehensive — reviewers should understand the change without reading code.
One logical change per commit. Split unrelated changes into separate commits.

Friction Log

At the end of each run, append to skills-meta/friction.jsonl :

{
  "date": "<ISO-8601>",
  "skill": "git-conventions",
  "task": "<task-slug or short description>",
  "frictions": [],
  "methods": [],
  "suggestion_type": null,
  "suggestion": null,
  "effort_estimate": null
}