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/patforna/auto-task/ship-tasknpx skills add patforna/auto-task --skill ship-taskgit clone --depth 1 https://github.com/patforna/auto-taskWhat 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.00021 | $0.01418 |
| Opus 5 | $0.00010 | $0.00709 |
| Sonnet 5 | $0.00004 | $0.00284 |
| Haiku 4.5 | $0.00002 | $0.00142 |
Grade A, and why
ship-task 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 2d ago.
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 — 102 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ship Task
Usage
/at:ship-task <task-path>
Goal
Use to wrap up a finished task - set status to done, merge, clean up.
Context
This skill is typically run as part of a larger workflow:
create-task → clarify-task → plan-task → impl-task → review-code → review-task → ship-task
As steps (e.g. clarify, plan, impl, review) typically run in new sessions, it's imperative that the task file plus repo state carry everything the next agent needs.
Task files live in the project's task store — tasks/ in the repo by default. Project config can override this and other defaults: read .claude/auto-task.config.md (project, committed) and .claude/auto-task.config.local.md (personal overrides — win on conflict) if they exist. See /at:create-task § Task Store and Project Config.
Guidance
mainthroughout this skill means the repo's default branch — substitute yours (e.g.master) if it differs.- Squash-merge by default — the task's commits collapse into a single commit on
main. - Push is automatic — invoking ship-task authorises the merge and push. No separate approval needed.
- Untracked files in the worktree are fine. Refuse only on uncommitted tracked changes.
- After the merge, re-install dependencies in the primary repo if the branch changed a dependency manifest — the primary's installed deps (
node_modules/, a virtualenv, etc.) don't update on merge. Run the ecosystem's install for each changed manifest (e.g. lockfile → package-manager install; regenerate any gitignored generated artefacts that depend on changed sources). The project config may list the exact commands.
Protocol
Step 1: Pre-Flight
Branch must be task/NNN-... with no uncommitted tracked changes.
Step 2: Mark Done
Set the task status to done. By default (in-repo task store), edit the frontmatter status: field and commit on the task branch with a (task/NNN) subject suffix — the squash in Step 3 carries it to main. If the config routes tasks to a separate repo, use its task-status command; the bump then commits there and the squash carries code only.
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.
- 2d ago First seen · 102 lines · 21 tokens per session scan A 57e2ceac1fa6
ship-task is a skill published in the GitHub repository patforna/auto-task (3 stars, last pushed 14d ago), licensed MIT. It adds 21 tokens to every session and 1,418 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 skills, from other repositories
repo-recap
Generate a comprehensive repo recap (PRs, issues, releases) for sharing with team. Pass "en" or "fr" as argument for language (default fr).
gh-axi
Operate GitHub through the gh-axi CLI - issues, pull requests, workflow runs, workflows, releases, repositories, labels, Projects (v2), Actions secrets and variables, search, and raw API access. Use whenever a task touches GitHub: listing or filing issues, reviewing or merging PRs, checking CI runs, triggering…
gsd-complete-milestone
Archive completed milestone and prepare for next version.
azsdk-common-prepare-release-plan
Create, get, update, abandon, and link SDK PRs to release plan work items for Azure SDK releases. UTILITY SKILL. USE FOR: "create release plan", "get release plan", "update release plan", "update API spec in release plan", "update SDK details in release plan", "abandon release plan", "link SDK PR to plan", "namespace…
testdino-releases
Use when the user wants to browse, inspect, create, or update releases/milestones in a TestDino project. Covers listreleases, getrelease, createrelease, and updaterelease. Accepts counter-style IDs like MS-12.
fix-issues
Fix a batch of open GitHub issues end to end - one git worktree and one agent per issue (feature-dev for implementation, review-pr for review), individual PRs into develop, a release PR to main with a final multi-agent integration review, and optional tag/release/issue-comment publishing. Use when the user asks to…