By theogbrand
Clone untrusted Python dependencies from GitHub, decompose them into verifiable sub-packages via test-driven evaluation, generate focused pytest unit tests, rewrite imports, and iteratively implement secure from-scratch replacements to mitigate supply chain attacks.
Evaluate whether a dependency should be kept or decomposed. Use during dependency decomposition (phase 3) to assess each library in the queue.
Implement or replace a dependency in the yoink package directory based on a decomposition evaluation. Use during dependency decomposition (phase 3) after evaluation.
Search reference test suite for tests relevant to a target function. Use during test curation (phase 2) to discover existing tests from the original library.
Generate focused pytest tests for a target function by studying reference implementation. Use during test curation (phase 2) after test discovery.
Phase 2: Generate and discover tests, validate against real library. Only invoke when explicitly requested by the user or by the yoink orchestrator.
Phase 3: Dependency decomposition. Only invoke when explicitly requested by the user or by the yoink orchestrator.
Scaffold project: clone repo, install real library. Only invoke when explicitly requested by the user or by the yoink orchestrator.
Curate tests then decompose dependencies
Uses power tools
Uses Bash, Write, or Edit tools
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
YOINK (You Only Implement Native Knowledge) is an AI agent that removes complex dependencies by reimplementing only what you need.
YOINK is currently built as a Claude Code plugin that decomposes third-party dependencies into internal replacements. Instead of importing a 50k-line SDK for three function calls, point yoink at the package, describe what you need, and it reimplements only the functionality you actually use, verified against the expectations of the original library's tests.
They say "don't reinvent the wheel" but what if you could?
AI agents are getting good enough to own code end-to-end, and with supply chain attacks accelerating, fewer dependencies means less attack surface.
Classical software engineering would have you believe that dependencies are good (we're building pyramids from bricks), but imo this has to be re-evaluated, and it's why I've been so growingly averse to them, preferring to use LLMs to "yoink" functionality when it's simple enough and possible. - Andrej Karpathy
OpenAI's harness engineering article echoed this: agents reason better from reimplemented functionality they have full visibility into, over opaque third-party libraries.
In some cases, it was cheaper to have the agent reimplement subsets of functionality than to work around opaque upstream behavior from public libraries. For example, rather than pulling in a generic p-limit-style package, we implemented our own map-with-concurrency helper: it’s tightly integrated with our OpenTelemetry instrumentation, has 100% test coverage, and behaves exactly the way our runtime expects. - Ryan Lopopolo (OpenAI)
We are making this capability accessible to anyone.
Add the yoink marketplace and install the plugin from within Claude Code:
/plugin marketplace add theogbrand/yoink
/plugin install yoink@yoink-marketplace
/reload-plugins
Navigate to any project and run /yoink:yoink:
/yoink:yoink "Replace usage of litellm with my own implementation" --url "https://github.com/BerriAI/litellm"
yoink runs three skills sequentially:
/yoink:setup clones the target repo and scaffolds a local replacement package./yoink:curate-tests studies the reference implementation and generates new tests, verified against the expectations of the original test suite./yoink:decompose determines dependencies to keep or decompose, based on a set of principles we defined, such as "keeping foundational primitives regardless of how narrow they are used".The /yoink:yoink command runs all three in sequence.
Curate tests from a target package, then decompose its dependencies into a local, dependency-free replacement. Runs in three phases: setup (Phase 1), test curation (Phase 2), and dependency decomposition (Phase 3).
Usage:
/yoink:yoink "<prompt>" --url "<github_url>" [--package "<package_name>"] [--skip-test-discoverer]
Options:
--url <github_url> - GitHub repository URL to clone and decompose (required)--package <package_name> - Override the package name (defaults to the repo name from the URL)--skip-test-discoverer - Skip the test discovery step (test generation still works without discovered tests)The individual phases of /yoink:yoink are also available as separate skills, useful if a run fails midway and you need to resume from a specific phase:
Scaffold the project: clone the target repo and install the real library for test validation.
Usage:
/yoink:setup --url "https://github.com/BerriAI/litellm"
Options:
--url <github_url> - GitHub repository URL to clone (required)--package <package_name> - Override the package name (defaults to the repo name from the URL)Phase 2: Generate and discover tests, then validate them against the real library. Requires /yoink:setup to have been run first.
Usage:
/yoink:curate-tests "I want to replace the usage of litellm in @sample.md with my own implementation" --package litellm
Options:
--package <package_name> - The target package name (required)Phase 3: Dependency decomposition. Seeds the queue with the target package and iteratively decomposes each dependency. Requires /yoink:curate-tests to have been completed first.
Usage:
/yoink:decompose --package litellm
Options:
--package <package_name> - The target package name (required)npx claudepluginhub theogbrand/yoink --plugin yoinkCheck dependencies for known vulnerabilities, outdated packages, and license compliance
Audit, update, and manage project dependencies with safety checks
Personal Claude Code + Codex dev stack: security hooks, AI-first code conventions, /security-review, /repo-map, /stack-check, portable statusline. Designed to complement other skills-based plugins, not replace them.
Codebase structural index — scan Python projects once, query the import graph for blast-radius and coupling before touching code — Python projects only
Audit supply-chain threat landscape of project dependencies for exploitation or takeover risk
Verification-first engineering toolkit for Claude Code. 15 skills across a 5-phase spine (Investigate → Design → Implement → Verify → Ship), 8 specialist agents, an interactive setup wizard. Every skill has rationalizations + evidence requirements. Built for senior ICs and tech leads.