Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

git-workflow

Étoiles1

Forks2

Mis à jour9 avril 2026 à 06:26

'Git commit, branching, and documentation conventions. Use when: writing commit messages, creating branches, preparing pull requests, reviewing changelogs, squashing commits, establishing git workflow standards, auditing commit history for convention compliance, or improving an existing project git workflow.'

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

michaelsvanbeek

michaelsvanbeek/personal-agent-skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	git-workflow
description	'Git commit, branching, and documentation conventions. Use when: writing commit messages, creating branches, preparing pull requests, reviewing changelogs, squashing commits, establishing git workflow standards, auditing commit history for convention compliance, or improving an existing project git workflow.'

Git Workflow Standards

When to Use

Writing or reviewing commit messages
Creating branches for features, fixes, or releases
Preparing pull request descriptions
Squashing or cleaning up commit history
Establishing git conventions for a project
Auditing an existing project's commit history and branch strategy for convention compliance
Retrofitting conventional commits, PR templates, or changelog practices to an existing repo

Commit Messages

Follow the Conventional Commits specification. This enables automated changelog generation, semantic versioning, and clear history.

Format

<type>(<scope>): <subject>

<body>

<footer>

Rules

Subject line: Imperative mood, lowercase, no period, max 72 characters.
Body: Wrap at 80 characters. Explain what and why, not how. Separate from subject with a blank line.
Footer: Reference issues, breaking changes, or co-authors.

Types

Type	When to use
`feat`	New feature or capability
`fix`	Bug fix
`docs`	Documentation only
`style`	Formatting, whitespace, semicolons (no logic change)
`refactor`	Code restructuring without behavior change
`perf`	Performance improvement
`test`	Adding or updating tests
`build`	Build system, dependencies, CI config
`chore`	Maintenance tasks, tooling, config
`ci`	CI pipeline changes
`revert`	Reverting a previous commit

Scope

Optional, but encouraged. Use the module, component, or area affected:

feat(api): add user search endpoint
fix(auth): handle expired refresh tokens
build(deps): update fastapi to 0.115
docs(readme): add deployment instructions

Examples

Single-line (small, self-explanatory changes):

fix(cors): allow credentials in preflight responses

With body (changes that need context):

feat(cache): add IndexedDB caching for dashboard data

Store API responses in IndexedDB keyed by endpoint and query params.
Serve cached data immediately on page load, then refresh in the
background. Reduces perceived load time for repeat visits.

With breaking change:

feat(api)!: change auth from API key to OAuth2

Migrate all endpoints to require Bearer token authentication.
API key header is no longer accepted.

BREAKING CHANGE: Clients must update to use OAuth2 tokens.
All existing API keys are invalidated.

Closes #142

Anti-patterns

update stuff - Vague, no type, no scope, no useful information
fix bug - Which bug? What was the symptom?
WIP - Never commit with WIP; use git stash or draft branches
address review comments - Describe what actually changed
Giant commits touching unrelated files - Split into focused commits

Commit Granularity

Each commit should represent one logical change.
If you can describe the commit with "and" (e.g., "fix login and update styles"), split it into two commits.
Test suite should pass on every commit (enables git bisect).
Prefer many small commits during development, squash into logical units before merging.

Branch Naming

<type>/<short-description>

Pattern	Example
`feat/user-search`	Feature work
`fix/token-expiry`	Bug fix
`docs/api-reference`	Documentation
`refactor/auth-module`	Refactoring
`release/v1.2.0`	Release branch
`hotfix/null-pointer`	Production hotfix

Rules:

Lowercase, kebab-case.
Short but descriptive (3-5 words max).
Include ticket number if applicable: feat/PROJ-123-user-search.

Pull Requests

Title

Follow the same conventional commit format as the squash/merge commit:

feat(api): add user search endpoint

Description Template

## What

Brief description of what this PR does.

## Why

Context on why this change is needed. Link to issue or ticket.

## How

High-level description of the approach taken.

## Testing

How this was tested. Include commands to verify, test output, or screenshots.

## Checklist

- [ ] Linter passes with no errors (`ruff check .` / `eslint .`)
- [ ] Formatter applied (`ruff format .` / `prettier --write .`)
- [ ] Type checker passes (`mypy .` for Python, `tsc --noEmit` for TypeScript)
- [ ] Tests pass
- [ ] Documentation updated
- [ ] No secrets or credentials committed

Changelog

When maintaining a CHANGELOG.md, follow the Keep a Changelog format. See the release-management skill for changelog automation from conventional commits and release cadence guidance.

# Changelog

## [Unreleased]

