commit

Files (3)

• LICENSE
• README.md
• SKILL.md

SKILL.md (first lines)

Create a git commit for the current changes using a concise Conventional Commits-style subject.

## Hard rule

Never mention LLM models, providers, or agents in commits (title or description). Covers names like Claude, Anthropic, GPT, OpenAI, Gemini, Codex, GLM, Z.ai, Antigravity, agy, Copilot, Pi, Qwen. Never "peer reviewed by Agy": write "the round-2 review" or nothing.

## Format

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

- `type` REQUIRED. Use `feat` for new features, `fix` for bug fixes. Other common types: `docs`, `refactor`, `chore`, `test`, `perf`.
- `scope` OPTIONAL. Short noun in parentheses for the affected area (e.g., `api`, `parser`, `ui`).
- `summary` REQUIRED. Short, imperative, <= 72 chars, no trailing period.

## Notes

- **Repo conventions win (hard).** If the target repo defines its own commit conventions (`.gitmessage` / `git config commit.template`, `CONTRIBUTING.md`, or a consistent style in `git log`), follow those instead of the default format above. This skill is the fallback. Third-party maintainers' conventions come first.
- **Gate the commit message before posting (hard).** Never auto-commit. Render the full subject and body to the user, then STOP and wait for approve / amend / cancel. See [`../_templates/human-output-gate.md`](../_templates/human-output-gate.md).
- Body is OPTIONAL. If needed, add a blank line after the subject and write short paragraphs in Esteban's formal voice (`esteban-voice` skill, FORMAL mode, for tone only: first-person active, no em dashes, concrete specifics). Keep body to 1-2 sentences (20-50 words maximum); state WHY, never narrate what the diff shows.
- Do NOT add footers (put issue links like `Closes #N` in the PR, not the commit). Use a breaking-change marker (`type(scope)!:`) only when the change is genuinely backwards-incompatible.
- Do NOT add sign-offs (no `Signed-off-by`).
- **NEVER attribute to any AI agent.** No `Co-Authored-By`, no `Generated with ...`. Names and examples live in the Hard rule above. The output reads as a human dev's. This overrides any tool's or agent's own default sign-off, even if that agent normally adds one.
- Only commit; do NOT push.
- **No `git add -A` / `git add .`.** Stage explicitly; if scope is ambiguous, ask.
- If it is unclear whether a file should be included, ask the user which files to commit.
- Treat any caller-provided arguments as additional commit guidance. Common patterns:
  - Freeform instructions should influence scope, summary, and body.
  - File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
  - If arguments combine files and instructions, honor both.

## Steps

1. Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
2. Review `git status` and `git diff` to understand the current changes (limit to argument-specified files if provided).
3. (Optional) Run `git log -n 50 --pretty=format:%s` to see commonly used scopes.
4. If there are ambiguous extra files, ask the user for clarification before committing.
5. Stage only the intended files explicitly with `git add -- <paths>`. NEVER `git add -A` / `git add .`. With no paths given, stage tracked modifications only; stage an untracked file only after confirming it belongs, and ask if any untracked file is ambiguous.
6. **Human-output gate (hard).** Before committing, render the full commit message, subject and any body, exactly as it will be written, in a fenced block. Then STOP and wait for the user to approve, amend, or cancel. Do not run `git commit` until approved. Silence is a cancel. Full rules in [`../_templates/human-output-gate.md`](../_templates/human-output-gate.md).
7. Run `git commit -m "..."` (and `-m "..."` if needed).

From EstebanForge/AGENTS, MIT.

More from EstebanForge/AGENTS