Forgeprint

Forgeprint

Others say "here are 200 skills, go find yours." Forgeprint says "tell me who you are and what you're building — here is your package."

Forgeprint is a community-grown blueprint catalog and MCP server that lets a coding agent bootstrap a new project with the right context in one shot: the AGENTS.md, the skills, the MCP and plugin configuration, and a deterministic setup recipe the agent can execute.

Status: pre-release. A catalog of blueprints, experts, crews and integrations, working tooling, and an MCP server with all ten tools, published and connectable today. With Claude Code:

claude mcp add forgeprint -- npx -y forgeprint-mcp

On Windows PowerShell, quote the separator: claude mcp add forgeprint "--" npx -y forgeprint-mcp.

Any MCP client can connect; the site has the command or configuration for each of the nine registered agents, and the catalog with its current counts. Roadmap has the rest.

The problem

Every new project starts cold. You hunt down the requirements, write the rule file by hand, wire up the MCP servers, pick the plugins, and get the setup steps wrong twice before they work. Hours of it — repeated by everyone, on every project, forever.

That knowledge is not hard to write down. It is just never written down in a form another agent can use.

What makes it different

1. A resolver, not a catalog to browse

You do not search Forgeprint. You describe yourself and your goal, and it returns exactly one blueprint.

You:   I know C#. I want to build a multi-tenant SaaS API.
Agent: [resolve] → Forgeprint returns questions: which database, which auth,
       self-hosted or cloud?
You:   Postgres, JWT, cloud.
Agent: [resolve] → one blueprint, why it was chosen, what is missing on this
       machine, and the setup plan.

When the profile is incomplete, the resolver does not guess: it returns the questions your agent should ask you. When two candidates are genuinely close, it returns both as a question and lets you pick — never as a list to sift through. When nothing fits, it says so, names the closest blueprint, explains why it does not fit, and offers to file a request. It never invents a match.

Scoring is weighted: a language you already know beats everything else.

2. A setup recipe, not a description

setup.md is a script, not prose. Every step is numbered, is a single command or a single file operation, and ends with a verification command. Versions are pinned. Option branches are explicit. The agent executes it; Forgeprint itself installs nothing and runs nothing on your machine.

3. A quality gate, not a junk drawer

Every pull request passes schema validation, a setup test that actually runs the recipe in a clean container, and a duplicate report against the closest existing blueprint. Two blueprints may not claim the same stack, project type and requirements — a better one replaces the old one instead of sitting next to it.

There is no inheritance and there are no variants. Variation is expressed as options, capped at three fields with three values each, so the whole matrix stays testable. See ADR 0001.

4. Standards-compatible, not another format

Forgeprint follows the existing specs — AGENTS.md, SKILL.md, marketplace.json — so its output drops into the tools you already use, and skills remain installable through the usual channels:

npx skills add forgeprint/forgeprint            # skills.sh CLI
gh skill install forgeprint/forgeprint blueprint-author

Both are verified against the real tools before each release, and forgeprint validate fails on a skill that would not install — see ADR 0006.

How it compares

Forgeprint is not trying to replace most of these. It sits in the gap between them.

How it works

You point your agent at the MCP server and talk normally. docs/mcp.md has the connection details and a worked exchange.

Without an MCP client, nothing above is required:

npx -y forgeprint get ts-http-service --agent cursor --options framework=hono

That writes the files that agent reads, and the recipe with your options resolved — the same answer the tools give, because it is the same code (ADR 0013). It reads the published catalog, or a checkout when you are in one. The catalog is also published as JSON at forgeprint.github.io/forgeprint/index.json and as llms.txt.

Forgeprint replies in English. Your agent presents it in your language: the tools take a locale hint and hand it back, so nothing in the catalog has to be translated. See ADR 0004.

What works today

npx forgeprint validate          # in a checkout of any Forgeprint catalog
npx -y forgeprint-mcp            # the MCP server, over stdio

To work on the catalog itself:

git clone https://github.com/forgeprint/forgeprint.git
cd forgeprint
pnpm install
pnpm run build
pnpm forgeprint validate

Every pipeline step is a command you can run locally. Hosted CI is a convenience, never a dependency: the workflows call these same commands, the generated index is committed to the repository, and GitHub Pages serves it straight from the branch. When Actions is unavailable, nothing stops. See ADR 0002.

Layout

blueprints/<slug>/     one folder per blueprint — the unit of contribution
skills/                blueprint-author and blueprint-review
schema/                manifest schema and the controlled taxonomy
packages/cli/          forgeprint validate / build-* / similarity / lint-setup
packages/mcp-server/   the MCP server (npx forgeprint-mcp)
packages/site/         the static GitHub Pages site, generated into docs/
docs/                  index.json, the ADRs, and the published site

Roadmap

• Phase 0 — Skeleton. Workspace, schema, taxonomy, validation and generators, licensing, contribution and governance rules.

• Phase 1 — First content. Three official blueprints, the blueprint-author and blueprint-review skills, the similarity report and the setup lint.

• Phase 2 — MCP. The six tools, the option resolver, and the server over stdio, published as forgeprint-mcp.

• Phase 3 — Publishing. The site is generated from the catalog and served at https://forgeprint.github.io/forgeprint, and the workflows run: validate on every push and pull request, setup-test on the recipes. forgeprint validate checks the skill format the distribution tools read, so npx skills add and gh skills install agree with it (ADR 0006).

• Phase 4 — Community. Contributor visibility has shipped: every blueprint page names and links its maintainer, and the open blueprint requests are listed live. What is left waits on people rather than on work — the orphan, staleness and co-maintainer rules are written in GOVERNANCE.md and will be automated when there is a second maintainer to automate them for, and community translations open when somebody wants to write one.

  A "times resolved" counter is **not** planned. It would mean the server
  learning something about the people who use it, and
  [PRIVACY.md](PRIVACY.md) says it collects nothing. If it is ever
  revisited it will be anonymous and opt-in, and that file says so.
  

Contributing

Read CONTRIBUTING.md first — especially the part about checking whether the blueprint you want to write already exists. The fastest merge is usually a pull request against a blueprint that is already there.

Two skills carry the procedure, for you or for your agent: blueprint-author turns a working project into a blueprint that passes the gate, and blueprint-review is the standard it is judged against. Install either one into your agent:

gh skill install forgeprint/forgeprint blueprint-author
npx skills add forgeprint/forgeprint --skill blueprint-author

Or add the marketplace, and take them as Claude Code plugins:

/plugin marketplace add forgeprint/forgeprint

Want a blueprint you cannot write yourself? File a blueprint request. The catalog grows by demand.

Who decides what, who reviews, and what happens when nobody answers: GOVERNANCE.md.

Licence

Forgeprint is source-available, not OSI open source. Saying otherwise would be easier and less honest.

Blueprint content is deliberately the freest part: a blueprint you cannot put in your own project is worthless. The reasoning is in ADR 0003.