### Added
- User search endpoint with fuzzy matching (#142)

### Fixed
- Token refresh handling for expired sessions (#138)

### Changed
- Auth migrated from API key to OAuth2 (#140)

## [1.1.0] - 2026-03-15

### Added
- Dashboard caching with IndexedDB

Categories: Added, Changed, Deprecated, Removed, Fixed, Security.

Pre-Commit Checklist

Run these before every commit:

Python projects:

ruff format .        # format
ruff check --fix .   # lint with auto-fix
mypy .               # type check
pytest               # tests

Web projects:

prettier --write .   # format
eslint . --fix       # lint with auto-fix
tsc --noEmit         # type check
npm test             # tests

Consider automating this with a pre-commit hook or lint-staged.

Git Hygiene

Write meaningful messages on every commit, even during early development.
Use .gitignore before the first commit to avoid committing generated files.
Never commit secrets, credentials, or environment files.
Never commit code that fails linting or type checking.
Use git stash for work-in-progress rather than WIP commits.
Rebase/squash feature branches before merging to keep main history clean.
Tag releases using semantic versioning: v1.2.0 (see release-management skill for full SemVer conventions).

Release Tagging

Use annotated tags for all releases. Annotated tags store author, date, and message — essential for audit and tooling:

git tag -a v1.5.0 -m "Release v1.5.0"
git push origin main --follow-tags

Tag Rules

Prefix with v: v1.5.0, not 1.5.0.
Tags are immutable — never delete and re-create. Fix with a new PATCH release.
Tag only commits where all CI checks pass.
Use the conventional commit type chore(release) for the version-bump commit:

chore(release): v1.5.0

For full semantic versioning rules (when to bump MAJOR vs MINOR vs PATCH), release workflows, hotfix procedures, and changelog automation, see the release-management skill.

Plus depuis ce dépôt

même dépôt

mcp-server

michaelsvanbeek/personal-agent-skills

MCP server design, development, and audit using the Python SDK (FastMCP). Use when: creating a new MCP server, wrapping an API as MCP tools, auditing an existing MCP server for patterns and gaps, adding auth/secrets/retry/observability to an MCP server, choosing between tools vs resources vs prompts, designing MCP resources or resource templates, creating MCP prompts for workflow bootstrapping, choosing between low-level Server and FastMCP, designing tool contracts, configuring pydantic-settings, adding structured logging, writing MCP server tests, or improving an existing MCP server codebase.

2026-04-121

comms

michaelsvanbeek/personal-agent-skills

Writing for specific audiences: leadership, peers, team, and org-wide. Use when: preparing an executive briefing, writing a team newsletter, communicating up/down/ laterally, announcing a launch or change, escalating an issue, delivering difficult messages, pushing back on a request, or building team visibility across the org.

2026-04-111

goals

michaelsvanbeek/personal-agent-skills

OKRs and contribution goals — writing, cascading, scoring, and individual goal setting. Use when: setting team OKRs, writing individual contribution goals, cascading company OKRs to team level, coaching someone on goal quality, preparing for OKR reviews, scoring OKRs at end of cycle, or linking contribution goals to team OKRs. Covers both team-level OKRs and individual contribution goal frameworks.

2026-04-111

presentations

michaelsvanbeek/personal-agent-skills

Presentation design, outlining, visual best practices, and brand compliance. Use when: building a presentation outline, choosing visuals for a slide deck, structuring a talk for a specific audience, iterating on presentation content in markdown before graduating to slides, reviewing an existing deck for flow and clarity, selecting the right chart or diagram type for a given message, or ensuring slides comply with an organization's brand guide.

2026-04-111

stakeholder-comms

michaelsvanbeek/personal-agent-skills

Communicating effectively up, down, and laterally within an org chart. Use when: preparing an executive briefing, presenting to leadership, managing stakeholder expectations, negotiating priorities with product or peer teams, escalating issues, delivering difficult messages, or building influence without authority.

2026-04-111

ticket-writing

michaelsvanbeek/personal-agent-skills

Writing clear, actionable tickets in any issue tracker (Jira, Linear, GitHub Issues, ServiceNow, etc.). Use when: creating epics, stories, tasks, bugs, or spikes; writing acceptance criteria; decomposing work for a sprint; linking dependencies between tickets; auditing backlog items for clarity; or coaching a team on ticket quality. Covers title conventions, description templates, acceptance criteria, decomposition rules, dependency linking, and org-specific pluggable configuration.

2026-04-111

name	git-workflow
description	'Git commit, branching, and documentation conventions. Use when: writing commit messages, creating branches, preparing pull requests, reviewing changelogs, squashing commits, establishing git workflow standards, auditing commit history for convention compliance, or improving an existing project git workflow.'

Git Workflow Standards

When to Use

Writing or reviewing commit messages
Creating branches for features, fixes, or releases
Preparing pull request descriptions
Squashing or cleaning up commit history
Establishing git conventions for a project
Auditing an existing project's commit history and branch strategy for convention compliance
Retrofitting conventional commits, PR templates, or changelog practices to an existing repo

Commit Messages

Follow the Conventional Commits specification. This enables automated changelog generation, semantic versioning, and clear history.

Format

<type>(<scope>): <subject>

<body>

<footer>

Rules

Subject line: Imperative mood, lowercase, no period, max 72 characters.
Body: Wrap at 80 characters. Explain what and why, not how. Separate from subject with a blank line.
Footer: Reference issues, breaking changes, or co-authors.

Types

Type	When to use
`feat`	New feature or capability
`fix`	Bug fix
`docs`	Documentation only
`style`	Formatting, whitespace, semicolons (no logic change)
`refactor`	Code restructuring without behavior change
`perf`	Performance improvement
`test`	Adding or updating tests
`build`	Build system, dependencies, CI config
`chore`	Maintenance tasks, tooling, config
`ci`	CI pipeline changes
`revert`	Reverting a previous commit

Scope

Optional, but encouraged. Use the module, component, or area affected:

feat(api): add user search endpoint
fix(auth): handle expired refresh tokens
build(deps): update fastapi to 0.115
docs(readme): add deployment instructions

Examples

Single-line (small, self-explanatory changes):

fix(cors): allow credentials in preflight responses

With body (changes that need context):

feat(cache): add IndexedDB caching for dashboard data

Store API responses in IndexedDB keyed by endpoint and query params.
Serve cached data immediately on page load, then refresh in the
background. Reduces perceived load time for repeat visits.

With breaking change:

feat(api)!: change auth from API key to OAuth2

Migrate all endpoints to require Bearer token authentication.
API key header is no longer accepted.

BREAKING CHANGE: Clients must update to use OAuth2 tokens.
All existing API keys are invalidated.

Closes #142

Anti-patterns

update stuff - Vague, no type, no scope, no useful information
fix bug - Which bug? What was the symptom?
WIP - Never commit with WIP; use git stash or draft branches
address review comments - Describe what actually changed
Giant commits touching unrelated files - Split into focused commits

Commit Granularity

Each commit should represent one logical change.
If you can describe the commit with "and" (e.g., "fix login and update styles"), split it into two commits.
Test suite should pass on every commit (enables git bisect).
Prefer many small commits during development, squash into logical units before merging.

Branch Naming

<type>/<short-description>

Pattern	Example
`feat/user-search`	Feature work
`fix/token-expiry`	Bug fix
`docs/api-reference`	Documentation
`refactor/auth-module`	Refactoring
`release/v1.2.0`	Release branch
`hotfix/null-pointer`	Production hotfix

Rules:

Lowercase, kebab-case.
Short but descriptive (3-5 words max).
Include ticket number if applicable: feat/PROJ-123-user-search.

Pull Requests

Title

Follow the same conventional commit format as the squash/merge commit:

feat(api): add user search endpoint

Description Template

## What

Brief description of what this PR does.

## Why

Context on why this change is needed. Link to issue or ticket.

## How

High-level description of the approach taken.

## Testing

How this was tested. Include commands to verify, test output, or screenshots.

## Checklist

- [ ] Linter passes with no errors (`ruff check .` / `eslint .`)
- [ ] Formatter applied (`ruff format .` / `prettier --write .`)
- [ ] Type checker passes (`mypy .` for Python, `tsc --noEmit` for TypeScript)
- [ ] Tests pass
- [ ] Documentation updated
- [ ] No secrets or credentials committed

Changelog

When maintaining a CHANGELOG.md, follow the Keep a Changelog format. See the release-management skill for changelog automation from conventional commits and release cadence guidance.

# Changelog

## [Unreleased]

### Added
- User search endpoint with fuzzy matching (#142)

### Fixed
- Token refresh handling for expired sessions (#138)

### Changed
- Auth migrated from API key to OAuth2 (#140)

## [1.1.0] - 2026-03-15

### Added
- Dashboard caching with IndexedDB

Categories: Added, Changed, Deprecated, Removed, Fixed, Security.

Pre-Commit Checklist

Run these before every commit:

Python projects:

ruff format .        # format
ruff check --fix .   # lint with auto-fix
mypy .               # type check
pytest               # tests

Web projects:

prettier --write .   # format
eslint . --fix       # lint with auto-fix
tsc --noEmit         # type check
npm test             # tests

Consider automating this with a pre-commit hook or lint-staged.

Git Hygiene

Write meaningful messages on every commit, even during early development.
Use .gitignore before the first commit to avoid committing generated files.
Never commit secrets, credentials, or environment files.
Never commit code that fails linting or type checking.
Use git stash for work-in-progress rather than WIP commits.
Rebase/squash feature branches before merging to keep main history clean.
Tag releases using semantic versioning: v1.2.0 (see release-management skill for full SemVer conventions).

Release Tagging

Use annotated tags for all releases. Annotated tags store author, date, and message — essential for audit and tooling:

git tag -a v1.5.0 -m "Release v1.5.0"
git push origin main --follow-tags

Tag Rules

Prefix with v: v1.5.0, not 1.5.0.
Tags are immutable — never delete and re-create. Fix with a new PATCH release.
Tag only commits where all CI checks pass.
Use the conventional commit type chore(release) for the version-bump commit:

chore(release): v1.5.0

For full semantic versioning rules (when to bump MAJOR vs MINOR vs PATCH), release workflows, hotfix procedures, and changelog automation, see the release-management skill.