c4605's blog

I Made a Skill That Converts MCP to Skill

2026-01-23T00:00:00Z

I recently made a skill that converts MCP servers into Claude Code skills. Sounds a bit meta, but it's actually quite useful.

Why Convert?

MCP itself is great. It provides a unified, discoverable interaction protocol, and the adoption rate is impressive. RESTful APIs are supported by many providers, sure, but they're too loosely constrained—honestly, "discoverability" is something many big companies (especially quite a few Chinese tech giants) do terribly. GraphQL, gRPC and the like have limited adoption and are quite fragmented. MCP solves a lot of these problems.

But it still has some issues.

Context Window Consumption Is Too Heavy

MCP works by dumping all tool definitions into the context at once. If you've connected several MCP servers, each with a bunch of tools, the tool definitions alone take up a huge chunk of your context window. For example, I just checked—the GitHub MCP takes up 10k tokens (5%) of my context.

Claude Code skills have a mechanism called progressive disclosure: the AI first sees a brief description, and only loads the full content when it actually needs to use that skill. This way the context window doesn't get stuffed with tool definitions that might never be used.

Although this skill currently can't convert MCP services that require OAuth (technically it's doable, just a bit more work—I'm considering adding it when I have time...), at least every bit of context saved counts...

AI Tool Calling Is Too Inefficient

This is the main reason I wanted to build this converter.

The traditional approach has the AI call tools one by one: call A, get the result, call B, call C... Each call goes through an "AI decides → make call → get result → AI decides again" loop.

The problem is this process is unreliable. The AI might skip a step, might suddenly go off the rails mid-way, and each call result has to be stuffed into the context, making token consumption skyrocket. It might even fail because the response is too long, forcing the AI to figure out how to paginate through the content.

A better approach is to have the AI write a script that completes all calls at once (or preprocesses the responses). Code control flow is much more reliable than AI "chain of thought", and Anthropic is officially researching this direction—they published an article called Code execution with MCP, showing token consumption dropping from 150k to 2k, a 98.7% reduction.

The skill I made generates an api.mjs that the AI can directly import and use for scripting:

import { callTool } from '/<mcp-skill-path>/scripts/api.mjs';

// Search issues across multiple repos in parallel
const repos = ['facebook/react', 'vuejs/vue', 'sveltejs/svelte'];
const results = await Promise.all(
  repos.map(repo => callTool('search_issues', {
    repo,
    query: 'memory leak'
  }))
);

// Summarize results, return only needed fields
const summary = results.flatMap((r, i) =>
  r.content[0].text.items?.slice(0, 3).map(issue => ({
    repo: repos[i],
    title: issue.title,
    url: issue.html_url
  })) ?? []
);

console.log(JSON.stringify(summary, null, 2));

With traditional tool calling, the AI would need to call search_issues 3 times, with each call's full result stuffed into context, then the AI "thinks" again about how to summarize. With a script, it executes once and returns the processed, concise result to the AI.

Version Locking

MCP servers are typically run like npx @some/mcp-server, pulling the latest version every time. This means the server maintainer could push a malicious update at any moment, and you'd have no idea.

When converting to a skill, you can lock the version number—at least providing some defense against supply chain attacks.

Quick Example

Usage looks something like this:

> /mcp-skill-generator convert @anthropic/mcp-server-filesystem
> /mcp-skill-generator convert https://docs.devin.ai/work-with-devin/deepwiki-mcp

It will ask where you want to save it (project directory or personal directory), then automatically extract the schema and generate files. The resulting directory structure is:

mcp-filesystem/
├── SKILL.md
├── config.toml
├── tools/
│   ├── read_file.md
│   ├── write_file.md
│   └── ...
└── scripts/
    ├── mcp-caller.mjs
    ├── ...
    └── api.mjs          # AI can use this for scripting

Finally

The code is in my claude-skills repo if you're interested.

To be honest, this skill itself was written using Claude Code. During the process, I deeply experienced how much more reliable "having AI write code" is compared to "having AI call tools"—at least when code doesn't run, you can see error messages, instead of the AI quietly going off track without you knowing.

shadow-cljs-vite-plugin v0.0.6: Fixing HMR and ES Module Compatibility

2026-01-22T00:00:00Z

