resolver-query
Skill50 starsChanged 7 months agoMITView on GitHub
Use when an operator asks which rule or policy governs a question — pricing exceptions, deploys, refunds, hiring — or wants to look up the matching rule in Meta/RESOLVER.md without reading the whole index by hand. Triggers: /resolver-query <question>, "which rule applies", "what''s our policy on X", "does a rule cover this". Not for writing or editing rules (read-only) and not for rebuilding RESOLVER.md (use resolver-build.py).
In this repository39 other files it gives its agents.
- docs/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- setup-brainSkill
- backfill-journal-body-contextSkill
- cierre-de-llamadaSkill
- coachingSkill
- coachSkill
- daily-journalSkill
- deconstructSkill
- diagnoseSkill
- doubt-driven-developmentSkill
- evolveSkill
- for-my-teamSkill
- graphifySkill
- health-contextSkill
- health-doctorSkill
- health-setupSkill
- ingest-githubSkill
- ingest-healthSkill
- ingest-youtubeSkill
- insightsSkill
- instinct-exportSkill
- instinct-importSkill
- interview-meSkill
- longitudinalSkill
- meeting-todosSkill
- nano-bananaSkill
- note-todosSkill
- optimize-brainSkill
- patternsSkill
- repurpose-talkSkill
- riseSkill
- second-brain-mappingSkill
- secret-warnSkill
- security-snapshotSkill
- setup-vault-typesSkill
- skillify-meta-loopSkill
- sunday-reviewSkill
- vault-systemSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 101
When match_kind == none, the skill returns the empty matched_rules list and the host session tells the operator no rule matches.
≈ “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
/resolver-query
Look up which rule in Meta/RESOLVER.md applies to a natural-language question. The skill itself does NOT call an LLM. It reads RESOLVER.md, parses every rule row, and returns either a decisive match, a ranked candidate list, or "no rule matches." The host Claude session does the natural-language understanding on top of the structured output.
When to run
- An operator wonders which rule governs a recurring question (pricing, deploy, refund, hiring exception).
- A new teammate wants to find the policy for a scenario without reading the full resolver index.
- Any time the resolver layer should answer a query and the operator wants the structured candidate set in one call.
How it works
- The skill reads
Meta/RESOLVER.mdfrom the vault root. - It parses the YAML frontmatter for the build timestamp and counts.
- It parses every row of the
## Rulestable into a structured record. - It runs a deterministic match against the question:
a. Tokenize the question (lowercase, drop stopwords, keep stems).
b. For each rule, score by token overlap against
rule_id, source path, skill link, and source-file H1/topic when available. c. If exactly one rule scores >= the decisive threshold, return that rule directly. d. Otherwise return up to--limitrules ranked by score. e. If no rule scores above zero, returnno rule matches this query. - The host session then reads the structured output and frames the answer to the operator.
Step 1: Run the skill
python3 skills/resolver-query/query.py "How do we handle pricing exceptions?" \
--vault-root <vault>Output is a JSON document on stdout with shape:
{
"question": "...",
"vault_root": "...",
"resolver_built_at": "...",
"rule_count": 17,
"match_kind": "decisive | ranked | none",
"matched_rules": [
{
"rule_id": "...",
"type": "decision | workflow | exception | fact",
"status": "active | stale | superseded | under-review | unknown",
"last_verified": "...",
"source_path": "...",
"skill_link": "...",
"score": 0.0
}
],
"summary": "..."
}Step 2: Read the matched rule
If the match kind is decisive, the host session opens the rule's source file (source_path). If ranked, the host session presents the top candidates to the operator and lets them pick. If none, the host session tells the operator no rule applies and offers to draft one manually.
Rules
- The skill is read-only. It NEVER writes to
RESOLVER.mdor any source file. - The skill makes no external network calls. No LLM API is invoked from inside
query.py. - The matching algorithm is deterministic and stdlib-only. The host Claude session is the natural-language layer on top.
- When
match_kind == none, the skill returns the emptymatched_ruleslist and the host session tells the operator no rule matches; it does not invent one.
Boundary
- Adjacent skills:
scripts/resolver-build.pyrebuildsRESOLVER.md.scripts/resolver-conflict-report.pysurfaces conflicts in JSON.scripts/resolver-branch-merge-prompt.pydrafts merge prompts.
- This skill READS the rendered index. It does not refresh, edit, or rewrite it.
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.

