Relay10 research
Skill minwoo19930301/relay10/plugins/relay10/skills/relay10-research
Gather current, read-only evidence about a repository, API, product, or ecosystem. Use before broad changes, comparisons, or claims that may have changed; do not use when the user already supplied sufficient stable evidence.From its SKILL.md
npx -y skills add minwoo19930301/relay10 --skill relay10-researchAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.9 KB, 337 tokens by cl100k_base, as published. Nobody here has run it
DisciplinedRun Research
Build a compact evidence ledger before analysis or implementation.
Workflow
- Write the exact questions that evidence must answer.
- Search local files first for repository behavior and current workspace state.
- For changing external facts, prefer first-party documentation, official repositories, releases, and APIs.
- Record retrieval date, URL or file path, and the specific claim each source supports.
- Cross-check high-impact or surprising claims with a second primary source when practical.
- Return facts, inferences, unknowns, and recommendations as separate sections.
Use the cheapest reliable read path. A metadata API or focused file search is preferable to a broad crawl when it answers the question.
Evidence contract
For each material claim include:
- claim;
- source and retrieval time;
- observed value or short paraphrase;
- confidence and any staleness risk;
- whether it is fact, inference, or proposal.
Popularity signals such as GitHub stars are discovery signals, not proof of quality, market share, or production usage.
Boundaries
- Remain read-only unless the user separately asks for changes.
- Do not quote or copy third-party prompts, scripts, or assets when a behavior-level summary is enough.
- Check file-level licenses before any reuse; treat unclear licensing as inspiration-only.
- Do not silently turn an archived or deprecated project into a current recommendation.
- Do not report a provider, app surface, or integration as supported without an end-to-end test.
Output
End with a short decision table: candidate, evidence, adopt, exclude, reason, and verification still needed.