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 skills add IdanTayree/Blindspot --skill blindspotgit clone --depth 1 https://github.com/IdanTayree/BlindspotWrote 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/skills/idantayree/blindspot/blindspot)<a href="https://agentmods.dev/skills/idantayree/blindspot/blindspot"><img src="https://agentmods.dev/badge/skills/idantayree/blindspot/blindspot.svg" alt="Measured on agentmods" 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.00227 | $0.03954 |
| Opus 5 | $0.00113 | $0.01977 |
| Sonnet 5 | $0.00045 | $0.00791 |
| Haiku 4.5 | $0.00023 | $0.00395 |
Grade A, and why
blindspot 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 6d 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 — 269 lines — stays where its author put it; the contents beside it link to each section on GitHub.
blindspot
Named for what it looks for: the two things nobody can self-report — what you assumed was too obvious to say, and what you never considered at all.
Someone arrives with one sentence: "an app that helps dog walkers find clients." A plan written straight from that sentence is fiction — every important decision gets made by whoever writes it, not by the person who has to live with it.
This skill replaces that with two phases:
- Interview — one question per message until the unknowns stop appearing, writing every answer to disk as it arrives.
- Harvest — for each component the blueprint needs, find real open-source projects and verify them before recommending anything.
Phase 2 depends on phase 1. Harvesting against a half-formed idea produces a list of libraries for a product nobody has decided on yet. Finish the interview first, or at least reach a component list the user agrees with.
Two ways in
From nothing — one sentence and an intention. Start at "before the first question" below.
From a project already underway — someone with code, docs and momentum who says it was never planned properly, that it is full of gaps, or that they are no longer sure what they have actually decided. This is the more common case and the more valuable one, because the gaps are load-bearing by the time anyone notices them.
The mid-project entry changes the opening, not the method:
- Read what exists before asking anything. Their README, plan docs, ADRs, issues, the directory layout, recent commits. An audit that opens by asking things already written down burns the user's patience on work they have already done, and they will answer more shallowly for the rest of the interview.
- Populate the blueprint from those artefacts, marking each entry with where it came from — from your docs or from you. Provenance matters here: a decision recorded in a doc nobody has revisited in six months is not the same as one they just confirmed, and the difference is often the gap itself.
- Then run a collision pass over what already exists, before asking anything new. This is the highest yield move in the whole skill for an existing project: decisions made months apart contradict each other constantly, and nobody has put them side by side. Open with one of those, not with a beginner question.
- Name the untouched areas — what a project of this shape normally has to decide and theirs never has. Say them plainly as a list; that list is usually why they came.
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.
- 6d ago First seen · 269 lines · 0 tokens per session scan A 72a970c08c57
blindspot is a skill published in the GitHub repository IdanTayree/Blindspot (5 stars, last pushed 19d ago), licensed MIT. It adds 227 tokens to every session and 3,954 once invoked, about $0.0011 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 skills, from other repositories
yolo-plan
Use when you have a goal or brief and need to break it into executable, testable tasks. Produces a committed plan.md. Triggers on "make a plan", "break this into tasks", or as the planning step of yolo-feature.
yolo-finish
Use when a feature is implemented and verified, to land it. Default path is PR + CI check, with the ship gate confirming before the irreversible merge; fast-local is the escape hatch. Includes the risk classifier whose hard triggers always stop for a human. Triggers on "ship it", "land this", "open a PR", or as the…
yolo-feature
Use when the user wants to build, add, or implement a feature. Captures intent, drafts a brief, confirms, then composes research → plan → execute → verify → finish. In a YOLO-initialized repo this takes precedence over generic brainstorming for feature intent.
yolo-debug
Use when a reported problem, failure, or bug needs a systematic root-cause investigation — reproduce → isolate → fix → verify — recorded as one durable artifact. Triggers on "fix the 500 on login", "X is broken", "why is Y failing?", "debug this", "track down this bug".
yolo-decide
Use when facing a design or architecture decision that benefits from multiple perspectives before committing. Produces a decision record under workspace/decisions/. Triggers on "help me decide X vs Y", "which approach", "should we use A or B".
yolo-intake
Use when a feature should draw on the project's reference material for context. yolo-intake does NOT fetch, import, or copy anything — it points YOLO at a selected folder (default docs/) and READS from it to enrich a feature's context. Getting material INTO that folder (a Figma, a spec, a URL, a schema) is the docs…