yoinker.

An evidence-first Agent Skill

Understand it.
Yoink what transfers.

Give your agent a repository, paper, product, technique, or open question. Get back what it actually does, what the evidence supports, and what—if anything—fits your situation.

Install Yoinker View the source
One skill · no service Codex + Claude Code MIT licensed v0.1.0 · release notes

A worked example

A useful mechanism without a wholesale yes.

This compact example uses a real public artifact and a hypothetical local situation. It demonstrates Yoinker’s decision shape; it is not a claim that this adoption happened or improved an outcome.

Input
Situation
A TypeScript monorepo already using ESLint, with package boundaries drifting.
Would this help us? We want the smallest useful addition, not another architecture platform.
Yoinker’s answer

Bottom line

Yes—for executable dependency boundaries in CI. No—as a new source of architectural truth. Start with one rule tied to a failure you already care about.

Borrow

The rule contract: named from/to constraints, comments that preserve intent, and error severity that can fail a build.

Try

Add one package-boundary rule against a known regression fixture. Compare signal and maintenance cost with the current lint-only baseline.

Track

Resolution accuracy and runtime on the full monorepo. Expand only if the bounded rule survives real aliases, generated code, and CI timing.

Reject

Starting with diagrams or treating the dependency graph as the canonical architecture model. Neither addresses the named regression first.

Evidence checked · 2026-08-30 mechanism rule semantics

Install

Two commands. Then ask normally.

Install from the Lyra Forge marketplace and start a new session so your harness loads the skill. There is no service, account, API key, or package dependency.

Codex

Install the plugin

codex plugin marketplace add lyra-forge/marketplace
codex plugin add yoinker@lyra-forge

Invoke it as $yoinker:yoinker

Claude Code

Install the plugin

/plugin marketplace add lyra-forge/marketplace
/plugin install yoinker@lyra-forge

Invoke it as /yoinker:yoinker

Prefer to inspect before installing? Read the entire skill or browse the repository .

How it works

One method, two ways in.

01

Assess this

“Here is a repository, paper, product, or practice. Does it help this situation, and how should we think about adoption?”

02

Explain this

“What does this actually do? How do these approaches differ? What does the evidence support, and what remains uncertain?”

  1. 01

    Ground

    Follow discovery links to original artifacts. Inspect the named local context before claiming fit.

  2. 02

    Separate

    Keep observation, source claims, inference, unknowns, recommendations, and outcomes from blurring together.

  3. 03

    Decide

    Judge each mechanism as borrow, try, track, or reject. Name the evidence and what would reverse the call.

Good first prompts

Bring the question you already have.

Release status

Useful now. Honest about what is not proven.

Version 0.1.0 is the initial MIT-licensed release. Repository checks, both plugin manifests, marketplace installation, and the public deployment are verified.

The held-out behavior comparison is still planned. Availability and a polished example are not presented as evidence that the skill improves outcomes.

Read the evaluation contract