Skip to content
Eight Effect-native API SDKs are live.Explore the catalog
Distilled
Esc
navigateopen⌘Jpreview
On this page

Introducing Distilled

Extending Alchemy's Effect-native software-factory pattern to Jira, GitHub, and Slack.

The interesting part of a generated SDK is not how quickly it can produce files. It is whether the result stays trustworthy six months later: where the API shape came from, what was changed, how runtime behavior is shared, and who can publish the package.

Distilled is an experiment in making those answers structural.

The spark

Alchemy built a collection of repositories that behaves like a software factory. A shared Effect-native runtime and generator feed provider repositories; provider repositories pin their exact sources and commit generated operations; release automation publishes packages without hand-assembling every client.

We studied alchemy-run/distilled, distilled-spec-neon, distilled-neon, actions, and node-utils at their current heads. The goal was not to borrow the shape from a diagram. It was to understand the working seams in real code.

The extension

Jira, GitHub, and Slack exercise three different source strategies:

Jira

Mirror a maintained, compact OpenAPI document.

GitHub

Extract the exact versioned bundle from a very large OpenAPI repository.

Slack

Generate from the official typed SDK when maintained OpenAPI is absent.

That third path matters. “Generated” should not mean “OpenAPI at any cost.” An official TypeScript source can be more authoritative than a scraped pseudo-spec.

Small adaptations, explicit diffs

The shared package is a thin façade over Alchemy’s published core. Local generator changes stay deliberately small and regression-tested—for example, correctly quoting non-identifier OpenAPI parameter names such as GitHub’s enterprise-team.

The generated operations themselves are committed. When an upstream source moves or a generator changes, reviewers see the consequences rather than trusting an opaque build step.

Releases without a publish token

Each package is bound to one private GitHub repository, one publish.yml, and one npm environment through npm trusted publishing. GitHub issues a short-lived OIDC assertion; npm verifies the workflow identity; long-lived publish tokens are disabled.

That security boundary influenced the docs architecture too. We chose not to import sibling private repository READMEs through a broad cross-repository token. Durable docs live here and link to the exact implementation and source repositories.

What shipped

The next provider should not require inventing the factory again. It should require making one careful source decision, then following a path that is already boring in all the right places.

Last updated on July 15, 2026

Was this page helpful?