# Gessnerfl Fake Smtp Server Fake Smtp Server > Safe Git Commit Workflow - Skill: `tomevault-io/gessnerfl-fake-smtp-server-fake-smtp-server` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/gessnerfl-fake-smtp-server-fake-smtp-server` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/gessnerfl-fake-smtp-server-fake-smtp-server/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/gessnerfl-fake-smtp-server-fake-smtp-server --- # Safe Git Commit Workflow This skill gates every commit behind a test run and user confirmation. The goal is to avoid broken commits and ensure the message accurately reflects the change. ## Step 1 — Detect what changed Run `git status` and `git diff HEAD --name-only` to see which files are modified, staged, or untracked. Group them by area: - **src/** → backend tests - **webapp/** → frontend tests If nothing has changed, tell the user and stop. ## Step 2 — Run tests for affected areas Run only the tests relevant to what changed. This keeps the feedback loop fast. | Changed area | Command | | ------------ | -------------------------------------------------------------- | | `src/` | `mvn test` | | `webapp/` | `cd webapp && npm run build && npm run lint && npm test --run` | Run each applicable command. If any test run fails, **stop immediately** and show the failure output. Do not proceed to staging or committing. Explain which area failed and what the user should fix. If all tests pass, summarise the result briefly (e.g. "✓ 111 tests passed in api module") and continue. ## Step 3 — Propose files to stage List the files you intend to stage. Use `git diff HEAD --name-only` and `git ls-files --others --exclude-standard` for untracked files. Exclude files that should not be committed: - `.claude/settings.local.json` (personal local settings) - `.env*` files - `target/` or `node_modules/` contents (should be gitignored, but flag if not) Present the proposed file list to the user clearly. If there are files you are unsure about, flag them and ask. ## Step 4 — Generate a commit message Analyse the diff with `git diff HEAD` and draft a commit message following the project's convention: ``` : ``` Types: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `ci` Keep the subject line under 72 characters. Use the body to capture the _why_ and _what_ when the change is non-trivial. Do not include `Co-Authored-By` lines. ## Step 5 — Ask for confirmation Present a summary to the user before doing anything irreversible: ``` Files to stage: Commit message: : Proceed? (yes / edit message / cancel) ``` Wait for the user's response: - **yes** (or any affirmative) → proceed to Step 6 - **edit message** / user provides new message → use their version, then proceed - **cancel** → stop, do nothing ## Step 6 — Stage and commit Stage only the files from Step 3 (add them individually, not with `git add -A` or `git add .`, to avoid accidentally staging sensitive files). Commit with the confirmed message using a heredoc to avoid shell escaping issues: ```bash git commit -m "$(cat <<'EOF' : EOF )" ``` Do **not** append `Co-Authored-By` or any attribution footer. After the commit, run `git log --oneline -3` and show the user the result so they can confirm everything looks correct. ## Notes - If the user asks to also push after committing, do so with `git push`. - If the user is on a new branch with no upstream, use `git push -u origin `. - If the user already staged files themselves before invoking the skill, respect that staging and skip the "propose files" step — just show what's staged and confirm the message. --- > Source: [gessnerfl/fake-smtp-server](https://github.com/gessnerfl/fake-smtp-server) — distributed by [TomeVault](https://tomevault.io).