Two weeks after the initial release of shadow-cljs-vite-plugin, v0.0.6 brings some important fixes that make the development experience much smoother.

Problem 1: ES Module Imports

When I first released the plugin, there were edge cases where ClojureScript code wouldn't import correctly in Vite's ESM environment. This was particularly problematic for users deploying to Cloudflare Workers.

The fix required coordinating with shadow-cljs upstream. We submitted a PR #1249 to address the root cause, which was merged in v3.3.5. Thanks to @thheller for working through it with me!

Problem 2: HMR "Namespace already declared" Error

This was a frustrating one. During hot module replacement, Vite re-executes module code, but global state (like goog.loadedModules_) persists across HMR updates. Google Closure Library assumes modules are loaded exactly once and throws errors on duplicate registration.

The solution was to patch goog.provide and goog.module to be idempotent:

goog.provide = function(name) {
  return goog.isProvided_(name) ? undefined : goog.constructNamespace_.call(this, name);
};

goog.module = Object.assign(function(name) {
  if (name in goog.loadedModules_) {
    goog.moduleLoaderState_.moduleName = name;
    return;
  }
  return origModule.call(this, name);
}, origModule);

Better HMR Batching

Previously, if you saved multiple files quickly (or your editor formatted on save), each change triggered a separate HMR update. Now the plugin batches multiple file changes into a single update using a debounce mechanism.

Additionally, changes to shadow-cljs.edn now automatically restart Vite, so you don't have to manually restart when modifying your build configuration.

Tailwind CSS Support

The plugin works great with Tailwind CSS. I've been using this combination on my blog frontend with no issues.

Try It Out

npm install shadow-cljs-vite-plugin

The plugin is stable and I'm using it in production. Feedback and contributions are always welcome on GitHub.

Bitcoin Wallet Connector: Probably the Best Bitcoin Wallet Adapter Currently

2026-01-06T00:00:00Z

Clickbait intended 🤪

In the previous article, I ranted about how chaotic the Bitcoin wallet ecosystem is: WBIPs standards that nobody implements, sats-connect compatibility issues, wallets each doing their own thing with APIs...

This article introduces the library I built: bitcoin-wallet-connector.

Try the Live Demo first, or check out the Storybook.

What This Library Focuses On

Smoothing Out the Ridiculous Differences

bitcoin-wallet-connector provides a unified API that lets you connect to all supported wallets with the same code:

import {
  BitcoinWalletConnector,
  UnisatWalletAdapterFactory,
  XverseWalletAdapterFactory,
  LeatherWalletAdapterFactory,
} from "bitcoin-wallet-connector";

// Register the wallets you want to support
const connector = new BitcoinWalletConnector([
  UnisatWalletAdapterFactory(),
  XverseWalletAdapterFactory(),
  LeatherWalletAdapterFactory(),
]);

// Subscribe to available wallet changes
// Note: The timing of wallet extension API injection is unpredictable
// (some inject at DOMContentLoaded, others after the load event),
// so subscribing is recommended over getting
connector.subscribeAvailableAdapters((availableAdapters) => {
  console.log(
    "Available wallets:",
    availableAdapters.map(([id]) => id)
  );
  // => ['unisat', 'xverse', ...]
});

// Connect wallet - same API for all wallets
const [adapterId, adapter] = availableAdapters[0];
await connector.connect(adapterId, adapter);

// Get addresses, sign, send transactions - unified interface
const addresses = await adapter.getAddresses();
const result = await adapter.signMessage(
  addresses[0].address,
  "Hello Bitcoin!"
);

That's it. Write the code once, support all wallets.

Currently supported wallets:

Wallet	Adapter	Extra Dependencies
UniSat	`UnisatWalletAdapterFactory`	-
Xverse	`XverseWalletAdapterFactory`	`sats-connect`
OKX	`OkxWalletAdapterFactory`	-
Leather	`LeatherWalletAdapterFactory`	`@leather.io/rpc`
Bitget	`BitgetWalletAdapterFactory`	-
Magic Eden	`MagicEdenWalletAdapterFactory`	`sats-connect`

All adapters implement the same interface:

interface WalletAdapter {
  // Connect/Disconnect
  connect(): Promise<void>;
  disconnect(): Promise<void>;

  // Get addresses
  getAddresses(): Promise<WalletAdapterAddress[]>;

