external-source-fitlisted

# External Source Fit Assessment Given a link to an external GitHub repo, file, or project, decide whether it fits this project and write the answer up as a finding. The recurring trap is answering from the name or the asker's framing ("it's a skill-eval tool, so it must be relevant") instead of from what the source actually does. Most sources are a partial or no fit; the value is in naming the one transferable idea precisely and in not re-opening the question later. This skill is **project-aware**: every verdict is rendered through the skill-quality-auditor lens, not in the abstract. ## Mindset - ALWAYS characterise what the source does before judging it; the name and the framing MUST NOT stand in for reading the code. - PREFER extracting a generic kernel; AVOID porting hardcoded, project-specific literals. - By default, most sources are a Partial or No fit. Treat Good fit as the exception you must justify, not the hope you start from. - Judge on need, not novelty. A clever technique is RECOMMENDED for adoption only when it closes a real gap this project has. - A rejection recorded once is cheaper than the same source re-assessed three times. The finding is the deliverable. ## When to use / When NOT to use Use this skill when someone links an external repo, file, or project and asks whether it fits, whether there is anything to learn from it, or whether the project needs it. When NOT to use: reviewing internal changes (use `review-changes`), scoring one of our own SKI