priori-incantato
Skill9 starsChanged 3 months agoMITView on GitHub
Audit whether every automation artifact is actually reached — hooks whose declared event does not match their wiring, orphaned skills/agents/commands/tests, artifacts that exist but nothing ever causes to run, and artifacts that work only because of local state a fresh clone lacks. Use for "is this hook even firing", "did my skill ever run", "find orphaned automation", "why did nothing happen", "this lint has never caught anything", or as part of /opus-pocus. Read-only; reports per-artifact declared-vs-actual wiring with a verdict. NOT for whether a check reports honestly once it does run (→ nihil-revelio). NOT for whether a guard blocks too much (→ alohomora).
In this repository20 other files it gives its agents.
- accio-rulebookSkill
- alohomoraSkill
- avada-verbosaSkill
- clarificus-maximaSkill
- configureSkill
- contradicto-revelioSkill
- descriptio-reducioSkill
- finite-recursumSkill
- legilimens-anthropicaSkill
- muffliato-hookusSkill
- nihil-revelioSkill
- obliviate-fossiliumSkill
- opus-pocusSkill
- protegoSkill
- quietus-capslockiusSkill
- sorting-hatSkill
- tempus-mutaturSkill
- the-pensieveSkill
- the-remembrallSkill
- the-room-of-requirementSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 39
Verify as a fresh clone sees it: query the VCS index, never a filesystem existence test on the machine that authored it.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
🐉 Priori Incantato
"Every artifact swears it works. Ask it when it last ran."
An artifact nothing invokes is not a feature, it is invisible debt — and it costs more than absence, because the roster claims coverage the repo does not have. The failure is quiet by construction: a hook wired to the wrong event returns success and its payload is dropped, a skill whose disambiguation lives somewhere the router never reads is simply never chosen, and neither state produces an error anywhere. This pass asks one question of every artifact: what causes you to run?
What to scan
- Hook scripts and the config that wires them (
.claude/settings*.jsonand equivalents) — the pair, never one side alone - Skills, agents, commands, output styles, and their routing-visible surfaces
- Repo-local test suites and lints, and whatever is supposed to invoke them
- The version-control index — the ground truth for what a fresh clone actually receives
Anti-patterns to find
- Declared-vs-wired event mismatch. A hook emits one event name in its payload while the config fires it on a different event. The handler runs, the payload is discarded silently, and both sides look healthy in isolation. Only comparing the pair reveals it.
- Orphans. A skill, agent, command, hook, lint or test that nothing invokes — no config entry, no caller, no documented route. Count them honestly and separate the ones this change created from the ones that predate it.
- Availability mistaken for discoverability. The artifact exists, is wired, and still never runs, because nothing causes it to be reached: a router that reads only a description field while the disambiguation lives in the body; an advisory that fires after the decision it was meant to inform; a skill whose triggers no real user phrasing matches.
- Fresh-clone unreachability. The artifact works only because of local state — an unversioned file, a locally-set executable bit, an absolute path, a machine-specific tool. Verify as a fresh clone sees it: query the VCS index, never a filesystem existence test on the machine that authored it.
- Wired to a dead event. The trigger existed once. The event was renamed, the tool it matched was removed, or the workflow that called it was retired — and the artifact still sits there declaring a route to nowhere.
- The finish-the-sentence test fails. The author cannot complete "this will next run when ___" with an observable event. If the sentence cannot be finished, the artifact is not wired; it is merely present.
Fix prescriptions
| Finding class | Fix |
| Event mismatch | Reconcile the pair — fix whichever side is wrong — then add a conformance test asserting the declared event equals the wired event, so the two cannot drift apart again |
| Orphan | Wire it or delete it; nothing else is a resolution. Report the count against its denominator and mark which orphans predate this change — an orphan you did not create is repo backlog, not your remainder |
| Availability ≠ discoverability | Move what routing needs onto the router-visible surface (the description, the trigger list, the config), and place an advisory before the decision it informs, not after |
| Fresh-clone unreachable | Commit the artifact, commit its mode bit, replace absolute paths with repo-relative resolution, and verify from the index rather than from disk |
| Dead event | Re-point to a live event or retire the artifact; leaving it is a claim of coverage that does not exist |
| Unfinishable sentence | Write the trigger down explicitly in the artifact, then add a mechanical wiring check that runs on change, so the roster cannot silently drift back |
Bounds
- Scope: automation artifacts and the config that wires them, plus the version-control index. Not application source, not another installed plugin's artifacts.
- Cap: the census covers everything (it is a table); cap detailed findings at 15, dropped-payload and dead-event cases first.
- Done when every artifact has been paired with its wiring once. Orphans that predate this change are repo backlog, reported as a count.
- Quote once, at read time; mark anything you cannot re-confirm
UNVERIFIEDrather than re-reading to check yourself. - See
skills/opus-pocus/references/casting-safety.mdfor the full rules.
Report format
Per artifact: path · declared trigger · actual wiring · verdict — reached / dropped
(runs, but its output is discarded) / orphan (nothing invokes it) / unknown (could not
determine, which is not a pass). Then the census against its denominator: N artifacts examined,
M reached, and how many orphans predate this change versus were created by it. SCANNED NOTHING
if no automation layer was found — never "clean".
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

