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.
git clone --depth 1 https://github.com/andkirby/markdown-ticketWrote 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/commands/andkirby/markdown-ticket/implement)<a href="https://agentmods.dev/commands/andkirby/markdown-ticket/implement"><img src="https://agentmods.dev/badge/commands/andkirby/markdown-ticket/implement/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/commands/andkirby/markdown-ticket/implement"><img src="https://agentmods.dev/badge/commands/andkirby/markdown-ticket/implement.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.00000 | $0.02858 |
| Opus 5.5 | $0.00000 | $0.01143 |
| Sonnet 5.5 | $0.00000 | $0.00572 |
| Haiku 4.5 | $0.00000 | $0.00286 |
Grade A, and why
implement 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 — 354 lines — stays where its author put it; the contents beside it link to each section on GitHub.
MDT Implementation Orchestrator (v10)
Execute tasks from a task list with constraint verification after each task.
Core Principle: Verify TDD (RED→GREEN), scope boundaries (flag/STOP), structure, and no duplication after each task.
User Input
$ARGUMENTS
Session Context
Use {TICKETS_PATH} in all file path templates below (if it's not defined read ticketsPath key from .mdt-config.toml).
Execution Modes
| Command | Behavior |
|---|---|
/mdt:implement {CR-KEY} |
Interactive — auto-detect part or prompt |
/mdt:implement {CR-KEY} --prep |
Execute prep (refactoring) tasks |
/mdt:implement {CR-KEY} --part {X.Y} |
Target specific part |
/mdt:implement {CR-KEY} --all |
Run all tasks, pause at part boundaries |
/mdt:implement {CR-KEY} --continue |
Resume from last incomplete |
/mdt:implement {CR-KEY} --task {N.N} |
Run specific task only |
Execution Steps
Step 1: Load Context and Discover Part
1a. Detect mode:
| Condition | Mode | tasks_file | tests_file | Test Expectation |
|---|---|---|---|---|
--prep flag |
prep | prep/tasks.md |
prep/tests.md |
GREEN (preserve) |
--part X.Y flag |
part | part-X.Y/tasks.md |
part-X.Y/tests.md |
RED (TDD) |
Single part-*/tasks.md |
part (auto) | that part | matching tests | RED |
Multiple part-*/tasks.md |
part (prompt) | user selects | matching tests | RED |
prep/tasks.md has unchecked items |
prep (auto) | prep/tasks.md |
prep/tests.md |
GREEN |
| No part folders | single | tasks.md |
tests.md |
RED |
All paths relative to {TICKETS_PATH}/{CR-KEY}/.
If both prep (incomplete) and part tasks exist, prompt user: [Continue prep (recommended)] [Proceed to feature].
1b. Set CR status to In Progress:
mcp__mdt-all__update_cr_status(project=PROJECT_CODE, key=CR-KEY, status="In Progress")
1c. Load {tasks_file} — extract: scope boundaries, shared patterns/imports, test coverage mapping.
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 First seen · 354 lines · 0 tokens per session scan A 93d164951d23
implement is a command published in the GitHub repository andkirby/markdown-ticket (7 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,858 tokens. 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
bugfix
Bug fix workflow: root cause analysis → user review → regression test + fix via TDD.
eval
Evaluate and improve one healthcare agent's system prompt. Run up to 5 iterations of: prepare fixed questions -> answer -> judge -> improve -> re-score -> commit if better.
usage-add
PitWay: Accumulate measured planning or qa token usage onto a milestone.
speckit.tdd.plan
Derive the feature's test list by delegating to zfa tdd plan (deterministic engine); falls back to LLM-guided derivation only when zfa is unavailable.
dashboard
Generar dashboard HTML local con métricas de eficiencia del proyecto SDD.
tdd
A command that follows test-driven development (TDD), a method where you write tests before the code they check. It moves through writing a failing test, adding the smallest implementation, and then improving the code.