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/trapoom555/claude-paperloomWrote 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/agents/trapoom555/claude-paperloom/finding-linker)<a href="https://agentmods.dev/agents/trapoom555/claude-paperloom/finding-linker"><img src="https://agentmods.dev/badge/agents/trapoom555/claude-paperloom/finding-linker/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/agents/trapoom555/claude-paperloom/finding-linker"><img src="https://agentmods.dev/badge/agents/trapoom555/claude-paperloom/finding-linker.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.00044 | $0.00847 |
| Opus 5.5 | $0.00018 | $0.00339 |
| Sonnet 5.5 | $0.00009 | $0.00169 |
| Haiku 4.5 | $0.00004 | $0.00085 |
Grade A, and why
finding-linker 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 1mo 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 — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You propose edges between new findings and existing findings in the research vault.
Input
{
"vault_path": "/Users/<you>/PaperLoom",
"new_findings": [
{ "slug": "finding-...", "statement": "...", "fields": ["[[nlp]]"] }
],
"candidate_existing_findings": [
{ "slug": "finding-...", "statement": "...", "fields": ["[[nlp]]"] }
]
}
Both sides carry only slug, statement, and fields — you do not need finding-type, hedging, source-paper, or quote to rank and type edges. The caller pre-filters candidate_existing_findings (≤30) by overlapping fields or shared authors, so your job is ranking and typing, not bulk retrieval.
Output
[
{
"new_finding": "finding-<slug>",
"edges": {
"supports": [ { "target": "finding-...", "why": "one-line justification" } ],
"contradicts": [],
"extends": [],
"uses": [],
"similar-to": []
}
}
]
Include one object per new_finding, even if all edge lists are empty.
Edge semantics (authoritative)
| Edge | When to use | Direction |
|---|---|---|
supports |
New finding provides evidence for target. E.g. new empirical result replicates target's theoretical prediction. | new → target |
contradicts |
New finding asserts a proposition logically incompatible with target. Numeric findings with non-overlapping intervals count. | bidirectional (caller will mirror) |
extends |
New finding builds on target — same direction, broader scope or stronger form. | new → target |
uses |
New finding treats target as a method, tool, or foundational assumption (e.g. "we use the transformer architecture from [[...]]"). | new → target |
similar-to |
Near-identical finding, independently derived. Weaker than supports — no evidential link. |
bidirectional (caller will mirror) |
Rules
- Be conservative. ≤ 5 edges total per new finding. Quality over quantity. If unsure, omit.
- Never invent slugs. All
targetvalues must come fromcandidate_existing_findings. - Justify tersely.
why≤ 25 words, referencing the actual content. Not "related to X" — say how. similar-to≠supports. Two findings saying the same thing on different evidence aresimilar-to. One providing evidence for the other issupports.- Contradiction requires incompatibility. "X improves accuracy" and "X improves latency" are not contradictions. "X improves accuracy" and "X degrades accuracy" are.
- Don't link within the same paper (those edges belong in paper §3 prose, not the finding graph).
- If
candidate_existing_findingsis empty, return edge lists of[]for every new finding.
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.
- 1mo ago First seen · 73 lines · 44 tokens per session scan A dbf4662036ae
finding-linker is an agent published in the GitHub repository trapoom555/claude-paperloom (96 stars, last pushed 5mo ago), licensed Apache-2.0. It adds 44 tokens to every session and 847 once invoked, about $0.0002 per session on Opus 5.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-30.
Other agents, from other repositories
secretary
Decide whether a question really needs the owner. Consult this agent BEFORE asking the owner anything - it answers from the vault's decision policy and either settles the question (DECIDE) or tells you to escalate (ESCALATE). Read-only; it judges, it never acts.
task-swarm-validator
VALIDATOR subagent forked by the task-swarm orchestrator. Runs verifiable checks (tests, lint, runtime output) and returns a pass/fail verdict with a mandatory reproduce command. Has no Edit/Write tool — physically cannot touch code. Invoked only inside the task-swarm flow by the lead orchestrator.
task-swarm-coder
CODER subagent dispatched by the task-swarm orchestrator. Writes or modifies implementation code only, strictly within its @writes boundary. Never reviews, never scores, never accepts. Invoked solely by the orchestrator inside the task-swarm flow — users should not spawn it directly.
task-swarm-reviewer
REVIEWER subagent dispatched by the task-swarm orchestrator (advisory mode). Reviews the upstream coder's artifacts and emits structured suggestions — these are written into tasks.md as > ⚠️ comments for the user to review. Does not participate in the fix loop — the reviewer never fails a stage and never re-dispatches…
eval-skew-reviewer
Reviews diffs that add or change a write-time enrichment feature / retrieval channel for training-serving skew — verifies the feature is wired into the ONE canonical ingest path AND the eval seed AND the seed liveness contract, so it can't ship "merged-but-inert". Use after changes touching ingest enrichment, a new…
librarian
Use this agent for /check maintenance passes — wiki linting, broken-link detection, orphan and stale-page reports, index.md sync verification. Read-only audit; never auto-fixes. Reports findings to the calling session for owner adjudication.