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 skills add patforna/auto-task --skill clarify-taskgit clone --depth 1 https://github.com/patforna/auto-taskWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/patforna/auto-task/clarify-task)<a href="https://agentmods.dev/skills/patforna/auto-task/clarify-task"><img src="https://agentmods.dev/badge/skills/patforna/auto-task/clarify-task/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/patforna/auto-task/clarify-task"><img src="https://agentmods.dev/badge/skills/patforna/auto-task/clarify-task.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00065 | $0.00931 |
| Opus 5.5 | $0.00026 | $0.00372 |
| Sonnet 5.5 | $0.00013 | $0.00186 |
| Haiku 4.5 | $0.00006 | $0.00093 |
Grade A, and why
clarify-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 1mo 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Clarify Task
Usage
/at:clarify-task <task-path> [further user instructions]
Goal
Ensure the task is clear enough so that two reasonable agents - with access to the task content and repo only - would neither complete the task in a meaningfully different way nor disagree on whether the task is done.
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. Project config can override its location 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. /at:config owns the defaults and the precedence rules.
When another skill invokes this one (/at:create-task Step 6, /at:auto-task Step 0.3), run Steps 1–2 in a fresh subagent so the task is read cold, and Steps 3 onward on the main thread: a subagent can neither ask the user (Step 3) nor spawn the Step 5 verifier.
Step 1: Understand the Task
- Read the task and explore the relevant parts of the codebase to make sure you fully understand what the task is about and ground your questions.
- If you detect ambiguity, vagueness or implicit assumptions, do another round of deeper exploration and try to resolve.
Step 2: Identify Issues
If after completing Step 1 you conclude that two reasonable agents - with access to the task content and repo only - would either complete the task in a meaningfully different way or disagree on whether the task is done, flag it to the user.
Triggers (non-exhaustive):
- Motivation missing - task says what but not why.
- Incomplete content - trailing-off sentences, TODOs, TBDs, "should we...?", etc.
- Acceptance criteria weak - vague, untestable, or missing boundary/edge cases (see
/at:create-task§ Acceptance criteria). - Unclear scope - a criterion two reasonable agents would read differently.
- Semantic ambiguity - same term, field, column, etc. meaning different things (e.g. "days" = calendar or trading?).
- Implicit assumptions - things the implementer must assume that aren't stated.
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.
- 1mo ago Changed · +2 lines e0b7c698ba71
- 1mo ago First seen · 74 lines · 65 tokens per session scan A b6293f488b4e
clarify-task is a skill published in the GitHub repository patforna/auto-task (11 stars, last pushed 1mo ago), licensed MIT. It adds 65 tokens to every session and 931 once invoked, about $0.0003 per session on Opus 5.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
nft-standards
Implement NFT standards (ERC-721, ERC-1155) with proper metadata handling, minting strategies, and marketplace integration. Use when creating NFT contracts, building NFT marketplaces, or implementing digital asset systems.
postgresql-table-design
Use this skill when designing or reviewing a PostgreSQL-specific schema. Covers best-practices, data types, indexing, constraints, performance patterns, and advanced features.
istio-traffic-management
Configure Istio traffic management including routing, load balancing, circuit breakers, and canary deployments. Use when implementing service mesh traffic policies, progressive delivery, or resilience patterns.
event-store-design
Design and implement event stores for event-sourced systems. Use when building event sourcing infrastructure, choosing event store technologies, or implementing event persistence patterns.
projection-patterns
Build read models and projections from event streams. Use when implementing CQRS read sides, building materialized views, or optimizing query performance in event-sourced systems.
workflow-orchestration-patterns
Design durable workflows with Temporal for distributed systems. Covers workflow vs activity separation, saga patterns, state management, and determinism constraints. Use when building long-running processes, distributed transactions, or microservice orchestration.