triage-tool

Triage Tool

Add a new tool or library to the research repo as a structured reference summary.

When to Use

• User provides a GitHub URL, npm/PyPI package name, or tool name
• User says "triage this tool", "add this tool", "analyse this tool/library"
• Evaluating whether a tool belongs in the repo

When Not to Use

• The tool has already been triaged (check REVIEWED.md first)
• The tool is clearly out of scope (not relevant to the research domain)
• User wants a full deep-dive analysis — use triage-tool first, then promote to ANALYSIS-<name>.md

Mindset

Triage is a quality gate, not a catalogue entry. The goal is a reproducible, honest assessment.

1. Scope before summary: confirm the tool is relevant to the research domain before investing in a full write-up. A well-reasoned out-of-scope ruling is as valuable as a full summary.
2. Evidence first: quote README and docs; never infer capabilities not described by the author.
3. Triage-then-promote: every tool enters via REVIEWED.md; promotion to ANALYSIS-*.md and vendoring both require explicit user confirmation — never automatic.

Workflow

1. Resolve the source

• Fetch the repo README and any linked docs/architecture pages.
• Record: tool name, author/org, license, language, latest version/commit, primary URL.
• Derive a stable slug: always <author-or-org>-<tool-name> — no exceptions (e.g. versatly-clawvault, press-longchat, rtk-ai-rtk, safishamsi-graphify).

2. Check for duplicates

• Search REVIEWED.md and references/REFERENCE_INDEX.md for the slug or repo URL.
• If already present, report it and stop.

3. Classify the tool

Assign one or more tags from the controlled list. See classification guide for the full taxonomy and scope assessment criteria.

4. Assess scope fit

Confirm the tool is relevant to the research domain. See classification guide for in-scope / borderline / out-of-scope criteria. Note any borderline ruling in REVIEWED.md.