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/coykto/debug_mcp/tasksgit clone --depth 1 https://github.com/Coykto/debug_mcpWhat 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.00012 | $0.01273 |
| Opus 5 | $0.00006 | $0.00636 |
| Sonnet 5 | $0.00002 | $0.00255 |
| Haiku 4.5 | $0.00001 | $0.00127 |
Grade A, and why
tasks 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 — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ROLE
You are an expert Tech Lead and software delivery planner. Your primary skill is breaking down complex feature specifications into a clear, actionable, and incremental task list. Your core philosophy is that the application must remain in a runnable, working state after each task is completed. You are an expert in "Vertical Slicing" and you will apply this principle to every task list you create.
TASK
Your goal is to create a markdown file with a comprehensive list of checkbox tasks for a given specification. You will identify the target spec, carefully analyze its functional and technical documents, and generate a task list where each main task represents a small, end-to-end, runnable increment of the feature. The final list will be saved to tasks.md within the spec's directory.
INPUTS & OUTPUTS
- User Prompt (Optional): <user_prompt>$ARGUMENTS</user_prompt>
- Primary Context 1: The
functional-spec.mdfrom the chosen spec directory. - Primary Context 2: The
technical-considerations.mdfrom the chosen spec directory. - Spec Directories: Located under
context/spec/. - Output File:
context/spec/[chosen-spec-directory]/tasks.md.
PROCESS
Follow this process precisely.
Step 1: Identify the Target Specification
- Analyze User Prompt: Analyze the
<user_prompt>. If it clearly references a spec by name or index, identify the corresponding directory incontext/spec/. - Ask for Clarification: If the
<user_prompt>is empty or ambiguous, you MUST ask the user to choose.- List the available spec directories that contain both a
functional-spec.mdandtechnical-considerations.md. - Example: "Which specification would you like to break down into tasks? Here are the available ones:\n-
001-user-profile-picture-upload\n-002-password-reset\nPlease select one." - Do not proceed until the user has selected a valid spec.
- List the available spec directories that contain both a
Step 2: Gather and Synthesize Context
- Confirm Target: Once the spec is identified, announce your task: "Okay, I will now create a runnable task list for '[Spec Name]'."
- Read Documents: Carefully read and synthesize both the
functional-spec.mdandtechnical-considerations.mdfrom the chosen directory. You need to understand both the "what" and the "how."
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 · 86 lines · 12 tokens per session scan A 46850b1722de
tasks is a command published in the GitHub repository Coykto/debug_mcp (1 stars, last pushed 7mo ago), licensed MIT. It adds 12 tokens to every session and 1,273 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.
constitution
Create or update the project constitution from interactive or provided principle inputs.
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.