The card format

A card is a Markdown file in your vault (your repository). Write every new card in this v2 shape. The older v1 shape is still read, but is not for new cards (the v1 shape).

The format’s source of truth is the public repository — anchor-card-format (SPEC.md). That is the exact definition the three apps and the linter follow, and where it disagrees with this page, it wins. This page is the same thing written to be read.

To teach an agent the format, hand it the prompt the app builds for you (under “How to use” in settings — it carries instructions to read the spec), or the examples and the vault templates directly.

Proposals and bugs about the format itself go to Issues.

A whole card

---
id: stat-sd-reading
deck: Statistics/Basics
tags: [descriptive]
---

# What standard deviation tells you

Two datasets have the same mean. Which single number says which one is more spread out?

<!-- back -->

**Definition** [[stat-sd-def]]

It has the same unit as the data, so it reads as "typically this far from the mean".

<!-- hint -->

Its size depends on the unit, so compare spreads across units with SD ÷ mean.

<!-- note -->

Source: any introductory statistics text.

The syntax is frontmatter, a # Title, three marker lines and [[id]] references. Nothing else in the body is syntax.

Which files are cards

A file is read as a v2 card when all of these hold (paths are vault-relative).

1. The file name ends in .md, is not INDEX.md, and does not start with _
2. The file is inside at least one directory (files at the vault root are never cards — that is where README.md and CLAUDE.md live)
3. No directory on the path starts with _ or . (_drafts/, .github/ are never read)
4. The first line of the file, trimmed, is exactly ---

Depth and file names are otherwise free. A file that fails rule 4 is not a v2 card.

The first-line test is one condition, visible in any editor, and cannot collide with an ordinary note.

Frontmatter

The lines between the first --- and the next line that, trimmed, is ---. If there is no closing ---, the file yields no card (it is unclear where syntax ends). The body starts on the line after the closing ---; later --- lines are ordinary body text.

This is not YAML. There are four rules:

• Trimmed blank lines and lines starting with # are ignored
• Otherwise the line is split at its first :: key before, value after, both trimmed. Lines without : are ignored
• A value wrapped in a matching pair of " or ' has the pair removed. No escapes are processed
• A list is written inline only: key: [a, b, c]. Elements split on ,, trimmed, dequoted. The block form is not read

If a key appears twice, the last one wins. Writers must not repeat keys.

No YAML library is used, because three implementations with three YAML parsers would disagree at the edges (no, dates, block scalars). Reading the same bytes the same way matters more.

Keys

Unknown keys are ignored. Do not invent keys meant to change behaviour.

id

• Must match ^[A-Za-z0-9][A-Za-z0-9-]{2,63}$ — 3 to 64 ASCII letters, digits and hyphens, not starting with a hyphen. Case-sensitive. Underscores are not allowed
• A file whose id is missing or malformed yields no card. It is the one breakage readers do not recover from: without a key the review cannot be recorded, and inventing one would mix histories
• The id goes into the review log exactly as written. Implementations never change its case or normalise it
• A fresh ULID (26 uppercase characters) or a readable slug (stat-sd-01) are both fine, and may coexist in one vault
• Never change an existing id, and never reuse the id of a deleted card. Changing it orphans the history; reusing it attaches old history to a different question. Renaming, moving and rewriting the file are all safe
• If two files carry the same id, the first in ascending path order is kept (the linter reports duplicate-id)

deck

• deck: A/B/C splits on /, each part trimmed, empty parts dropped
• The deck is independent of the directory the file sits in. Moving a file does not change its deck; editing deck: does. History is keyed by id, so neither affects history
• If deck is absent, the file’s directory path is used (Statistics/Basics/x.md → Statistics/Basics). This exists so nothing is silently lost; the linter reports missing-deck

The body

Title

The title is the first body line that, trimmed, starts with # and has text after it. Put it first, before any marker. With no title, the file name (without .md) is used and the linter reports missing-title.

The title line belongs to no face and is shown with the card. Never put the answer in it.

Markers and faces

There are exactly three markers. A line is a marker when, trimmed, it is exactly one of these.

• Text before the first marker is the front (minus the title line)
• Each marker switches the face until the next one. Order is free; front → back → hint → note is recommended
• Leading and trailing blank lines of each face are removed; interior blank lines are kept
• ---, emoji, tables, headings and code fences are ordinary body text. They never split faces
• Any other <!-- ... --> line stays in its face as ordinary text. Display differs between apps, so do not put other HTML comments in cards
• A card with no <!-- back -->, or nothing after it, has an empty back. It still loads; the linter reports empty-back. The same applies to ask: false cards — the back is what [[id]] pulls in

References — [[id]]

A reference writes shared text once — typically a definition on an ask: false card — and shows it inside every card that needs it.

• Syntax is [[id]], anywhere in a line
• Only references in the back are expanded. Elsewhere they are shown as written
• A back line containing references is rendered as:
  1. the line with every [[id]] removed and spaces collapsed — omitted if nothing is left (so **Definition** [[stat-sd-def]] keeps **Definition** as a label)
  2. then, for each reference in order, the back of the referenced card
  3. an id that does not resolve shows as reference not found: id. It is never silently dropped
• One level only. References inside the inlined back are not expanded again
• Expansion never modifies the stored files

The [[…]] spelling matches wiki-links, so a vault shared with a note-taking tool reads naturally.

Rendering

The body is Markdown. The apps render a common subset (paragraphs, emphasis, lists, quotes, tables, code); anything they do not understand is shown as text or dropped. Scripts inside a card are never executed. Do not rely on raw HTML.

• On iPhone, tables wrap instead of scrolling sideways (a scroll area there fights the parent scroll)
• Quotes (>) are set one step smaller than body text, so that a screen full of quoted statute does not bury the part you wrote yourself

Lint

A vault can be checked mechanically (lint). One error or more exits 1; warnings and info never fail. It is what lets the “agent writes → lint fails → agent fixes” loop run without opening the app.

Thresholds are part of the format. Fix a card that trips one by splitting the question before it has history, or by moving shared text into an ask: false card — not by changing an id.

For vaults that already hold many long cards, long-back can be pinned to a baseline file. Cards on the list stay warnings; a card that is not on the list fails as an error — so only newly written long cards stop the build. The list only ever shrinks.

The v1 shape (legacy, read-only)

For vaults that predate v2, the older heading-based shape is still read. Do not write new cards in it.

## 基-02　標準偏差の読み方
<!-- id: 01KB6M2QX40000000000000002 -->

**表面：**
Two datasets have the same mean. Which one is more spread out?

**裏面：**
Square each distance from the mean, average them, take the square root.

📌 **定義**: [標準偏差](../用語定義/定-標準偏差.md)

💡 Its size depends on the unit.

**補足：**
Source: any introductory statistics text.

English face labels are accepted only when the line is the label alone. **Note:** the index is separate. is an ordinary English sentence; allowing text on the same line would let prose be eaten as a face label and leak the answer onto the front before you flip. Japanese labels do not occur in prose, so they may carry text on the same line.

Keep the face labels in whatever form that card already uses. Rewriting them into another form makes the card unquizzable (don’t translate a Japanese vault’s labels into English, or the reverse).