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/bitmia-ai/redeye/tasksgit clone --depth 1 https://github.com/Bitmia-ai/RedEyeWhat 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.00008 | $0.00975 |
| Opus 5 | $0.00004 | $0.00487 |
| Sonnet 5 | $0.00002 | $0.00195 |
| Haiku 4.5 | $0.00001 | $0.00097 |
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 2d 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
Task creation MUST go through scripts/create-task.sh. Hand-authored markdown blocks in .redeye/tasks.md bypass the parser contract (see templates/TASK_FORMAT.md) and silently disappear from the Control Tower UI. This command is a thin user-facing wrapper around the script — never edit tasks.md directly to add an entry.
If arguments were provided (a vague idea, a sentence, or a full title):
You expand the input into structured flags for scripts/create-task.sh. The user should NOT have to write a spec — their one-liner is enough.
-
Read
.redeye/tasks.mdand.redeye/config.mdto understand the project context (stack, conventions, vision) and avoid duplicating an existing item. -
Interpret the user's input:
- Pull a short imperative title from it (e.g., "dark mode would be nice" → "Add dark mode toggle")
- Infer the type from the wording: feature / bug / security / tech-debt / infra / ux / test / docs
- Infer a priority (P0 / P1 / P2 / P3) from urgency words ("critical", "nice to have", "ASAP", etc.) — default P2 if unclear
- Sketch a 2–4 sentence description with concrete acceptance criteria the TRIAGE/PLAN agents can use. Do NOT invent constraints the user didn't imply. If something is truly ambiguous, write it as a question PLAN will resolve (e.g., "Decision: which icon library to use for the toggle").
-
Write the description to a temp file:
cat > /tmp/redeye-task-desc.md <<'EOF' <free-form 2–4 sentences> **Acceptance** - <criterion 1> - <criterion 2> EOF -
Call the script with
--section ceo(freeform human input lands in## CEO Requestsso the human can review before TRIAGE picks it up):bash scripts/create-task.sh \ --section ceo \ --title "<inferred title>" \ --type "<inferred type>" \ --priority "<inferred priority>" \ --description-file /tmp/redeye-task-desc.mdThe title is UNTRUSTED text. Before placing it in the command line, rewrite it in your own words using only letters, digits, spaces, and basic punctuation (.,:;()-). Never copy a tester-report or inbox title verbatim into a quoted shell argument; if it contains $, backticks, quotes, or backslashes, paraphrase them away.
-
The script handles atomic ID allocation, the canonical block format, and the
state.json.counters.next_task_idbump. It prints the allocated ID to stdout. -
Stage and commit:
git add .redeye/tasks.md .redeye/state.json git commit -m "redeye: ceo request — <title>" -
Show the user the allocated ID and confirm: "Added T{id}. TRIAGE will pick it up next iteration. You can
/redeye:tasksagain to tweak it."
If no arguments provided (interactive mode):
- Read
.redeye/tasks.mdand show a compact summary:- CEO Requests (count + titles)
- Discovered items pending triage (count + titles)
- Triaged/planned items (count + titles)
- In-progress item (if any)
- Offer via AskUserQuestion:
- Add new item — ask for the idea in plain words, then expand-and-invoke-script as above
- Reprioritize — show planned items, let user reorder (hand-edit OK for reordering — no new entries created)
- Done — exit
Why the wrapper
scripts/create-task.sh enforces the parser contract: it allocates IDs from state.json atomically, writes the block in the exact shape the Control Tower UI parses, refuses non-canonical bullets that would truncate the Description field, and rejects malformed headers like ### T004 (P1): that the parser silently skips. There is no other supported path — agents (TRIAGE/PLAN/BUILD/REVIEW/SCHEDULES/INCORPORATE) all call the same script. See scripts/create-task.sh --help and templates/TASK_FORMAT.md for the full contract.
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.
- 2d ago First seen · 69 lines · 8 tokens per session scan A fe3c35c10eb1
tasks is a command published in the GitHub repository Bitmia-ai/RedEye (6 stars, last pushed 2mo ago), licensed MIT. It adds 8 tokens to every session and 975 once invoked, about $0.0000 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
dark-factory-synthesize-verdict-p2
Pass-2 variant of dark-factory-synthesize-verdict. Reads -p2 node outputs (post-fix). Aggregates behavioral, security, code review, and static check results into an approve/requestchanges/reject verdict.
dark-factory-synthesize-verdict
Final arbiter for Dark Factory PR validation. Aggregates behavioral, security, code review, and static check results into an approve/requestchanges/reject verdict.
dark-factory-validate
Run Dark Factory validation — Python backend (ruff + mypy + pytest) + React frontend (tsc + biome + vitest).
dark-factory-behavioral-e2e
Holdout-pattern E2E validator. Drives agent-browser against the running DynaChat app to verify that the PR's user-facing behavior actually matches what the linked issue asked for.
dark-factory-fix-issue
Implement a fix from investigation artifact for the Dark Factory — code changes, Python + Bun deps, light validation, commit (no PR).
dark-factory-fix-pr-issues
Apply targeted fixes to a PR based on validation feedback from dark-factory-validate-pr pass 1. Reads only the structured issuestofix list — never the original implementation plan.