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 agents/mattpocock/sandcastle/adding-an-issue-trackergit clone --depth 1 https://github.com/mattpocock/sandcastleWhat 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.00000 | $0.01638 |
| Opus 5 | $0.00000 | $0.00819 |
| Sonnet 5 | $0.00000 | $0.00328 |
| Haiku 4.5 | $0.00000 | $0.00164 |
Grade B, and why
adding-an-issue-tracker scanned grade B with 1 finding 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 3d 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.
Asks for rootmediumPrivilege escalation
A mod that escalates privileges can change anything on the machine, not only the project.
- `templateArgs.ISSUE_TRACKER_TOOLS` — Dockerfile snippet that installs the CLI. Substituted into the agent provider's Dockerfile at the `{{ISSUE_TRACKER_TOOLS}}` placeholder, which sits before the `USER agent` line, so How it starts
The opening of the file, as written. The whole thing — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Adding an issue tracker
This document is for contributors adding support for a new issue tracker (e.g. GitHub Issues, Beads, Jira, GitLab) to sandcastle init. It covers:
- Evaluating a new issue tracker — the questionnaire used to decide whether an issue tracker can be supported.
- The
IssueTrackerEntryshape — what you fill in. - Scaffold integration — how the entry plugs into
sandcastle init. - Implementation checklist — every file to touch.
For terminology (issue tracker, task, template argument, etc.), see CONTEXT.md.
What an issue tracker integration actually is
Sandcastle does not embed any issue tracker itself. An issue-tracker entry is a scaffold template: when a user picks it during sandcastle init, we substitute three CLI commands (LIST_TASKS_COMMAND, VIEW_TASK_COMMAND, CLOSE_TASK_COMMAND) into the generated prompt files, and we drop a Dockerfile snippet that installs the relevant CLI into the sandbox.
The generated project then runs those commands itself — Sandcastle is not in the loop at runtime.
This means the requirements below are about what the CLI can do unattended inside a Debian-based container, not about what the issue tracker can do as a product.
Evaluating a new issue tracker
Before implementing, confirm the issue tracker satisfies the must-haves below. If a must-have is missing, the integration likely cannot be supported until upstream changes.
Must-have CLI capabilities
- Official / first-party CLI. We will not ship a third-party CLI as the default integration. Reason: the scaffold prints these commands directly into user prompts and installs the CLI into every generated sandbox — recommending an unofficial tool puts users on a maintenance path we don't control.
- Non-interactive auth via env var. The CLI must authenticate from an environment variable (typically a personal access token) without an interactive login. The token name goes into
.env.example. - Non-interactive list command. A single command that prints open tasks, ideally filterable by some "ready" signal (label, status, query). This becomes
LIST_TASKS_COMMAND. - Non-interactive view command. A command that prints a single task by ID, including its description and (ideally) comments. This becomes
VIEW_TASK_COMMAND. - Non-interactive close command. A command that closes a task by ID, ideally accepting a closing comment. This becomes
CLOSE_TASK_COMMAND. - Installable inside a Debian container. The install must be reproducible from a Dockerfile
RUNline — apt package, official install script, single static binary, etc. No GUI installer, no per-user OAuth dance. - Stable exit codes. Non-zero on error so the agent loop can detect failures.
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.
- 3d ago First seen · 110 lines · 0 tokens per session scan B 1eb6c36ddb81
adding-an-issue-tracker is an agent published in the GitHub repository mattpocock/sandcastle (7,792 stars, last pushed 2mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,638 tokens. A static security scan graded it B with 1 finding (asks for root). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
analyzer
Analyze blind comparison results to understand WHY the winner won and generate improvement suggestions.
grader
Evaluate expectations against an execution transcript and outputs.
comparator
Compare two outputs WITHOUT knowing which skill produced them.
.NET-Notebook-Migration-Agent
Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.