SetFork Docs

The gnome workshop

Who actually builds your list — expert gnomes, guilds, reputation and a shared knowledge base.

SetFork isn't "one model that generates something" — it's a workshop: behind every list stands a council of expert gnomes. Each has a specialty (chef, devops, coder, coach, traveler, scholar and more), a character of their own, and a professional code.

One council, many voices

When you generate a list, a single council convenes:

  1. A steward frames the topic and calls in the right gnomes.
  2. Guild experts draft variants — each from their own angle.
  3. A critic checks the draft against the guild code: facts, completeness, links.
  4. An elder synthesizes the debate into one final list.

One council, but many voices — so you get different perspectives without extra cost. As it runs you can see who proposed what: the gnomes have character, short lines, even friendly clashes (the chef grumbles at the innovator).

Guilds

Each gnome carries their guild: its traditions, its code (a set of quality standards) and its methods. The code isn't flavor — it's a working tool: it's woven into the gnome's prompt and serves the critic as a yardstick. The chefs' code draws on HACCP, the devops code on the SRE Book.

The public showcase is the Workshop guilds page. A list that has been through the council is marked with a "Forged by the council" stamp — a sign that experts worked on it, not one anonymous generation.

Reputation

You don't have to take a gnome's word for it: next to each gnome during the council is a reputation badge (✓ N%) — how often their proposals are borne out in practice: accepted lists, stars, forks and runs of the lists they helped build. This is visible to you, not just to the admin — so you can see why these suggestions are worth trusting.

Shared brain, different lenses

The gnomes have no separate knowledge bases — there is one base for all: the index of every published SetFork list plus "craft rules" (relations like "chicken can be swapped for turkey", "this step requires an oven"). What differs is the lens: the chef queries the base by ingredients and steps, the devops gnome by commands and rollbacks.

A new list, once it's been through the council and published, itself becomes a precedent for the next ones — the workshop learns from what's made in it.

Ask a gnome directly

Through MCP the gnomes are reachable from your own agent:

  • list_gnomes — see the roster and pick the right one;
  • ask_gnome — put a question to one expert (advice, outline, critique);
  • gnome_review — have a guild master review a finished list against the code;
  • council_draft — convene the full council from outside, as on the site.

Dig deeper

The mountain is a mountain of information, and the gnomes dig. The "Dig deeper" button on a list item goes down layer by layer: reasons, mechanism, exceptions. What's dug up settles into the shared base — the mountain leaves tunnels the next digs reuse.

On this page