card-creator

name	card-creator
description	Create atomic Obsidian knowledge cards from user-provided ideas, sources, notes, or confirmed learning outcomes. Use when the user asks to save, record, create, or turn material into a reusable knowledge card, even without naming a card type.

Card Creator

Create one reusable knowledge unit at a time. Preserve the user's meaning, source, and uncertainty; write cards only after the requested scope is clear.

Workflow

1. Confirm the card scope

Apply the atomic test: a card has one core object, claim, question, or practice that can be named in one sentence and reused independently.

When the input contains multiple independently reusable cores, propose a split with one title and type per card, then wait for user confirmation before creating multiple files. Treat length, headings, and connective words only as signals to inspect; they do not by themselves require splitting.

MOC is the explicit exception: create it only when the user asks for a navigational map rather than an atomic knowledge unit.

Completion: The input has one atomic core, a user-approved split plan, or a confirmed MOC scope.

2. Select the type and template

Honor a user-specified type when it exists. Otherwise select the type from the core object, not incidental source words: an idea learned from a book may be an insight; use book-note only for a book-specific passage or annotation.

Read references/card-type-map.md before selecting a type. It is the sole authority for supported types, detection cues, template filenames, and source policy. If two types remain plausible, show the two candidates and ask the user to choose.

Completion: The selected card_type, exact template path, and source policy are explicit.

3. Fill the template

Read the exact mapped template under 04_Knowledge/00_Cards/.templates/. Keep type: card; set card_type to the mapped type. Fill only fields present in that template.

For cards whose template requires source, use the original URL when available; otherwise use a concise source name such as a book, conversation, personal experience, or 自己整理. Put titles, authors, context, and explanations in the body's 来源 section. For mapped source-exempt templates, follow the template without inventing a frontmatter field.

Use 待补充 or an empty optional value for genuinely unknown information; leave no literal {{...}} placeholders in the completed card. Read references/writing-rules.md when filling frontmatter, filenames, or links.

Completion: Every required template field is populated, intentionally left empty, or marked 待补充; frontmatter contains valid YAML and no unintended template placeholders.

4. Find meaningful links

Search card titles, card_type, tags, source, and core concepts. Read only the strongest matches, then add up to three meaningful links to the new card using the template's related format. Explain additional relationships in the body when useful.

Creating a card does not authorize modifications to existing cards. When the user explicitly asks for bidirectional links, show the exact existing files and proposed changes before updating them.

Completion: Related cards were searched by core concept and only meaningful new-card links were selected.

5. Create and verify the card

Name the file {card_type}_{title}.md, using a concise stable title and the Vault naming rules. If that exact filename already exists, show the collision and obtain confirmation before replacing or choosing a new name.

Write the card to 04_Knowledge/00_Cards/, parse its frontmatter, verify its template and links, and report its final path.

Completion: The new file exists at the approved path, its frontmatter parses, and the reported card matches the selected type and approved scope.

References

• Read references/card-type-map.md to select a supported type and template.
• Read references/writing-rules.md when producing final card text or YAML.
• Read references/examples.md only when a user request is ambiguous and a nearby example would clarify the type decision.