  // Message signing
  signMessage(address: string, message: string): Promise<SignMessageResult>;

  // Send BTC
  sendBitcoin(
    fromAddress: string,
    receiverAddress: string,
    satoshiAmount: bigint
  ): Promise<{ txid: string }>;

  // PSBT signing
  signAndFinalizePsbt(
    psbtHex: string,
    signIndices: [address: string, signIndex: number][]
  ): Promise<{ signedPsbtHex: string }>;

  // Listen for address changes
  onAddressesChanged(callback): { unsubscribe: () => void };
}

No matter which wallet users choose, your business logic stays the same.

About sendRunes/sendInscriptions/sendBRC20

Currently, this library only supports signMessage, sendBitcoin, and signPsbt. It doesn't support sendRunes, sendInscriptions, or sendBRC20.

Because these involve more complex dependencies (like needing an Ordinals Indexer, a BRC20 Indexer, etc.). These would make a Connector overly complicated.

In my view, this should be the responsibility of a Transaction Builder. The Transaction Builder handles transaction construction, then passes it to the Connector for signing and broadcasting.

Security Matters

When designing this library, I prioritized dependency security. The reason is simple: wallet libraries directly handle user assets, and any security vulnerability could result in real financial losses.

Peer Dependencies

I declared important dependencies as peer dependencies rather than bundling them:

pnpm add bitcoin-wallet-connector @scure/base @scure/btc-signer

This means:

You directly control the versions of these dependencies
If a dependency has a security vulnerability, you can upgrade immediately without waiting for this library to release a new version
You won't end up with two versions of @scure/btc-signer bundled in your final build

Optional Dependencies: Install Only What You Need

Wallet SDKs (like sats-connect, @leather.io/rpc) are optional peer dependencies:

# Only supporting UniSat and OKX? No extra dependencies needed

# Need Xverse support?
pnpm add sats-connect

# Need Leather support?
pnpm add @leather.io/rpc

You only install what you need, reducing your exposure to malicious package scripts.

Dynamic Imports: Lazy Loading

This is another important security design: Wallet SDKs are lazy-loaded via dynamic import().

// Internal implementation sketch
const availability = createAvailability({
  getPrecondition: () => window.unisat ?? null,
  initializer: async () => {
    // Only when user actually wants to connect this wallet
    // will the corresponding implementation be loaded
    const { UnisatWalletAdapterImpl } = await import(
      "./UnisatWalletAdapter.impl"
    );
    return new UnisatWalletAdapterImpl();
  },
});

Suppose sats-connect gets compromised in a supply chain attack (not uncommon in the npm ecosystem). If your users only use UniSat wallet, the malicious code won't be loaded or executed, because sats-connect is only imported when users click "Connect Xverse".

This should reduce users' exposure to supply chain attacks.

Framework Integration

Currently React integration is provided with an out-of-the-box Context Provider:

import {
  BitcoinConnectionProvider,
  useBitcoinConnectionContext,
} from "bitcoin-wallet-connector/react";
import {
  UnisatWalletAdapterFactory,
  XverseWalletAdapterFactory,
} from "bitcoin-wallet-connector/adapters";

const adapterFactories = [
  UnisatWalletAdapterFactory(),
  XverseWalletAdapterFactory(),
];

function App() {
  return (
    <BitcoinConnectionProvider
      adapterFactories={adapterFactories}
      onWalletConnected={(session) => console.log("Connected:", session)}
      onWalletDisconnected={() => console.log("Disconnected")}
    >
      <WalletUI />
    </BitcoinConnectionProvider>
  );
}

function WalletUI() {
  const { walletSession, availableAdapters, connect, disconnect } =
    useBitcoinConnectionContext();

  if (walletSession) {
    return (
      <div>
        <p>Connected: {walletSession.adapterId}</p>
        <button onClick={() => disconnect()}>Disconnect</button>
      </div>
    );
  }

  return (
    <div>
      {availableAdapters.map(([adapterId, adapter]) => (
        <button key={adapterId} onClick={() => connect(adapterId, adapter)}>
          Connect {adapterId}
        </button>
      ))}
    </div>
  );
}

The core BitcoinWalletConnector is framework-agnostic. If you're using Vue, Svelte, Solid, or other frameworks, wrapping it into corresponding hooks/composables should be straightforward. Contributions are welcome!

