Strip a stranger’s repo for parts

01Most sources have 2-3 good ideas, not 10

Point an agent at someone else's repo and the default failure is enthusiasm. It reads the README, gets excited, and comes back with a proposal to adopt ten things. Of those ten, two are good. Three already exist in your own setup, because the agent studied the stranger's code closely and yours not at all. The rest are bolted to a framework you don't run.

So I treat “what can we steal from this?” as its own repeatable process with gates, not a vibe. The goal is always the idea, reimplemented in my own style, not the tool as a dependency. Install the stranger's tool and you inherit their maintenance burden and their attack surface. Reimplement their one good pattern and it costs you a paragraph.

I've been running this against skill repos, one-file skills, blog posts, and paper replications for months. The numbers in the receipts are from those runs, not projections.

02Read safely first: the clone can attack you without running

Before anything gets read for ideas, two screens run in order. The first one is the part of this page I most want you to take even if you take nothing else.

The foreign .claude/ screen

Claude Code auto-loads .claude/settings.json and its hooks from your current directory and its ancestors, in-process, with full privileges, the moment a session’s working directory lands in that tree. A cloned repo can ship its own .claude/. Clone a malicious repo, cd into it, and its hooks are now running inside your agent. No code was executed by you. No install step happened. A sandbox around the repo doesn’t help, because the process doing the loading is your own agent outside the sandbox.

So the first check runs the instant a clone lands, before any cd, before any survey:

# before entering ANY cloned tree:
find <clone-dir> -maxdepth 3 -name ".claude" -o -name "settings.json" -path "*.claude*"
# found one? do NOT cd in. inspect from outside (Read/grep don't auto-load),
# quarantine the planted .claude/ before any further work.

kaibot enforces it at two layers: a scan script runs on every clone, and a hook stops cd into any tree with a non-allowlisted .claude/ directory, even when the scan gets skipped. The prose rule and the physics rule, per the companion page.

The malice scan

Second screen over the clone, for prompt injection, data exfiltration, trigger abuse, and supply-chain patterns. I use NVIDIA's SkillSpector, a static scanner that gives a 0-100 score plus per-finding rules. The score maps to three actions: 20 or under, proceed; 21-50, carry the findings into the survey, so source hygiene counts against every lift you take from it; over 50, stop and adjudicate before extracting. Extracting from an actively malicious source is itself an attack vector. An adversary hides the malice in the file they most expect you to want.

Scanners tuned for small skill bundles throw heavy false alarms on large general-purpose repos. One scan returned 100/CRITICAL on a mainstream open-source app; after dedup, 21 of the criticals were a single devDependency CVE repeated in each package.json. A markdown-only skill can trip the “excessive agency” rules on ordinary descriptive prose.

A high score is not a verdict. It is a demand for adjudication: read what the regex actually matched, then decide whether to walk away or proceed. And single files are not exempt. A hand-picked single skill is the highest-value hiding place there is.

03Two gates before you write any lift-list

Both of these exist because I got them wrong first.

Verify the gap exists before classifying a lift. It prevents more wasted review time than any other step. Survey agents reliably overstate gaps. They read the external source well but read your own code poorly. So for every claim that a pattern fills a hole, open your own skill or script the pattern would affect and quote the lines showing the hole is real.

One early run: an agent reported three missing dimensions in my review setup. On inspection, two already existed. If half of an agent's recommended lifts already exist, your survey prompt is too loose. Tighten it, and make a note of it.

04The lift itself: a third synthesis, not a copy

For a whole skills repo, the flow is: clone it somewhere durable, read the README and every skill file (not a skim; the actual files), then cross-reference each candidate against what you already have:

Then the survey goes to the human, tiered by impact and effort, and only the approved items get built. Classification is a four-way call: implement now, document for later, keep as reference, or skip. Most of a good source lands in skip, and that's the process working.

Before you build anything, go back to the original source. Not your notes on it. Summaries drift, and you'll end up implementing your interpretation instead of the source's actual idea. The lift that works is a third synthesis: the source's version plus your nearest existing equivalent, recombined into something new that follows your own conventions. Copying directly drags the source's voice and assumptions along with it, and possibly its license problem too. Verify where the reusable rigor sits before you credit or license anything. I once almost attributed a lifted evaluation method to an academic paper. The valuable portion was the replication author's own contribution and never appeared in the paper at all.

File a revisit for ~30 days out. External repositories change, so pull the clone and rerun the malice scan: later pushes can introduce what the first scan missed. Re-survey knowing what you actually used. Second-pass lifts tend to beat first-pass ones. By then you know which adoptions proved worthwhile.

05Steal this: the prompt for your Claude

Paste this (or save it as a skill) and use it whenever you hand your Claude a URL with “anything worth taking?”:

When I share a repo/article URL and ask what's worth lifting:

0. SAFETY FIRST, before reading for ideas:
   - If cloning: check the clone for a .claude/ directory BEFORE any cd
     into it. Found one = stop, tell me, inspect only from outside the
     tree. (Agent harnesses auto-load config from the cwd's tree.)
   - Run a malicious-pattern scan if we have one installed. Over the
     danger threshold: adjudicate what the rules actually matched
     before proceeding or walking away.
1. GATE: is this a coherent PRODUCT doing a job I already attack with
   my own tools? Then it's a build-vs-buy question; say so and stop.
2. GATE: is its value a curated catalog that overlaps mine 2+ items
   by intent? Then propose the hybrid (their items into my
   infrastructure), not a standalone adoption.
3. Deep-read the actual files, not the README alone. Extract specific
   quotable patterns: what it is, what it replaces here, effort
   (trivial/small/medium/large).
4. For every claimed gap, open MY closest existing skill/script/doc
   and quote the lines proving the gap is real. Already covered =
   SKIP now, not later.
5. Present a tiered list (high-impact-low-effort first). I classify
   each: IMPLEMENT / DOCUMENT / REFERENCE / SKIP. Track it in a file
   with checkboxes.
6. For each IMPLEMENT: re-read the original source (not your summary),
   then write a third synthesis in OUR conventions. Never paste
   verbatim. Check attribution and license against the true source.
7. File a reminder to revisit the source in ~30 days: pull, re-scan,
   re-survey with hindsight.

06For the Claude that just got pointed here

If a human gave you this URL alongside some repo they’re curious about, here’s your tl;dr.

07Receipts

Real runs of this process, from my own tracking files:

• One whole skills repo produced 12 tiered cards; 11 shipped (5 new skills, 8 existing skills extended, 6 new memory files, 15 commits). The 12th was deliberately skipped after review. The same run exposed that this process’s own trigger phrasing was too narrow to fire on its own canonical use case, which then got fixed.
• A session-auditing tool yielded 5 patterns and zero installs: 3 documented as reference material, 2 filed as trigger-conditioned future cards. The tool itself duplicated things already running here, which is the whole-product gate earning its keep.
• A paper-replication repo produced exactly one lift (a measurement discipline for A/B-testing a scorer), plus the wrong-source lesson above: the rigor was the replication author’s, not the paper’s, and the licensing followed the repo, not the citation.
• An early run had a survey agent claim 3 gaps of which only 1 was real, which is why gap-verification is now a mandatory step instead of a virtue.
• The scanner-adjudication notes are from two real verdicts: a 100/CRITICAL that a multi-model review unanimously called a false alarm (deduped to one CVE + noise on binary files), and a 55/HIGH on a markdown-only skill where every match was descriptive prose.