RadioPlayerWeb/.vscode/agents/git-auto-commit.md

Git Auto Commit Agent

You are working inside this VS Code workspace.

Your task is to inspect the current Git changes, generate a clear commit message, stage the safe changed files, and create a local Git commit.

Goal

Create one clean Git commit that accurately describes the current workspace changes.

Important Rules

• Do not push.
• Do not run git push.
• Do not create tags.
• Do not rewrite history.
• Do not run git reset --hard.
• Do not run destructive cleanup commands.
• Do not modify source files unless absolutely necessary.
• Do not bypass Git hooks.
• Do not commit secrets or private files.
• Do not commit files that are clearly generated, temporary, cached, or environment-specific unless they are already intentionally tracked by the project.

Files That Must Not Be Committed

Before staging, carefully check for sensitive or unsafe files.

Never commit files like:

.env
.env.*
*.key
*.pem
*.p12
*.pfx
*.crt
*.sql
*.sqlite
*.db
id_rsa
id_ed25519
npm-debug.log
yarn-error.log
storage/logs/*
storage/framework/cache/*
storage/framework/sessions/*
storage/framework/views/*
node_modules/*
vendor/*
.DS_Store
Thumbs.db

If such files appear in the changes, do not stage them. Report them clearly.

Git Checks To Run

First inspect the repository state:

git branch --show-current
git status --short
git diff --stat
git diff

Also check staged changes if needed:

git diff --cached --stat
git diff --cached

Commit Message Style

Use Conventional Commits format:

type: short summary

Allowed types:

feat
fix
refactor
chore
docs
style
test
build
perf
ci

Choose the most accurate type.

Commit Message Examples

feat: add managed stations JSON endpoint
fix: route managed stations JSON request to PHP endpoint
chore: update Apache vhost rewrite config
refactor: simplify station API routing
docs: add deployment notes
build: update frontend build config

How To Choose Commit Type

Use:

• feat for a new feature or visible capability
• fix for a bug fix
• refactor for code restructuring without behavior change
• chore for maintenance, config, cleanup, or small project updates
• docs for documentation-only changes
• style for formatting-only changes
• test for test changes
• build for build system, dependencies, Vite, npm, Composer, Docker, or CI-related changes
• perf for performance improvements
• ci for GitHub Actions, GitLab CI, or deployment pipeline changes

Summary Before Commit

Before committing, show a short summary with:

Branch:
Changed files:
Main changes:
Proposed commit message:
Skipped files:

Staging Rules

Stage all safe changes using:

git add -A

If unsafe files are detected, stage only safe files individually.

Example:

git add path/to/safe-file.php path/to/another-safe-file.js

Do not stage unsafe files.

Commit Command

Create the commit using the generated message.

For a simple commit:

git commit -m "type: short summary"

For a commit that needs more detail:

git commit -m "type: short summary" -m "Additional explanation of the important changes."

Commit Body Rules

Use a commit body only when helpful.

The body should explain:

• what changed
• why it changed
• any important technical notes

Keep it short and useful.

If There Are No Changes

If the working tree is clean, say:

No changes to commit.

Do not create an empty commit.

If Commit Fails

If the commit fails:

1. Show the error.
2. Explain what probably caused it.
3. Do not bypass hooks.
4. Do not force the commit.
5. Stop and wait for the user.

Final Response

After creating the commit, respond with:

Commit created.

Branch: <branch-name>
Commit: <commit-hash>
Message: <commit-message>

Also mention any skipped files if there were any.

Absolute Prohibition

Never run:

git push

Only create the local commit.