Get Started and Contribute

Quick Start

pnpm add bitcoin-wallet-connector @scure/base @scure/btc-signer

# Install wallet SDKs as needed
pnpm add sats-connect      # Xverse / Magic Eden
pnpm add @leather.io/rpc   # Leather

Or get the demo running in 5 minutes:

Clone the repo
pnpm install
pnpm storybook
Open http://localhost:6006

You can test wallet connections, signing, and other features in Storybook.

Contributing

This is an open source project, and community contributions are very welcome!

If you want to add support for a new wallet, there's one small preference: try to avoid depending on the wallet's official SDK.

Why? Because many wallet APIs are just mounted on the window object and can be called directly without introducing an additional SDK. For example, the UniSat, OKX, and Bitget adapters have zero external dependencies.

Introducing an SDK means one more potential supply chain attack vector, one more package users need to install, and potentially unnecessary bundle size. Of course, if a wallet can only be accessed through its SDK (like Xverse's sats-connect), that's fine — we can make it an optional peer dependency.

See CONTRIBUTING.md for detailed contribution guidelines.

The project is fully open source (MIT). Stars and contributions are welcome!

The Bitcoin Wallet Extensions Ecosystem is a Mess: A Developer's Rant

2026-01-03T00:00:00Z

If you're building a Bitcoin dApp, you've probably already discovered that the Bitcoin community's ecosystem is an absolute dumpster fire.

The simplest example is Bitcoin wallets. Everyone seems eager to create standards for others, but nobody seems eager to actually implement them.

"Standards"? What Standards?

Let me be more specific:

WBIPs: Even the Standard Makers Don't Follow Their Own Standards

Leather and Xverse created WBIPs, supposedly to establish a unified Bitcoin wallet API standard, but:

The signPsbt finalize parameter

The signPsbt standard defines a finalize parameter, but neither of the initiators implemented it:

Leather's code
Xverse's code

The wallet auto-discovery mechanism is completely wrong

WBIP004 defines a wallet plugin auto-discovery mechanism, where the first step is to inject the wallet provider into wbip_providers.

But in reality, both Xverse and Leather inject into window.btc_providers:

Leather's code
Xverse's code

Two other major wallets don't care at all

Not to mention that UniSat and OKX Wallet, which actually have massive traffic, seem to have zero interest in supporting WBIPs.

sats-connect: A Standard on Top of Standards

Then, beyond WBIPs, Xverse also created sats-connect, apparently wanting to extend some of their own APIs beyond WBIPs, implementing a standard on top of a standard.

This isn't bad, especially since it also provides compatibility with the UniSat API. Magic Eden even claims to be "sats-connect compatible."

"This sounds absolutely amazing! sats-connect is the meta! The savior of the world!" Right? That's what you're thinking.

But there are still "two small clouds" hovering over this perfect world:

sats-connect doesn't support OKX Wallet (even though OKX Wallet's API has now migrated to be UniSat-compatible, sats-connect can't auto-discover it)
Magic Eden's auto-discovery follows a different standard: ExodusMovement/bitcoin-wallet-standard, not the WBIPs standard. So you can't rely on sats-connect to auto-discover it.

Wait What, Another Standard?

"Wait, what the hell is this ExodusMovement/bitcoin-wallet-standard? I've never heard of it!"

Right, before I tried to integrate Magic Eden, I hadn't heard of it either. Now I've heard of it, and so have you.

More Fun Facts

Oh, here's a "fun fact": if your users have both Xverse and Magic Eden installed, and you don't handle it properly, when they click "Connect Wallet," they might randomly receive a confirmation request from one of the two wallets. Life is full of surprises.

Oh, and another "fun fact": although Magic Eden claims to be "sats-connect compatible," it's actually compatible with an older version of the API.

Show Some Code

You might think, "Fine, I'll just integrate them all myself." So let's look at the code differences for implementing a simple "connect wallet" feature:

// UniSat - Direct window object call
const unisatResponse = await window.unisat.requestAccounts()

// Leather - Yet another API
const leatherResponse = await window.LeatherProvider.request("getAddresses")

// Xverse - From official docs
import { request } from "sats-connect"
const xverseResponse = await request("getAddresses", null)

// Magic Eden - From official docs
import { getAddress, AddressPurpose, BitcoinNetworkType } from "sats-connect"
await getAddress({
  getProvider: getBtcProvider,
  payload: {
    purposes: [AddressPurpose.Ordinals, AddressPurpose.Payment],
    message: "Address for receiving Ordinals and payments",
    network: {
      type: BitcoinNetworkType.Mainnet,
    },
  },
  onFinish: response => {
    console.log("onFinish response, ", response.addresses)
    connectionStatus?.setAccounts(response.addresses as unknown as Account[])
  },
  onCancel: () => {
    alert("Request canceled")
  },
})

Four wallets, four different implementations.

What if you need to integrate 6 wallets in your project? Congratulations, you'll need to go through all the issues I mentioned above, and enjoy wasting a huge chunk of your life along with me.

To Sum It Up

"F**k the stupid ecosystem, what a dumpster fire!" — you/I thought.

So I Built a Library

So I built bitcoin-wallet-connector to help others waste less time on this crap.

In the next article, I'll detail the usage and design philosophy of this library. If you can't wait, check out:

Live Demo
GitHub Repository

I Moved My Config Sharing Repo to LLM-oriented Mode

2026-01-02T00:00:00Z

Simply put, config sharing projects provide llms.txt, and consumers use it to let LLMs download/update project config files to keep them up to date—instead of distributing configs through npm registry.

So Why Not Use npm Anymore?

Traditional ways of sharing tool configurations—whether through extends or presets—all face a fundamental contradiction: the trade-off between convenience and flexibility.

The Pros of Inheritance Mode

When you use something like extends: "@company/eslint-config", the benefits are obvious:

Easy upgrades: Just npm update, and all projects using this config get the updates
Consistency guaranteed: All projects in the team use the same rules
Centralized maintenance: Improvements and bug fixes only need to happen in one place

But Reality is Harsh

Problems arise when you need to do anything "non-standard":

Custom requirements: Your project has special needs and requires overriding certain rules
Dependency version conflicts: You need to upgrade ESLint, but the upstream config package hasn't caught up yet (e.g., ESLint moved to flat config mode, and you need the latest version, but I'm lazy and haven't updated yet 🤪)
Rule disagreements: Upstream updated a rule, but it doesn't fit your project (the problem is you might not know at first, and only realize "damn, I got burned" when things break)

At this point, you have two choices:

Option A: Patch on top of inheritance

// eslint.config.js
export default [
  ...baseConfig,
  {
    rules: {
      // Override one rule
      "some-rule": "off",
      // Override another
      "another-rule": ["error", { different: "options" }],
    },
  },
  // Still need to handle plugin version conflicts...
];

As patches pile up, your "inheritance" becomes layer upon layer of overrides, ending up harder to maintain than writing from scratch.

ESLint is actually not too bad. Tools like Prettier and lint-staged that don't have extends/merge mechanisms are even more troublesome. I previously wrote a super complicated lint-staged config (see lint-staged.config.js and lint-staged.helpers.js). It looks decent (well, at least I think so), but it's actually super hard to use and makes a very simple thing extremely complex.

Option B: Eject

Many scaffold tools provide an eject command that copies all config files into your project, giving you full control.

But after ejecting:

You lose the ability to auto-upgrade; you have to update yourself and can't benefit from upstream's tested plugin compatibility
When upstream has important updates, you need to manually diff and merge

This is the dilemma: In inheritance mode you're constrained by upstream; after ejecting you bear the maintenance cost.

LLM is a Game Changer

Now we have LLMs. Times have changed.

The New Workflow

Get latest configs: LLM fetches the latest recommended configs directly from llms.md/llms.txt
Smart merging: LLM understands your project context and merges new configs into existing ones
Preserve customizations: Your custom modifications are recognized and preserved
Update on demand: When you need to upgrade, let LLM handle the merge conflicts

Why is This Better Than Traditional Approaches?

All configs live in your codebase

No hidden config files deep in node_modules, no confusion about "where did this rule come from". Every line of config is clearly visible in your project.

Upgrades become controllable

Upgrading is no longer an "all or nothing" decision. LLM can help you:

See what changed upstream
Understand the impact of each change
Selectively apply updates
Automatically handle merge conflicts

Customization is a first-class citizen

Your customizations are no longer "patches"—they're part of the config. LLM understands and respects these customizations when updating.

Dependency version freedom

You can upgrade any dependency anytime without waiting for upstream config packages to update. Run into issues? LLM can help adjust the config (and configs are easier for them to read now too).

Upstream config files become simpler

Let's look at my lint-staged config files again.

Previous version:

lint-staged.config.js
Helper functions I had to write so downstream could reuse and customize the lint-staged config: lint-staged.helpers.js

Current version:

lint-staged.config.js Actually, this is so simple now, let me just inline it:

module.exports = {
  "*.{ts,tsx,js,jsx}": ["prettier --write", "eslint"],
  "*.{css,scss,sass,less,md,mdx}": ["prettier --write"],
};

lint-staged.helpers.js no longer exists—because it's no longer needed

You've Said a Lot, But Doesn't This Still Look Like a Step Backward?

Yes and no.

Yes: Config files do exist independently in each project, just like the old days
No: Because the maintenance cost has fundamentally changed:
- Before: Manually read CHANGELOG or diff against upstream config -> Figure out what changed -> Manually modify -> Test and verify
- Now: Tell LLM "upgrade to the latest recommended config" -> Review LLM's changes -> Done

The cognitive burden of maintenance shifts from "I need to understand all these configs" to "I need to review LLM's suggestions". This is what's different from the early days.

Summary (AI version, couldn't write this myself)

Traditional config sharing forces a choice between "one-size-fits-all convenience" and "full autonomy with complexity". The LLM-oriented approach lets us have both:

Maintain full ownership and transparency of configs
While enjoying intelligent assistance for upgrades and maintenance

This isn't a step backward in technology—it's redefining best practices with new tools.

I built (another) Elm-style useEffectReducer hook for React

2025-11-12T00:00:00Z

GitHub: bolasblack/react-components/tree/develop/packages/useEffectReducer

What is "Elm-style"?

Elm popularized the Model-View-Update pattern, where each update returns both the next model and the commands to run:

update : Msg -> Model -> ( Model, Cmd Msg )

This design keeps all logic about "what happens when event X occurs" in one place — the update function — instead of scattering side effects across random useEffects.

It also keeps reducers pure while making when and what side effects happen explicit and interpretable by a runtime.

React's docs echo this philosophy: effects should be an escape hatch, not the default — see You Might Not Need an Effect.

If you want to see how this kind of modeling makes UI logic elegant and maintainable, check out David Khourshid's classic post "No, disabling a button is not app logic."

So why another Elm-style reducer?

The author wanted a variant with different trade-offs:

Some are archived. For example, useEffectReducer and react-use-bireducer are now read-only.
Keep it tiny. Fits in one file with almost no dependencies — copy, tweak, or delete it whenever you want.
Effects as plain objects + separate interpreter. Returns serializable effect descriptors and implements the actual effect logic in one dedicated place. It's easier to test reducers (assert on descriptors) without invoking real side effects.
Lower the barrier. The goal is to make the Elm-style approach approachable without requiring deep knowledge of Elm's Cmd Msg system or learning a full-blown state machine library like XState.

Example usage

The article reimplements the example from David Khourshid's article "No, disabling a button is not app logic." using useEffectReducer.

Both implementations are available on GitHub:

useEffectReducer version: useEffectReducer.stories.tsx → L121–203
useReducer version: useEffectReducer.stories.tsx → L24–119

Excellent existing takes on bringing Elm-style "state + effects" reducers into React:

davidkpiano/useEffectReducer — by David Khourshid; archived
soywod/react-use-bireducer — returns [state, effects] and processes effects through a separate effect reducer; archived
ncthbrt/react-use-elmish — Elmish-style hook combining reducer logic with async helpers
redux-loop — Redux enhancer adding Elm-like effect tuples
dai-shi/use-reducer-async — extends dispatch for async actions
useReducerWithEmitEffect — Sophie Alpert's gist that inspired much of this work

Good Articles

Christian Ekrem - "Chapter 2, Take 2: Why I Changed Course"
David Khourshid – "Redux is half of a pattern (1/2)"
David Khourshid – "There are so many fundamental misunderstandings about XState (and state machines in general)"
David Khourshid – "No, disabling a button is not app logic."
React docs – "You Might Not Need an Effect"