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 duthaho/skillhub --skill priorartgit clone --depth 1 https://github.com/duthaho/skillhubWrote 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/duthaho/skillhub/priorart)<a href="https://agentmods.dev/skills/duthaho/skillhub/priorart"><img src="https://agentmods.dev/badge/skills/duthaho/skillhub/priorart/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/skills/duthaho/skillhub/priorart"><img src="https://agentmods.dev/badge/skills/duthaho/skillhub/priorart.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.00178 | $0.01584 |
| Opus 5 | $0.00089 | $0.00792 |
| Sonnet 5 | $0.00036 | $0.00317 |
| Haiku 4.5 | $0.00018 | $0.00158 |
Grade A, and why
priorart 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 8d 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 — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
priorart — who built this before me?
/priorart <idea> — check whether the idea already exists
/priorart — list ideas already checked (from out/priorart/checked.md)
Answer one question: has someone already built this — and what does that mean for whether you should? The deliverable is one honest verdict with the landscape as its evidence, not a survey. Advisory throughout: it recommends; the human decides what, if anything, gets built.
Step 0 — Check the memory
Read out/priorart/checked.md if it exists. If this idea (or a close
variant) was checked before, open with "Since last check": re-verify
the previous brief's findings (status changes, new arrivals since that
date) instead of redoing the whole search. The pipeline below is for ideas
not yet in the log.
Step 1 — Restate before searching
Restate the idea in one sentence — what it does, who it's for, and the constraint that makes it distinctive — and confirm it with the user. Too vague to restate → ask exactly one clarifying question, offering at most 3 example dimensions (it's a question, not a questionnaire).
Step 2 — Vocabulary before queries
Before any search, write 6–10 framings of the idea from distinct vantage points: the builder's terms, the end-user's terms, the academic field's terms, the infrastructure/implementation terms, and the adjacent discipline that likely solved this first. Map each planned query to a framing — this is what prevents five queries landing in the same semantic neighborhood and calling it coverage. Most "novel" ideas are existing ideas under a different name; the framings are where that name gets found.
Step 3 — Search where builders publish
Budget: ≤10 queries for the whole check, with 1–2 held back for Step 4's lead-tracing. Fan out 2–3 sub-agents grouped by venue class, each briefed with 2–3 framings and an explicit share of the rest (say the numbers; agents without a stated allowance keep searching). Together the briefs cover every vantage point from Step 2 — framings left out of every brief defeat the point of writing them:
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 8d ago First seen · 127 lines · 178 tokens per session scan A 3da82d0aa76d
priorart is a skill published in the GitHub repository duthaho/skillhub (9 stars, last pushed 15d ago), licensed MIT. It adds 178 tokens to every session and 1,584 once invoked, about $0.0009 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
session-deep-dive
Deep qualitative analysis of high-signal sessions. Spawns subagents with v2 template, synthesizes patterns, compares against known findings. Use after /session-scan.
brainstorm
Brainstorm Elixir/Phoenix features — explore ideas, compare approaches, gather requirements. Use when vague idea, not sure how to approach, or want to discuss before plan.
security
Enforce Elixir/Phoenix security — auth, OAuth, sessions, CSRF, XSS, SQL injection, input validation, secrets. Use when editing auth files, login flows, RBAC, or API keys.
tidewave-integration
Tidewave MCP runtime tools — debugging, smoke testing, live state inspection, SQL queries, hex docs. Use when evaluating code in a running Phoenix app.
plugin-dev-workflow
Guide plugin development workflow — editing skills, agents, hooks, or eval framework in this repo. Use when modifying files in plugins/elixir-phoenix/, lab/eval/, or lab/autoresearch/. Ensures changes pass eval, lint, and tests before committing.
techdebt
Analyze Elixir/Phoenix technical debt — duplicates, refactoring opportunities, credo issues. Use when asked about code quality, cleanup, or what to improve.