source-command-candidate-screening

Use this skill when the user asks to run the migrated source command candidate-screening.

Command Template

CryptoGlossario — Candidate Screening

This command reviews pdfTermCandidates in pending_review and decides whether each candidate deserves an autonomous glossary entry.

• Accepted: a draft term (isApproved: false) is created inline with the

canonical lemma + slug. The candidate moves to approved and linkedTermId is set. The draft enters the same enrichment flow as existing terms.

• Rejected: the candidate moves to rejected and will not be suggested again

by future PDF analyses.

Pipeline, ownership and versioning rules live in lib/skill-registry.ts.

Autonomy gate (hard requirement)

A candidate is accepted only if web research establishes it exists as an autonomous technical term — not as a casual combination of technical words. Follow AGENTS.md "Web research standard"; for admission the standard is generous (see its positioning note).

Admission is generous on purpose: CryptoGlossario admits emerging terms before Treccani. Domain-native sources from fast-moving sites count toward the gate — Binance Academy, CoinMarketCap, project documentation, reliable crypto or tech media. Only pure promotional material (a project marketing its own coin) is excluded. What you are testing is autonomy of the term, not the prestige of the outlet.

Programmatic gate: the apply script rejects accepted entries with fewer than 2 valid URL sources.

Review questions

Ask these before accepting:

• Is this a recognized technical term, not a generic word?
• Is it used outside the source PDF in authoritative sources or technical documentation?
• Does it have stable meaning in crypto, AI, blockchain, fintech, economics, cryptography, computer science, videogames, or technical slang?
• Is it at the same granularity level as existing glossary terms?
• Is it an autonomous entry, not just a variant, trivial abbreviation, or sentence fragment?
• If it is an acronym, does it identify a real concept rather than a local document label?
• If it is a compound, is it a recurring technical expression rather than an occasional word pairing?
• Would the entry help an Italian reader understand the domain?
• Do existing glossary terms already cover the same concept?
• If rejected, is the reason clear enough that the candidate should not be suggested again?

Decision rule

Accept only when the candidate is both useful and stable. Reject when it is too generic, too local to one document, already covered by another entry, or not technical enough for the glossary.

Homonyms vs polysemy — one entry or two?

When the term carries more than one meaning, decide here whether to create one entry or several, before any draft exists:

• Unrelated meanings tied to different disciplines (true homonyms) → separate

entries, one per sense. Title and slug are disambiguated downstream by the Uniqueness rule in title-normalization (e.g. Benchmark [AI] / Benchmark [Computing]).

• One core concept applied across sub-areas (polysemy) → a single entry; the

distinct uses are laid out in definitionInDepth by content-definition (e.g. Renderer: 3D/engines, web framework, generic output).

• A sense already fully covered by an existing entry → reject as duplicate;

if the entry merely lacks that nuance, it is an enrichment of the existing term, not a new candidate.

Granularity test: if the senses share the same opening ("what the thing is"), keep one entry; if each needs a different opening statement, split.

Batch format

``json [ { "id": "pdfCandidateId", "accepted": true, "title": "Reasoning Effort", "slug": "reasoning-effort", "reason": "Termine tecnico riconosciuto nel dominio ...", "sources": ["https://...", "https://..."], "notes": "Eventuali note brevi" }, { "id": "pdfCandidateId", "accepted": false, "reason": "Generic term, not autonomous in domain literature." } ] ``

For accepted entries: title (lemma canonico) and slug (kebab-case) are required. The slug must be unique across all terms (drafts included).

Apply

Dry-run first:

``bash bun scripts/pdf-candidates/apply-candidate-screening-batch.ts /tmp/cg_candidate_screening_batch.json ``

Apply after review:

``bash bun scripts/pdf-candidates/apply-candidate-screening-batch.ts /tmp/cg_candidate_screening_batch.json --apply ``

After acceptance

The new draft term enters the standard enrichment flow. Run the apply-<skill>-batch.ts scripts (same code path used to refresh existing terms) until the admission gate and all enrichment skills are validated, then publish. This includes enrichment skills whose requiredForNewTerm flag is false, and future enrichment skills added to lib/skill-registry.ts:

``bash bun run publish:drafts # dry-run, lists publishable drafts bun run publish:drafts -- --apply # flips isApproved: false -> true ``