Hr Research Shared Links

---
name: hr-research-shared-links
description: "Research a shared link or repo in depth, compare it with the user's setup and rate each idea. Use when a session opens with a link or asks for thoughts or what to borrow. Not for factual lookups, and not for implementing or fixing things the link describes."
---

# Research shared links

A shared link asks "is this worth anything to us?", not "what does it say?".
The failure to avoid is a first answer built from the page that was shared,
so the user has to ask again to "look closer", "compare it to ours" or "find
the hidden gems". Do that work the first time.

## Before reading

1. If the link looks unrelated to the session's work or carries stray
   characters, say what you think it is and confirm before a long analysis.
2. For several links, give each its own verdict and add one synthesis.
3. Tell the user in one line what you will do: read the primary source, compare
   with their setup, rate each idea.

## Read the source, not the pointer

1. Use the reader for the site when one is available (X posts, Reddit threads);
   generic fetch truncates them.
2. Follow an article, post or video to what it is about: the repository, paper,
   docs or data. The shared page is a claim; the source is the evidence.
3. For a repository, read past the README: agent guidance files, skills, docs,
   tests and the code behind any headline feature. These hold the transferable
   ideas. Search its open issues and security disclosures for the shared claim
   and for each idea you may recommend, check every hit against the current
   code, and read the latest release notes. Record the terms you searched. The
   README says what the maintainer wants to be true; the tracker shows what
   users and reviewers found, and a fix may already have landed.
4. Say what you did not read: videos, images, earlier posts in a thread,
   private or login-gated pages, source behind a README claim. Do not rate what
   you did not see.
5. Check headline claims against the project's own data. Recompute a cost or
   speed figure, compare the README with the results file, and name each claim
   that has no evidence behind it.
6. A license does not stop you borrowing an idea. If it bars an AI from reading
   the material, flag that and offer another reader.

## Compare with what the user has

1. Search their rules, skills, docs and settings for the same idea before judging
   it. "We lack this" needs a search showing the gap; "we have this" needs the
   path.
2. Search the earlier sessions and decisions you can reach for standing
   constraints and options already rejected. Name any records you could not
   reach, and do not read their absence as "never decided". Do not recommend
   what was ruled out without saying so and saying what changed.
3. State exactly what the comparison ran against: which fork or version of ours,
   which release of theirs, the competitor's real name.

## Rate each idea

Give each idea one row: source path, the technique in one to three lines, what it
would change here and what that is worth (faster, cheaper, safer, clearer),
the evidence on both sides (their file and line, our search), and a verdict.

- **Adopt**: clear gain, fits a stated need, small to carry.
- **Consider**: real idea, unproven here or costly. Say what would settle it.
- **Skip**: already covered, ruled out, or tied to the vendor's model or product.

Separate the idea that transfers from the vendor and model details around it.
Weigh build against buy against borrow: a maintained tool that is good enough
beats building, and an idea is often worth taking without the tool. List the
ideas you dropped and why, so the recommended set and the table agree.

## Route what is worth keeping

1. Name the layer that owns each kept idea: shared portable rules, host or
   machine setup, one project, or a portfolio-level record. Use the user's own
   ownership map when they have one.
2. A deferred idea gets the condition that reopens it and a proposed home in
   the owning repository; offer to save it there rather than leaving it only in
   this reply.
3. If an idea means adopting something vendored, offer to record where it came
   from so upstream changes are noticed. If evaluating it exposed an upstream
   bug, offer to file it.
4. Wording adopted into rules describes behavior and carries no "borrowed from"
   history. Provenance belongs in the research record.

## Answer

1. Lead with a table, one row per link or repository: what it is, its status in
   the user's setup (have, partly, missing, ruled out) with the evidence, and the
   verdict.
2. Then the ranked ideas, then what is not worth borrowing and why.
3. Explain jargon in plain words or a small diagram. Before changing anything
   from this research, show the exact before and after wording or real sample
   output.
4. End with offers under the user's offer rules. Candidates: write a research
   note; test it against what they use on quality, speed or cost (give the
   expected wall-clock time and check host load first); get independent opinions
   from other models or a review panel, with a brief that includes your findings
   and the candidates you rejected, choosing the reviewers yourself; build or
   adopt one idea, saying which steps that option includes (file changes,
   installing the tool, a pull request, landing) and which it leaves for a later
   offer; stop here.

"Tell me more" and "thoughts?" authorize research and nothing else. Changing
files, installing the tool or opening a pull request needs the user's selection.