The list standard
What makes a list good — the required core, the encouraged norm, and templates for the six list types.
A list in SetFork is edited by many hands: the author, collaborators, a suggestion from a stranger,
the generator, a git push. For lists that mean the same thing to stop looking different every
time, the shape has a standard.
It works the way programming languages do. In Python, indentation is syntax — get it wrong and nothing runs. In JavaScript, semicolons are optional, yet people write them because that's the convention and it reads better. Same here: a small hard core your list cannot be saved without, and a norm we encourage and surface, but never force.
The list type
The type answers one question: what the element of this list is. You pick it at creation and can change it in list settings.
| Type | An element is | Example |
|---|---|---|
| Steps | an action performed in order | deploying a service, assembling a shelf |
| Things to get | a thing you need to have | a car emergency kit, a watercolour starter set |
| Checklist | a state you confirm | "Backup created", "Passport valid for 6+ months" |
| Criteria | a rule you judge or choose by | what to look for when buying a monitor |
| Options | a variant to compare | five newsletter services and their trade-offs |
| Recipe | an ingredient with an amount, then a cooking step | borscht, focaccia |
The type is not decoration: generation shape, validation, export and discovery all follow from it.
What is required
This is the minimum. Without it the list will not save — like Python code without indentation.
- The type is declared. No list without a type: we stopped guessing on the author's behalf.
- At least one element.
- Every element has a title — non-empty, in the list's language.
- Every block has a known type — step, text, image, poll, video, quiz, file or products.
- The list contains the element it exists for: a recipe has at least one ingredient, a things-to-get list has at least one thing, a criteria list has at least one rule. A recipe with no ingredients isn't a free-form recipe — it's a different list.
The required set is deliberately short and grows only by an explicit decision.
What is encouraged
This is the norm. It never blocks saving, but it is visible: the list carries a "what to improve" note, and the note clears itself once the reason is gone.
For every type
- The element's title is about the element, not about working on it. "Determine the right size" is neither a thing nor a rule.
- The description carries what the title can't: amounts, temperatures, flags, gotchas.
- Sections (
Day 1,Dough,Verify) group a long list. A section belongs to any type, not just recipes. - Links point at the source, not at a site's front page.
- Levels are used meaningfully:
required/recommended/optionalis MUST / SHOULD / MAY, not styling.
Per type
| Type | Norm |
|---|---|
| Steps | the title is a short imperative action; a command only where one is genuinely typed into a terminal |
| Things to get | the title carries the thing's name and an amount or spec; order is not a sequence to perform |
| Checklist | the title is a state ("Keys rotated"), not an action ("Rotate the keys") |
| Criteria | the title is the rule itself; "why" explains what breaks when it's ignored |
| Options | at least two options; each names its trade-off, not only its upside |
| Recipe | ingredients come first, each with an exact amount in the title ("Sugar — 400 g"); cooking steps follow, with timings and temperatures |
Templates
A template is a type plus a prepared structure: sections, order, hints in the fields. Start from a template and you already meet the norm — all that's left is the content.
The generator reads the same template. Not two similar documents — one: when the shape changes, it changes for the human and the AI at once, so they have nothing to drift apart on.
What following it buys you
The standard takes nothing away from a list that falls short. It adds for the lists that don't:
- Search engine markup. The list maps onto schema.org (
Recipe,HowTo,ItemList) and becomes eligible for a rich result. - Data, not prose.
data.jsonserves typed elements: an ingredient reads as an ingredient, a tool as a tool. - Discoverability. Filters and collections work by list type.
- Easier collaboration. A suggestion against a familiar shape is reviewed and merged faster.
How it rolls out
The order is the one any live system uses for policy: show first, require later. A new rule arrives as a "what to improve" note, and only then — if it proves uncontroversial — becomes required. Existing lists don't break in the process.
The technical side — which fields travel in list.json, what a rejection looks like and which codes
it carries — lives in Git access and in the manifest schema linked from every
list.json via $schema.