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 skills/devoxx/devoxxgenieideaplugin/close-task-commit-push-prnpx skills add devoxx/DevoxxGenieIDEAPlugin --skill close-task-commit-push-prgit clone --depth 1 https://github.com/devoxx/DevoxxGenieIDEAPluginWhat 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.00064 | $0.01046 |
| Opus 5 | $0.00032 | $0.00523 |
| Sonnet 5 | $0.00013 | $0.00209 |
| Haiku 4.5 | $0.00006 | $0.00105 |
Grade A, and why
close-task-commit-push-pr 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 — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Close Task, Commit, Push & PR
Context
- Current git status: !
git status - Current git diff (staged and unstaged changes): !
git diff HEAD - Current branch: !
git branch --show-current - Main branch: !
git rev-parse --verify main 2>/dev/null && echo main || echo master - Recent commits: !
git log --oneline -10
Your task
Close the active backlog task, commit all changes, push, and open a pull request.
Step 0 — Identify the task
- Extract the task ID from the current branch name (e.g.
feature/task-113-split-css-modules→task-113). - If no task ID is found in the branch name, ask the user which task to close.
Step 1 — Close the backlog task
Close the task before committing so the task file changes are included in the commit and PR.
- Use
mcp__backlog__task_viewto read the task details (title, acceptance criteria). - Use
mcp__backlog__task_editto:- Set status to
Done - Check off all acceptance criteria that were completed (review the diff to determine which ones)
- Write a
finalSummarythat concisely describes what was implemented
- Set status to
- Use
mcp__backlog__task_completeto move the task to the completed folder.
Step 2 — Analyze changes and plan commits
Before committing, analyze git status and git diff HEAD to identify logically distinct groups of changes. Group by feature or concern — for example:
- New files that form a self-contained module → one commit
- Modifications to an existing file that depend on the new module → separate commit
- Task/backlog file changes → include in the final commit (or a dedicated chore commit)
Print a short commit plan (list of planned commits with the files in each) so the grouping is visible.
Step 3 — Commit
- Create one commit per logical group identified above. Stage only the files for that group using explicit file names (never
git add -A; never stage.envor credential files). - Write a clean, descriptive commit message for each commit using conventional commits style.
- End every commit message with:
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> - Use a HEREDOC to pass the commit message for correct formatting.
- Include the closed task file in the final commit.
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 · 96 lines · 64 tokens per session scan A b091de88af96
close-task-commit-push-pr is a skill published in the GitHub repository devoxx/DevoxxGenieIDEAPlugin (677 stars, last pushed 5d ago), licensed MIT. It adds 64 tokens to every session and 1,046 once invoked, about $0.0003 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-30.
Other skills, from other repositories
agtx-sweep
Sweep this conversation into agtx tasks and push them to the kanban board. Use when the user wants to capture, decompose, or hand off conversation results to the agtx board.
nap
Context hygiene — compress, prune, archive .squad/ state.
call-diagnostics
Analyze phone call observability data, detect problems, track them across calls, and recommend systematic repairs.
backlog
EXPERIMENTAL. Use when working the project-wide out-of-scope backlog at paad/code-reviews/backlog.md — cleaning it of entries that are already fixed or gone, or picking the next entry and fixing it end-to-end. Not for producing backlog entries — that is /agentic-review — and not for reviewing a branch diff.
backlog
Capture single backlog items, or list and triage an existing project backlog. Use this skill whenever the user wants to file a bug, feature request, or backlog item without writing a full PRD, including casual requests mid-conversation like "create an issue for that", "add this to the backlog", or "file a quick bug…
workflow-reference
This skill should be used when executing the epic-dev workflow, creating epic branches, managing sprint phases, working with git worktrees for phased feature development, or when the user mentions "epic dev", "epic-dev", "/epic-dev", "epic workflow", "sprint phases", "phased development", or "git worktree workflow".