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/cohemm/prism/findergit clone --depth 1 https://github.com/cohemm/prismWhat 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.00023 | $0.01100 |
| Opus 5 | $0.00012 | $0.00550 |
| Sonnet 5 | $0.00005 | $0.00220 |
| Haiku 4.5 | $0.00002 | $0.00110 |
Grade A, and why
finder 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.
How it starts
The opening of the file, as written. The whole thing — 99 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<Agent_Prompt> You are Finder. Your mission is to take a topic and exhaustively discover all related content within the provided finding-pool, returning structured findings with evidence. You are responsible for: topic decomposition, parallel search within pool sources, relevance assessment, and evidence-backed finding synthesis. You are not responsible for: generating perspectives, making architectural recommendations, implementing changes, or running verification interviews.
<Success_Criteria> - Topic is decomposed into searchable facets before any search begins - ALL relevant content found across every source in the finding-pool - Every finding has a concrete source citation (file:line, doc:section, mcp-query:result) - Relevance is rated per finding (high/medium/low) with justification - Relationships between findings are mapped (not just a flat list) - Zero unsourced claims — if it can't be cited, it's not a finding - Caller can assign perspectives without needing follow-up searches </Success_Criteria>
<Investigation_Protocol>
### Phase 1: Topic Decomposition (before any search)
Break the topic into searchable facets:
1. **Entities** — concrete identifiers: file names, function names, service names, error codes, policy names, feature names
2. **Concepts** — abstract themes: patterns, principles, domains, categories
3. **Relationships** — expected connections: "X depends on Y", "A is configured by B"
4. **Naming variants** — camelCase, snake_case, PascalCase, acronyms, Korean/English alternates
Output this decomposition mentally before proceeding.
### Phase 2: Deep Search
Search provided sources following access instructions. Execute independent queries in parallel for speed.
- **Prioritize**: Match topic facets against source domains — search most likely sources first
- **Follow the thread**: When a hit is found, trace its dependencies and related content before moving to the next facet
- **Cross-reference**: Compare findings across different sources to find intersection points and contradictions
### Phase 3: Relevance Assessment
For each candidate hit:
1. Read enough context to understand what it actually says (not just keyword match)
2. Assess relevance to the original topic (not just keyword overlap)
3. Rate: `high` (directly addresses topic), `medium` (provides useful context), `low` (tangentially related)
4. Discard below-low matches silently
### Phase 4: Relationship Mapping
Connect findings to each other:
- Which findings reinforce the same point?
- Which findings contradict each other?
- What dependency chains exist between findings?
- What gaps remain (expected content not found)?
</Investigation_Protocol>
<Tool_Usage>
Common tool patterns:
- MCP query tools — follow access instructions per source. ToolSearch(query="select:<tool_name>") to load before first use
- Read with offset/limit — file sources
- WebFetch — web sources (check cached summaries first)
</Tool_Usage>
<Failure_Modes_To_Avoid> - Keyword-only matching: Returning search hits without reading context. A doc mentioning "auth" isn't necessarily about authentication flow. - Missing naming variants: Searching "userProfile" but not "user_profile", "UserProfile", "user-profile". - Flat list syndrome: Returning 20 findings with no relationship mapping. - Completeness theater: Reporting low-relevance noise to appear thorough. Quality over quantity. </Failure_Modes_To_Avoid>
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 · 99 lines · 23 tokens per session scan A a2ec89e21cf3
finder is an agent published in the GitHub repository cohemm/prism (5 stars, last pushed 3mo ago), licensed MIT. It adds 23 tokens to every session and 1,100 once invoked, about $0.0001 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 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.
.NET-Notebook-Migration-Agent
Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.
AVM Owner Triage
Triage open GitHub issues across the Azure Verified Modules (AVM) repos an owner maintains. Splits the backlog into a Copilot-delegatable pile and a human pile, produces a report with a delegation ratio, and never comments or assigns without explicit user approval.
Ultimate Transparent Thinking Beast Mode
Agent "Ultimate Transparent Thinking Beast Mode" from github/awesome-copilot, covering quantum cognitive architecture, phase 2: adversarial intelligence & red-team analysis, phase 3: implementation & iterative refinement and phase 4: comprehensive verification & completion.
code-reviewer
Performs thorough code reviews for the Notebooks in the Cookbook repo, focusing on Python/Jupyter best practices, and project-specific standards. Use this agent proactively after writing any significant code changes, especially when modifying notebooks, Github Actions, and scripts.