Skip to content
Back to skills

Matching References

ASecurity

Identifies sources in the corpus that match a query topic, situation, or concept. Returns a list with one-line justifications for each candidate, with paths to the relevant distillations.

  • 7 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 29, 2026
ai-agents

Security analysis

A100/100

Scanned October 5, 2026

npx -y skills add chrisgagne/grounded-forge --skill matching-references --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Matching References?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Matching References
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/chrisgagne-matching-references/badge)](https://www.skillsdirectory.com/skills/chrisgagne-matching-references)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: matching-references
description: Identifies sources in the corpus that match a query topic, situation, or concept. Returns a list with one-line justifications for each candidate, with paths to the relevant distillations.
argument-hint: "[query string or topic]"
---

# Matching References

Identifies which sources in the corpus address a given query topic, situation, or concept. The skill returns a list of candidate sources with one-line justifications, naming the distillation(s) that project each source onto the task axes the app ships.

Distillations are the source-grounded product. The reference tier (light + deep) lives at corpus level as the audit-of-record but does not travel with the compiled app, so this skill returns distillation paths rather than reference paths.

**Path convention.** Every path in this skill is written from the app's perspective: `./distillations/{task}/{slug}-{task}.md`, `./concept-index.json`, `./slug-table.json`. The distillations directory and the runtime JSON indexes sit at the app root.

## Retrieval order

1. **Runtime listener tables in the distillation index for the task at hand** (the `… — listener` sections of `./distillations/{task}/task-index.json`, one per phase; the `{TASK}-DISTILLATION-INDEX.md` is the operator view of the same tables). In a split index (`schema_version` 2) a listener section lists each trigger with its `[D#]` pointers and names a `shard` file holding the full trigger→response rows: match the trigger in the main file, then load only that shard. Check first when the query carries observable triggers: an utterance, a dynamic, a signal the practitioner noticed in the room ("the team keeps saying X", "we're stuck on Y", "someone keeps doing Z"). Skip this step on task axes whose spec carries no field-2a seed table.
2. **Phase-routing tables in the task-axis index** (`./distillations/{task}/task-index.json`, `rows` field). Use when the query is at the level of a phase or situation type ("we're in the contributing-factor-analysis phase", "this is a stakeholder-management question") rather than an observable trigger.
3. **Concept axis** (`./concept-index.json`) for topic- and concept-shaped queries. A schema-3 index opens with a topics block, the subjects the library covers with their synonyms: pick the topics the query touches and fetch their rows by topic ID, as `answer-from-corpus` sets out under *Reading the concept index*. On schema 2, each row is a concept with its aliases and the sources that cover it.
4. **Slug-table scan** (`./slug-table.json`) for named-source / author / title lookups when the user names a specific work or author. Resolve the slug-ID to distillation paths via `./distillations/{task}/{slug}-{task}.md` for each task the app ships.
5. **No-coverage is honest**: if none of the above surfaces a match, say so plainly rather than fabricate from training.

## Procedure

1. Read `./slug-table.json`, and the concept index the way its schema needs: the topics block on schema 3, the whole file on schema 2.
2. Match the query against the concept index first for concept-shaped queries (topic names and synonyms, then the rows under the matching topics; on schema 2, concept names and aliases); against `slug-table.json`'s slugs for source-shaped queries (author/title strings often appear in the slug itself).
3. For each matched slug, find the distillation files that project it onto the task axes this app ships (look under `./distillations/`).
4. Return the matches as a list with paths to the corresponding distillation files, in relevance order.

## Inputs

- A query: topic, concept, or situation in plain language.

## Outputs

- A list of candidate sources. For each:
  - Author / topic slug
  - Path(s) to the distillation(s) for the task axes the app ships
  - One-line justification (why this source matches the query)

## When to use

- The user asks "is there a source in this corpus on X?"
- The user describes a situation and wants the assistant to identify which sources apply.

## When not to use

- The user has already named the source and the task. Read the distillation directly; do not run a search to find what is already named.
- The user has named a phase of a task. Use the distillation index's phase-routing tables for that task instead. The distillation index is the situation-to-resource router; this skill is the topic-to-resource router.
- The user describes an observable trigger from the room (an utterance, a dynamic, an energy signal: "the team keeps saying X", "we're stuck arguing about Y"). Use the distillation index's runtime listener tables for the task at hand. The listener table is the moment-to-framework router and ships in any application whose task spec carries a field-2a seed table.

## Related skills

- `answer-from-corpus`: the default source-grounded retrieval skill.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.