Every developer knows the ritual: finish coding, run git status, stare at a wall of changed files, craft a commit message, and hope you remembered everything. But what if your AI coding assistant could handle the entire commit workflow — safely, with full documentation?
seal-commit is an agent skill that wraps git commit with a safety net, smart file selection, auto-generated commit messages, and dual-format change review documents included in the same commit.
The Problem
When committing changes, you typically face three pain points:
-
Fear of losing work — one wrong
git resetorcheckoutand uncommitted changes are gone - Vague commit messages — "fix stuff" or "update files" tells future-you nothing
- No change documentation — PR descriptions, release notes, and code review context are written manually, often after the fact
What seal-commit Does
seal-commit is an AI agent skill (works with Claude Code and compatible agents) that transforms the commit workflow into a guided, documented process:
-
Stash-based safety snapshot — Before anything else, it creates a
git stash savewith a descriptive message (timestamp + file count + key filenames), then immediatelygit stash apply. Your work is always recoverable. - Numbered file selection — Lists all changed/untracked files with numbers. You just type "all", "1,3,5", or "cancel".
-
Diff analysis — Reads actual code changes (tracked via
git diff, untracked via file reading). -
Auto-generated change review docs — Produces both
human.html(rich visual with sidebar, cards, interactive checklists) andai.md(dense, structured markdown for LLM context). -
Auto-generated conventional commit message — Formats as
type(scope): subjectwith 3-5 detail bullets, no user input needed.
All in one commit — code changes and documentation together.
Safety First: The Restricted Command Allowlist
This is the core design decision. seal-commit only runs safe git commands:
| Allowed | Blocked (for safety) |
|---|---|
git stash save/apply |
git reset |
git status |
git checkout |
git diff |
git restore |
git branch --show-current |
git rebase |
git add |
git stash drop |
git commit |
git clean |
The stash safety net is never at risk because the skill never runs commands that could destroy it.
Dual-Format Change Review
Every commit generates two documents in .change-review/<branch>-<date>/:
human.html — Visual Review for People
A self-contained HTML file with:
- Fixed sidebar navigation with scroll tracking
- Hero header with linked references
- Color-coded module cards (blue, amber, emerald, violet)
- Before/After code comparison panels
- Interactive testing checklist with clickable checkmarks
- Responsive layout
ai.md — Structured Context for LLMs
A dense markdown file optimized for AI context injection:
- Factual, no filler
- Actual code snippets (before/after)
- All identifiers in backticks
- Empty sections omitted entirely
How It Works
/seal or /commit or "commit"
↓
Step 0: git stash save + apply ← safety net
↓
Step 1: git status --porcelain
→ Numbered file list
→ User selects files (only interaction)
↓
Step 2: git diff + Read tool
↓
Step 3: Generate .change-review/<branch>-<date>/
├── human.html
└── ai.md
↓
Step 4: git add + commit with conventional message
↓
Done
Installation
npx skills add conanttu/skills/seal-commit -g -y
Or manual:
git clone https://github.com/conanttu/skills.git
cd skills
ln -s $(pwd)/seal-commit ~/.claude/skills/seal-commit
No prerequisites — works with any git repository.
Usage
Just say "commit" or type /seal. The skill lists your changed files with numbers, you pick which ones, and it handles everything else.
📝 Changed files:
1. src/api/auth.ts (modified)
2. src/types/user.ts (modified)
3. src/utils/helpers.ts (new)
4. package.json (modified)
❓ Which files do you want to commit?
- Type "all" or "a" to commit all
- Type file numbers (e.g., "1,3,5")
- Type "cancel" to abort
Docs Only Mode
Generate change review without committing:
/seal doc
Conventional Commits
Commit messages are auto-generated:
feat(auth): add token refresh interceptor
- Add axios interceptor for automatic token refresh
- Handle 401 responses with retry queue
- Store refresh promise to prevent duplicate calls
- Add unit tests for retry logic
Key Design Decisions
- stash + apply (not pop) — keeps the stash intact if commit fails
- Docs before commit — review docs are included in the same commit
-
Restricted commands — no
reset,checkout, orrestore - Dual output — HTML for humans, Markdown for LLMs
vs Manual Workflow
| Manual | seal-commit | |
|---|---|---|
| Safety net | None | Automatic stash snapshot |
| File selection | Manual paths | Numbered list |
| Commit message | Write yourself | Auto-generated |
| Documentation | Write later (or never) | Auto-generated |
| LLM-friendly docs | Not available |
ai.md included |
Learn More
What's your commit workflow like? Share your thoughts below!
Top comments (3)
Auto-generating change-review docs at commit time is a smart place to put this, because the moment you have a diff staged is exactly when the "what changed and why" context is freshest and cheapest to capture - leave it for the PR description later and you're reconstructing intent from memory. The thing that separates a useful version from a noisy one: the doc has to summarize intent and impact (what behavior changed, what to look at, what could break), not just restate the diff a reviewer can already read. A change-review doc that says "modified auth.ts" adds nothing; one that says "changes token expiry from 24h to 1h, affects all active sessions" saves the reviewer real time.
The caveat I'd build in: since it's LLM-generated from the diff, it can confidently miss a subtle side effect or overstate what changed, so the doc should be a reviewer's aid, not a substitute for reading the code. That "AI proposes the summary, human verifies against the diff" boundary is the same one I build around in Moonshift, the thing I work on - a multi-agent pipeline that takes a prompt to a deployed SaaS, where generated artifacts are checked, not trusted. Multi-model routing keeps a build ~$3 flat, first run free no card. Genuinely useful skill - commit-time is the right hook. Does it diff-summarize deterministically for the mechanical parts and only LLM the intent, or is the whole doc model-generated? Mixing the two usually gives the most trustworthy result.
Right now, the whole Review Document is model-generated.
The goal here isn't to create a Diff Summary, but a document that actually helps with review. A Diff Summary mostly answers "what changed", while a Review Document should answer "why it changed", "what behavior is affected", "what the reviewer should focus on", and "what might break".
So at commit time, I give the model both the Diff and the project Baseline. That means it's not just looking at isolated code snippets. It has the surrounding context too: project structure, conventions, existing patterns, and the actual changes in this commit. With that context, the model isn't just guessing; it's explaining and summarizing based on what it can see.
I generate two outputs:
ai.md: for other AI tools to do a second-pass review, risk analysis, or cross-checking.human.html: a human-facing Review Guide that highlights intent, behavior changes, risks, and areas worth looking at.So the code and Diff are still the source of truth. The Review Document isn't meant to replace review — it's meant to capture the freshest context at commit time and help both humans and AI get to the important parts faster.
I think vibe coding has reached a point where the core problem is no longer just “how do we generate code faster”, but “how do we review that code reliably”.
Code generation will keep getting better, but if review, verification, and risk detection don't keep up, the productivity gains from AI-generated code can easily be offset by the maintenance cost later.
That's why I'm focusing more on change review now: making sure the intent, impact, and potential risks of each change can be captured and verified more reliably.
This is the direction I'll keep investing in, and I'd be happy to discuss more.