Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/apiksdev/axel-core/axel-commitgit clone --depth 1 https://github.com/apiksdev/axel-coreWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00018 | $0.01601 |
| Opus 5 | $0.00009 | $0.00800 |
| Sonnet 5 | $0.00004 | $0.00320 |
| Haiku 4.5 | $0.00002 | $0.00160 |
Grade A, and why
axel:commit scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 201 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AXEL Command: /axel:commit
<document type="command" entry="cmd:main">
<enforcement>
<![CDATA[
COMMIT RULES:
- MUST find git repository root using: git rev-parse --show-toplevel
- MUST change to git root directory before commit operations
- MUST read CLAUDE.md for COMMIT_MESSAGE_FORMAT configuration
- MUST get user approval before committing (NEVER auto-commit)
- Default to "single-line" format if configuration not found
- Handle unstaged changes by offering stage-all option
]]>
</enforcement>
<objective>
Smart git commit command that:
1. Finds repository root directory
2. Reads commit format from CLAUDE.md configurations
3. Analyzes staged changes
4. Generates AI commit message based on format
5. Gets user approval before committing
6. Commits in correct directory (git root)
</objective>
<variables>
<var name="action" from="args.0" default=""/>
</variables>
<command id="cmd:main">
<goto to="route"/>
</command>
<execution flow="linear">
<![CDATA[
SMART GIT COMMIT - Linear execution flow
Step 1 - Route Action:
- If action = "help":
* Show usage information:
## Commit Command
Usage: /axel:commit [action]
Actions:
- (default) : Analyze changes and commit with AI-generated message
- help : Show this help message
Configuration (CLAUDE.md):
- COMMIT_MESSAGE_FORMAT: "single-line" (default), "conventional", or "detailed"
Flow:
1. Find git repository root
2. Read commit format from CLAUDE.md
3. Analyze staged/unstaged changes
4. Generate AI commit message
5. Show message and get approval
6. Commit changes
* Exit command
- Otherwise: Continue to Step 2
Step 2 - Find Git Repository Root:
- Run bash: git rev-parse --show-toplevel
- If error (contains "fatal"):
* Show error: "Not a git repository. Please run this command from within a git repository."
* Exit with error
- Store result in git_root variable
- Show: "Repository root: ${git_root}"
Step 3 - Read Commit Message Format:
- Read CLAUDE.md file in git root directory
- Look for configurations block
- Extract COMMIT_MESSAGE_FORMAT value
- Valid values: "single-line", "conventional", "detailed"
- Default to "single-line" if not found or invalid
- Store in commit_format variable
- Show: "Commit format: ${commit_format}"
Step 4 - Analyze Repository Changes:
- Change to git root directory: cd "${git_root}"
- Run bash: git status --porcelain
- If empty (no changes):
* Show: "No changes to commit. Working tree is clean."
* Exit command
- Run bash: git diff --cached --name-only (get staged files)
- Run bash: git diff --name-only (get unstaged files)
- If only unstaged files exist (no staged files):
* Show: "Unstaged Changes Detected"
* Show: "You have unstaged changes but nothing is staged for commit."
* Show: "Files with changes:" + unstaged files list
* Ask: "Stage all files for commit? (1=Yes, 2=No)"
* If 1 → Run bash: git add -A, then re-run Step 4
* If 2 → Show "Commit cancelled by user.", exit command
- If no staged files and no unstaged files:
* Show: "No changes to commit. Working tree is clean."
* Exit command
- Continue to Step 5
Step 5 - Get Diff of Staged Changes:
- Run bash: cd "${git_root}" && git diff --cached
- Store full diff in diff_result variable
- Run bash: cd "${git_root}" && git diff --cached --stat
- Store summary in diff_stat variable
Step 6 - Generate Commit Message:
- Analyze diff_result and staged files
- Generate message based on commit_format:
IF commit_format = "single-line":
- Format: "type: description"
- Max 72 characters
- Types: feat, fix, docs, refactor, test, chore, style, perf, build, ci
- Focus on WHAT changed and WHY
- Example: "feat: add user authentication with JWT tokens"
IF commit_format = "conventional":
- Format: "type(scope): description"
- Max 72 characters for title
- Optional body after blank line
- Types: feat, fix, docs, refactor, test, chore, style, perf, build, ci
- Example:
feat(auth): add JWT authentication
Implemented JWT-based authentication for API endpoints
IF commit_format = "detailed":
- Title line (max 72 chars)
- Blank line
- Body wrapped at 72 chars with bullet points
- Describe what changed and why
- Example:
feat: add user authentication system
- Implemented JWT token generation and validation
- Added login and logout endpoints
- Created middleware for protected routes
- Updated user model with password hashing
- Quality check:
* Clear and concise
* Describes "what" and "why" (not just "how")
* Follows conventional commits style
* Appropriate type based on changes
- Store in commit_message variable
Step 7 - Approval Loop:
- Show:
## Proposed Commit Message
```
${commit_message}
```
---
**Files to be committed:**
${staged_files}
**Changes summary:**
${diff_stat}
- Ask: "Choose action: (1=Commit, 2=Cancel, 3=Edit message)"
- If 1 → Continue to Step 8
- If 2 → Show "Commit cancelled by user.", exit command
- If 3 → Ask "Enter new commit message:", update commit_message, return to Step 7 (repeat approval loop)
Step 8 - Execute Commit:
- Run bash: cd "${git_root}" && git commit -m "${commit_message}"
- If result contains "error" or "fatal":
* Show: "Commit Failed"
* Show error output
* Show possible reasons:
- Pre-commit hooks failing
- No changes staged
- Git configuration issues
* Show: "Please resolve the issue and try again."
* Exit with error
- If success:
* Show: "Commit Successful"
* Show commit result output
* Show: "Committed in: ${git_root}"
* Exit command
]]>
</execution>
<understanding/>
</document>
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 201 lines · 18 tokens per session scan A a93ddc763758
axel:commit is a command published in the GitHub repository apiksdev/axel-core (7 stars, last pushed 6mo ago), licensed Apache-2.0. It adds 18 tokens to every session and 1,601 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.