git-commit

Engineering Community

Repo stars 0
Author repo Garden

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Write professional git commits using conventional format for clear communication and automated workflows. Write meaningful git c…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Commit Format”, “Commit Types”, “Subject Line Rules”, “Body Guidelines”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name git-commit directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Commit Format / Commit Types / Subject Line Rules” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write / env-read; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

License: MIT

Git Commit Skill

Write meaningful git commits using conventional commit format to improve collaboration, enable automation, and maintain clean project history.

Commit Format

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

<body>

<footer>

Commit Types

feat: New feature for users
fix: Bug fix for users
docs: Documentation changes
style: Code style (formatting, etc)
refactor: Code restructuring
test: Test additions/modifications
chore: Maintenance tasks
perf: Performance improvements
build: Build system changes
ci: CI configuration changes
revert: Revert previous commit

Subject Line Rules

Use imperative mood: "Add feature" not "Added feature"
First letter capitalized, no period at end
Max 50 characters
Describe what the commit does

Body Guidelines

Explain why the change was made
Use bullet points for multiple changes
Reference related issues: Closes #123, Fixes #456
Max 72 characters per line

Breaking changes: BREAKING CHANGE: description
Issue references: Closes #123, Fixes #456
Co-authors: Co-authored-by: name <email>

Examples

Feature with issue reference:

feat(auth): add OAuth2 support

Implement Google and GitHub authentication with JWT tokens.
Add social login buttons to UI.

Closes #123

Bug fix with explanation:

fix(api): resolve null pointer in user endpoint

Add null check for user object before accessing properties.
Root cause: Missing validation in user lookup function.

Fixes #456

Documentation update:

docs(readme): update installation instructions

Add Docker installation option.
Document required environment variables.

Workflow

Stage selectively: git add -p
Review changes: git diff --cached
Write message: Follow conventional format
Commit: git commit -m "type(scope): subject" -m "body"
Verify: git log --oneline -1

Automation Tools

Commitizen

Interactive commit message writing:

git add . && git cz

commitlint

Validate commit messages:

// commitlint.config.js
module.exports = {extends: ['@commitlint/config-conventional']}

Conventional Changelog

Generate changelog from commits:

conventional-changelog -p angular -i CHANGELOG.md -s

Semantic Release

Automated versioning based on commit types.

Git Hooks

commit-msg Hook

Validate commit message format in .git/hooks/commit-msg.

pre-commit Hook

Run tests and linting before commit:

npm test && npm run lint

Best Practices

Make atomic commits - one logical change per commit
Write meaningful subject lines
Explain reasoning in body, not just what changed
Reference related issues
Note breaking changes clearly
Use interactive staging: git add -p
Rebase for clean history: git rebase -i HEAD~5
Sign important commits: git commit -S

Quick Reference

Common Commands

git commit -m "type(scope): subject"
git commit --amend
git add -p
git rebase -i HEAD~5
git log --oneline --graph --decorate

Common Scopes

auth - Authentication
api - API endpoints
ui - User interface
db - Database
docs - Documentation

Templates & References

See templates/ directory for:

commit-message-template.md - Complete commit templates
git-hook-examples.md - Git hook implementations

See references/ directory for:

conventional-commits.md - Specification details
semantic-versioning.md - Version bump mapping
workflow-best-practices.md - Team workflows

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Engineering
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @001eander · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Guided setup
External API key: No requirement detected
Detected OS requirements: Docker
Runtime requirements: Docker
Detected file/system behavior: Read-only
Write / modify
Env read
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview git-commit.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

> License: MIT

# Git Commit Skill

Write meaningful git commits using conventional commit format to improve collaboration, enable automation, and maintain clean project history.

## Commit Format

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

<body>

<footer>
```

### Commit Types
- **feat**: New feature for users
- **fix**: Bug fix for users  
- **docs**: Documentation changes
- **style**: Code style (formatting, etc)
- **refactor**: Code restructuring
- **test**: Test additions/modifications
- **chore**: Maintenance tasks
- **perf**: Performance improvements
- **build**: Build system changes
- **ci**: CI configuration changes
- **revert**: Revert previous commit

### Subject Line Rules
- Use imperative mood: "Add feature" not "Added feature"
- First letter capitalized, no period at end
- Max 50 characters
- Describe what the commit does

### Body Guidelines
- Explain **why** the change was made
- Use bullet points for multiple changes
- Reference related issues: `Closes #123`, `Fixes #456`
- Max 72 characters per line

### Footer Elements
- Breaking changes: `BREAKING CHANGE: description`
- Issue references: `Closes #123`, `Fixes #456`
- Co-authors: `Co-authored-by: name <email>`

## Examples

**Feature with issue reference:**
```
feat(auth): add OAuth2 support

Implement Google and GitHub authentication with JWT tokens.
Add social login buttons to UI.

Closes #123
```

**Bug fix with explanation:**
```
fix(api): resolve null pointer in user endpoint

Add null check for user object before accessing properties.
Root cause: Missing validation in user lookup function.

Fixes #456
```

**Documentation update:**
```
docs(readme): update installation instructions

Add Docker installation option.
Document required environment variables.
```

## Workflow

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Commit Format → Commit Types → Subject Line Rules → Body Guidelines → Footer Elements → Examples
terms    -> feat · fix · docs · style · refactor · test · chore · perf
files/cmd -> Closes #123 · Fixes #456 · BREAKING CHANGE: description · Co-authored-by: name <email> · git add -p · git diff --cached · git commit -m "type(scope): subject" -m "body" · git log --oneline -1
body sha256 -> e2d290c18420