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/iHildy/jules-task-queueWrote 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/rules/ihildy/jules-task-queue/test-jules-task-queue)<a href="https://agentmods.dev/rules/ihildy/jules-task-queue/test-jules-task-queue"><img src="https://agentmods.dev/badge/rules/ihildy/jules-task-queue/test-jules-task-queue/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/rules/ihildy/jules-task-queue/test-jules-task-queue"><img src="https://agentmods.dev/badge/rules/ihildy/jules-task-queue/test-jules-task-queue.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.00646 |
| Opus 5.5 | $0.00000 | $0.00258 |
| Sonnet 5.5 | $0.00000 | $0.00129 |
| Haiku 4.5 | $0.00000 | $0.00065 |
Grade A, and why
test-jules-task-queue 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 13d 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.
What it actually says
Please read the README.md file to understand the purpose of this project. Your goal to to fully test it with real actions.
Required context: The GitHub app and repository have already been linked and setup via the USER from the web app.
Unless prompted to skip TEST_1 continue and perform it.
TEST_1:
I want you to leverage the GitHub CLI to fully test the process. This includes using it to create a TEST issue in the GitHub repository, and then assign it the jules label, then sleep for 10s and check if the Jules bot has replied in the issue comments, also check if our system automatically reacted to it with an emoji. If that was successful please remove the issue entirely. If it failed at any part please remove the the issue entirely as well to avoid leaving unnecessary issues in the GitHub (use the --yes flag to avoid confirmation prompts), then proceed to investigate any issues you ran into with the codebase and use your context to fix them. Use the gh issue view <issue-number> --comments > output.txt 2>&1 and then cat output.txt command to view the issue and comments.
If TEST_1 was fully successful (or you were instructed to skip it) then proceed to perform TEST_2
TEST_2:
We now are to test the queueing system - an extremely crucial part of this project. You need to use the GitHub CLI again to create 5 issues for testing on ONE command (either via && or a native way) that each have the jules label, immediately after create 5 more issues in ONE command with the same label. Immediately after check the status of ALL 10 issues in ONE command checking for things like the jules-queue label and comments saying the limit was reached by the Jules bot. Then query our database to check that all data was stored correctly and everything is queued correctly. Then use our ‘cron:run’ command in package.json to run the cron job, after which check all 10 issues again and the database for expected behavior. Then prompt the USER to login to Jules web app (jules.google) and make sure to end all currently running - in order to provide them sufficient time to do this use the terminal tool to request to run this command exactly: echo “Run this once the 5 concurrent task limit is negated and there are 0 tasks running in Jules”. If that is the case then run the ‘cron:run’ command once more and then check the statuses of all issues in one command, its expected that the previous 5 that were queued have now only the jules tag and the Jules GitHub bot has commented it started. In that case of a fully successful test delete all the test GitHub issues in one command to not cause issue bloat. Then return the status to the user the test was successful, prompt the user to delete their tasks in Jules.
If at any point during any test an unexpected behavior happens investigate in the code and fix the issue based on your knowledge as an expert SWE
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.
- 13d ago First seen · 20 lines · 0 tokens per session scan A 91ccefe07825
test-jules-task-queue is a cursor rule published in the GitHub repository iHildy/jules-task-queue (17 stars, last pushed 8mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 646 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-10-02.
Other cursor rules, from other repositories
hook-commits
Set up pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.
development_workflow
Spamoor Development Workflow and Best Practices.
desktop-release-gate
Desktop app fixes must pass a local packaged build smoke test before pushing release tags or CI desktop builds.
roslyn-mcp-version-bump
Auto-bump Version after successful MCP self-build and reload.
fusebase-flow-implementation
Fusebase Flow implementation phase rules. Use when editing source code per a locked spec.
push_rules
A project rule requiring checks before code is committed and pushed. For this Deno project, the required checks are formatting, linting, and the full test suite; new functions also need documentation and tests.