Foundry: Turn Your AI Workflow History Into Reusable Skills

You repeat the same workflows every day. Kill a stale server, rebuild, test. Check investor emails, cross-reference Telegram, draft a follow-up. Poll two APIs, compare against sprint targets, report deltas. Each time your AI coding assistant runs through these sequences, it starts from scratch -- no memory of the last twenty times it did the exact same thing.

What if your assistant could learn those patterns and turn them into reusable skills automatically?

That is what Foundry does.

The Problem: Every Session Starts Fresh

AI coding assistants are powerful. Claude Code, Codex, and similar tools can navigate codebases, run commands, query APIs, and synthesize results. But they share a fundamental limitation: each session is stateless. The assistant does not remember that yesterday it ran the same seven-step pipeline you are about to describe again.

Developers compensate by writing instructions in markdown files, building custom scripts, or just re-explaining workflows every time. Some teams maintain skill files -- structured descriptions of workflows that the assistant can follow. But writing and maintaining those skills is manual work, and most recurring patterns never get codified at all.

The gap is not intelligence. It is institutional memory.

How Foundry Works

Foundry is an open-source tool that reads your local AI session history, finds repeated workflow patterns, and turns them into portable skill bundles. It works in four stages.

Stage 1: Discover

Run npm run discover and Foundry scans every session in your local history. It builds a dataset of tool calls, command sequences, file access patterns, and timing. Then it clusters sessions by workflow shape -- not by topic or keywords, but by the actual sequence of actions taken.

A preset file defines the scope. For example, the Unbrowse team uses a preset that targets their monorepo workflows:

node scripts/discover-skill-candidates.mjs \
  --preset presets/unbrowse-workflows.json

Foundry outputs candidate skills backed by hard evidence: how many sessions matched, how many tool calls were involved, which command sequences recurred, and what the canonical execution order looks like.

Stage 2: Scaffold

Each discovered cluster becomes a candidate skill with a generated SKILL.md file. This is not a vague summary -- it includes the exact workflow steps, load-bearing rules extracted from the sessions ("always kill before testing -- stale servers are the number one false-negative source"), and the evidence that backs each step.

The scaffold also generates references/runtime-pointers.md with sanitized environment variable names and config locations. Sensitive values, emails, and user-specific paths are stripped out. The skill is portable from the start.

Stage 3: Fabricate

npm run fabricate takes the discovered candidates and produces complete bundles:

node scripts/fabricate-bundle.mjs \
  --preset presets/unbrowse-workflows.json \
  --out dist \
  --host claude \
  --scope agent

Each bundle includes install commands, host targets (Claude Code, Codex, or OpenClaw), routing rules, and memory artifacts. The output is a directory you can share, index, or commit.

Stage 4: Route

Discovered skills auto-install into the local host skill directory. For Claude Code, that is ~/.claude/skills. For Codex, $CODEX_HOME/skills or ~/.codex/skills. Foundry also writes host memory entries so future requests get routed to the right skill automatically -- no manual wiring needed.

Behind the scenes, Foundry also builds an explicit action DAG from tool traces and emits next-action training examples from real tool sequences. This is the foundation for a Phase 2 routing layer where the assistant does not just follow a skill -- it predicts the next action based on patterns across all sessions.

Real Example: Mining the Unbrowse Monorepo

We did not build Foundry as an abstract exercise. We built it because the Unbrowse team was running the same workflows by hand, session after session, and we wanted to know exactly how much repetition was hiding in our history.

We pointed Foundry at 319 sessions spanning 16,000 tool calls and 200 commits. It found 6 candidate skills that the team was executing manually dozens of times per sprint.

What Foundry Found

dev-loop -- The single most repeated workflow. Kill stale processes, rebuild from source, test resolve and execute, check output shape. It appeared in 21 sessions with an average of 117 tool calls each. The sequence pkill -> sleep 2 -> resolve -> validate showed up 47 times. Foundry encoded the load-bearing rule that the stale-server kill must happen before every test run.

traction-watchdog -- 27 sessions that were almost entirely context-gathering: read memory, call two API endpoints, do mental math, report to the user. The same two endpoints in the same order every time. Foundry turned it into a single-command dashboard.

investor-pipeline -- 14 sessions that all started with the same 7-step memory read sequence: load contacts, check BoldSign for SAFE status, scan Gmail, query Telegram, cross-reference for staleness, draft follow-ups, update memory. Every step was manual. Now it runs in one invocation.

content-loop -- Check content queue, optimize drafts for platform, schedule via Typefully. 9 sessions with the same flow.

issue-swarm -- Fetch issues, triage by area, spawn parallel agents, collect PRs. Foundry detected the fan-out pattern across 12 sessions.

eval-close -- Run eval harness, judge results against issue criteria, auto-close passing issues. 8 sessions with consistent structure.

None of these were obscure. They were the team's most common workflows -- hidden in plain sight because no one had audited session history before.

The Compound Effect

After installing the 6 discovered skills, the average session for these workflows dropped from 40-120 tool calls to a single skill invocation. That is not a minor efficiency gain. It changes what the team can accomplish in a day because the assistant stops re-deriving solutions and starts executing known-good procedures.

The skills also improved in quality over time. Each time a discovered skill runs, Foundry can re-mine the history and detect drift -- steps that have been added or removed since the skill was first scaffolded. The skill evolves with the team's actual practice.

Getting Started

Install Foundry as a skill:

npx skills add https://github.com/unbrowse-ai/foundry --skill foundry --yes

Or clone and run directly:

git clone https://github.com/unbrowse-ai/foundry
cd foundry
npm install

Create a preset file that defines your project scope (or use the included examples), then run discovery:

npm run discover

Inspect the candidates in the output directory. Each one has a SKILL.md with the workflow steps, evidence, and load-bearing rules. Review them, adjust if needed, then fabricate:

npm run fabricate

The skills auto-install into your host's skill directory. Next time you start a session, your assistant knows about them.

For continuous discovery, run the watcher:

npm run discover:watch

This re-scans history on a schedule and surfaces new candidates as your workflows evolve.

The Bigger Picture: Portable Skills Across Hosts

Foundry is not tied to one AI assistant. The same discovered skill can target Claude Code, Codex, or OpenClaw. The fabrication step generates host-specific install commands and routing rules for each target.

This matters because the skill is not the prompt. It is the workflow. The SKILL.md format is a structured description of steps, rules, and evidence that any capable assistant can follow. Moving from Claude Code to Codex does not mean re-discovering your workflows. You carry them with you.

Foundry also integrates with the broader skill ecosystem. Discovered skills can be published to skill registries, shared across teams, or contributed back to open-source projects. The Unbrowse team's own companion skills -- docs-release-sync, skill-surface-ship, main-actions-triage, and history-skill-miner -- were all originally discovered by Foundry and then refined into production-grade skills.

The long-term vision is a self-improving loop: use your assistant, let Foundry mine the patterns, install the skills, use the assistant more effectively, generate better patterns, mine again. The forge forges itself.

Start Mining Your History

Every AI coding session you have run contains latent skills -- workflows you repeat but have never codified. Foundry extracts them automatically, backs them with evidence, and installs them where your assistant can use them.

The code is open source at github.com/unbrowse-ai/foundry. Install it, run discovery against your history, and see what your own workflows have been trying to tell you.

npx skills add https://github.com/unbrowse-ai/foundry --skill foundry --yes

If you find it useful, star the repo. If you discover interesting workflow patterns, open an issue -- we want to see what Foundry finds in the wild.