# Turn a GitHub trend into a useful test

Filter tools against your work, verify sources and define a small experiment before installing.

## 1. Start with your work

A tool matters when you can name the task it could improve. Write that task before opening the radar. Our Hermes Workspace collects GitHub signals and adds editorial scores. That is our own workflow, not a feature automatically present in every Hermes installation.

Write: I want to improve task X, measured by result Y.

## 2. Keep the observation

Record repository URL, date and observed signal. Daily, weekly and monthly lists use different windows. Scores and stars help shortlist candidates; they do not prove quality, safety or usefulness. Record missing metadata. An empty scraped licence field does not mean there is no licence.

Fill the first half of the tool card and separate observation from interpretation.

## 3. Read the primary source

Open the README, documentation and relevant release information. Check whether the project offers the capability you need. This batch researches Chrome DevTools MCP for browser tests and ai-memory for memory handoff. Radar inclusion starts the investigation; the primary source determines which claims you can make.

Write one supported capability, one limitation and its source URL.

## 4. Review before installing

Record the exact version. Inspect source code, dependencies, installation hooks, network destinations and secret access. Our policy includes a SkillSpector scan; a scan does not replace source review. Downloading and installing are separate steps. You can finish the test plan before running the project on your work machine.

Choose reject, investigate or controlled test. Record the reason and unresolved questions.

## 5. Let the experiment decide

Test one bounded task with the same input as your current approach. Define the required improvement and unacceptable failure beforehand. Record results and repair work. For content, keep the demonstration and claim source with the brief. A test showing no improvement is useful too: it prevents an unnecessary installation.

Done when the decision can be traced from task to source, review, test and conclusion.

## Starter template

Review this public repository read-only for my task. Read primary sources. Produce a tool card with URL, access date, supported capability, limitation, licence source, installation questions and a small comparative experiment. Separate observations from assumptions. Download and install nothing. State what remains unverified.


# Radar → trial decision
My task: [existing problem]
Repository URL: [primary source]
Observed on: [date and radar period]
Documented function: [from the documentation]
Personally observed: [only what you actually reviewed or tested]
Uncertain: [limitations and dependencies]

Trial: [one input → one expected output]
Failure case: [how should it stop or report?]
Stop condition: [when is it not useful?]
Installation required? [yes/no]
If yes: record exact version/commit and scan + source review before execution.
Result: [evidence]
Decision: [test / park / reject + reason]
Content claim: [what does this evidence support?]