Source-governed research link intake workflow. Use when asked to find papers,
repos, datasets, docs, standards, benchmarks, source surfaces, or trusted
links; collect research links; search literature; update a research base; run
research intake; produce links.md; or prepare auditable JSONL evidence. The
skill asks for a topic ID when missing, creates or reviews topic configs with
user approval, discovers trusted source roots, writes URL-bearing query files,
runs fetch/dedupe/check/finalize, and produces links.md plus run-local
accepted.jsonl evidence. It does not write reports or syntheses.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Source-governed research link intake workflow. Use when asked to find papers,
repos, datasets, docs, standards, benchmarks, source surfaces, or trusted
links; collect research links; search literature; update a research base; run
research intake; produce links.md; or prepare auditable JSONL evidence. The
skill asks for a topic ID when missing, creates or reviews topic configs with
user approval, discovers trusted source roots, writes URL-bearing query files,
runs fetch/dedupe/check/finalize, and produces links.md plus run-local
accepted.jsonl evidence. It does not write reports or syntheses.
["find papers for","search literature","collect links","research intake","intake research","update research base"]
Research Intake Skill
Research Intake is not a report writer. It is the intake layer that creates a
small, auditable, topic-scoped set of accepted links. The CLI is the deterministic
I/O layer. The model is responsible for topic judgment, source trust, query
planning, semantic filtering, and concise user gates.
If the command is not installed and the current working directory is the project
checkout, use:
RI_CMD="uv run research-intake"
Respect an explicit user-provided root. If the user gives no root, use
RESEARCH_INTAKE_ROOT when set, otherwise .research-intake in the current
working directory.
Before a non-trivial run, check the command and root shape:
$RI_CMD doctor --root "$RI_ROOT"
If doctor fails because the root does not exist, initialize only when the user
has asked to start or update an intake base:
$RI_CMD init --root "$RI_ROOT"
Artifact Contract
Root layout:
<root>/
initial_sources.jsonl
topics/<topic-id>/
config.yaml
sources.jsonl
progress.md
captures/links.md
tasks/
runs/<run-id>/
expanded_queries.jsonl
raw_results.jsonl
candidates.jsonl
rejected.jsonl optional, model-written
categories.json optional, model-written
keep.json model-written before finalize
accepted.jsonl written by finalize
The following schema blocks are illustrative only. They show required shape and
field meaning, not fixed values. Always generate topic IDs, labels, ideas,
keywords, source IDs, URLs, resource titles, and dates from the user's actual
topic and verified sources.
source_id is a short stable slug, preferably lowercase with underscores.
url is a trusted root, collection, docs home, org page, index, or source
surface.
A specific result page is not a source. It belongs in expanded_queries.jsonl
as a URL to fetch.
Sources with missing status are active. Sources with status other than
active are not fetched.
Keep sources.jsonl compact: one current row per source_id. Replace a row
when updating it, keeping duplicate source events out of the file.
Resource record schema used in raw_results.jsonl, candidates.jsonl, and
accepted.jsonl:
{"resource_id":"url:<hash16>","source":"<source_slug>","title":"<verified resource title>","summary":"Short metadata description if available.","link":"https://<verified-result-url>","domain":"<verified-domain>","year":0,"query":"https://<verified-result-url>","fetched_at":"<UTC timestamp>"}
Decision Gates
Ask the user only at real gates. Batch choices into one question.
Mandatory gates:
Topic ID when missing.
Scope for a new topic.
Approval before changing config.yaml.
Approval before adding or changing source records.
Hard-cap recovery when more than 256 candidates remain.
Candidate group keep/reject/inspect decision.
If an AskUserQuestion tool is unavailable, ask one concise chat question and
wait. Use group-level questions unless the user explicitly requests
candidate-by-candidate review.
After a gate is answered, continue the workflow. Source discovery and config
review are not final deliverables.
Phase 0 - Understand The Request
Classify the user's request:
New intake: collect links for a topic that is not yet configured.
Existing intake: update or rerun a known topic.
Source maintenance: add, remove, or clean source roots.
Review-only: inspect existing candidates or links without running fetch.
If the user asks for a literature review, synthesis, report, or summary, explain
that this skill only performs link intake. Offer to produce links.md first.
Choose a run ID when one is not provided:
YYYY-MM-DD-<topic-id>-v1
If that directory exists, increment the suffix: v2, v3, and so on. Preserve
existing run directories.
Phase 1 - Topic Gate
If no topic ID is explicit, stop and ask:
Which topic ID should I use? Use a short stable slug, for example `<topic-id>`.
Ask for the topic ID instead of inferring it from nearby files or previous
context.
Check whether the topic exists:
test -f "$RI_ROOT/topics/<topic-id>/config.yaml"
New Topic
If the topic does not exist:
Ask for the scope if the user has not supplied it.
Draft a richer config update with label, description, include,
exclude, and budget.
Show the proposed config or a compact before/after diff.
Ask one approval question:
Apply this topic config? Options: apply, edit first, leave default.
Write config.yaml only after approval.
Continue to source discovery.
Existing Topic
For an existing topic, read:
topics/<topic-id>/config.yaml
topics/<topic-id>/sources.jsonl
topics/<topic-id>/progress.md if present
topics/<topic-id>/captures/links.md if present
Run:
$RI_CMD plan --root "$RI_ROOT" --topic <topic-id>
Review the config. The authority order is:
description > include idea > include keywords > include objects > exclude keywords
If the config is vague, contradictory, too broad, or missing exclusions, propose
specific edits and wait for approval before writing them.
Good config review output is concrete:
I would change:
1. Add include idea "<missing in-scope concept>" because the description explicitly mentions it.
2. Add exclude idea "<out-of-scope result type>" because those pages are not reusable source-governed evidence.
3. Reduce max_results_per_query from <old value> to <new value> to keep review under the cap.
Then ask one approval question for the whole set.
Phase 2 - Source Discovery And Maintenance
This phase is mandatory before fetch unless the user explicitly says to use the
existing sources only.
Goal: identify trusted source roots and concrete result URLs. Keep those two
concepts separate.
Examples:
Good source root: https://<trusted-domain>/<collection-root>/
Good result URL: https://<trusted-domain>/<specific-result-path>
Bad source root: https://<trusted-domain>/<specific-result-path>
Use web search from the topic config. Build 3-8 probes from:
Topic description.
Include ideas.
Include keywords.
Known official organizations, libraries, standards, datasets, or benchmarks.
Exclude ideas, to avoid ambiguous wording.
Probe patterns:
<core idea> official docs
<core idea> <code or artifact host>
<core idea> dataset
<core idea> benchmark
<core idea> standard
<core idea> <topic-specific artifact type>
site:<known-source-domain> <core idea>
site:<candidate-domain> <core idea>
For each promising result, record:
Source root URL.
Concrete result URLs worth fetching.
Why the source is trusted.
Whether it should be active now or only remembered as candidate.
Keep one row per source ID. Preserve unrelated source rows. If changing a URL or
status, replace that source's row.
If no useful new sources are found, say so in one sentence and continue with the
existing active sources.
Phase 3 - Query Planning
The fetcher is generic URL metadata fetch. It does not perform general web
search. Therefore query lines should usually contain verified concrete URLs on
the source domain.
For each active source:
Use the discovered result URLs from Phase 2.
Use links already present in links.md only to avoid duplicates, not to
refetch them as new candidates.
Use WebSearch/WebFetch to find additional concrete URLs if the source root is
too broad.
Respect budget.max_queries_per_source.
Set budget_max_results to budget.max_results_per_query.
Write runs/<run-id>/expanded_queries.jsonl with one JSON object per line:
Multiple URLs may be placed in a query string when they belong to the same
source domain, but keep lines readable. Prefer one URL per line when review
clarity matters.
Avoid empty or purely conceptual query lines such as:
With the generic fetcher, that line does not search the web or the source site.
It will not produce useful results unless the query includes concrete verified
URLs on the source domain.
Which groups should I accept for finalization?
Options:
- Accept all listed groups
- Accept only the group numbers I enter
- Reject the group numbers I enter
- Show details for group numbers I enter
Use those exact option labels when AskUserQuestion supports selectable options.
For the three number-based options, tell the user to enter group numbers in the
freeform field, for example 1, 3, 5.
If the user chooses Accept all listed groups, proceed to keep.json without
follow-up.
If the user chooses Show details for group numbers I enter, show only those
groups. For each inspected group, include:
Resource number.
Title.
Year or -.
Source.
Link.
One-line reason to keep or reject.
Then ask one follow-up for the inspected set. Keep review at group level unless
the user requests candidate-by-candidate review.
Phase 7 - Write keep.json
Write final accepted IDs to:
runs/<run-id>/keep.json
Shape:
{"keep":["url:<hash16>","title:<hash16>"]}
Use resource_id values from candidates.jsonl. URL strings are accepted by
the CLI as keep keys, but resource_id is preferred.
If all candidates are accepted, still write keep.json; it documents the review
decision and makes finalization explicit.
