@mulmoclaude/core 0.1.0

package/assets/helps/vocabulary.md

@@ -0,0 +1,109 @@
+# Vocabulary — a language-learning collection recipe
+
+Read this whenever the user wants to **learn a new language** (or grow their
+vocabulary in any language) and wants their words tracked, reviewed, and graded
+over time. It is the authoritative template for a vocabulary collection — copy
+it rather than reinventing one from the generic DSL fragments in
+`config/helps/collection-skills.md`. Read that file first for the general schema
+rules; this one is the vocabulary-specific specialization.
+
+The design in one line: **the `proficiency` enum is the single source of truth
+for how well a word is known, and a kanban board lets the user drag a word
+between mastery levels.** It works for any target language — English, Spanish,
+French, Japanese, anything. The word goes in the target language; the example
+sentence shows it in use.
+
+> **The point of the toggle:** the `mastered` checkbox is a `toggle` that
+> projects `proficiency` — checking it sets `proficiency` to `"mastered"`,
+> unchecking returns it to `"new"`. There is NO separate stored `mastered`
+> boolean to keep in sync.
+
+## schema.json
+
+Author it at `data/skills/vocabulary/schema.json` (the bridge mirrors it to
+`.claude/skills/vocabulary/`; the user opens it at `/collections/vocabulary`):
+
+```json
+{
+  "title": "Vocabulary",
+  "icon": "menu_book",
+  "dataPath": "data/vocabulary/items",
+  "primaryKey": "id",
+  "fields": {
+    "id":          { "type": "string", "label": "ID", "primary": true, "required": true },
+    "mastered":    { "type": "toggle", "label": "Mastered", "field": "proficiency", "onValue": "mastered", "offValue": "new" },
+    "word":        { "type": "string", "label": "Word", "required": true },
+    "proficiency": { "type": "enum",   "label": "Proficiency", "values": ["new", "learning", "familiar", "mastered"], "required": true },
+    "meaning":     { "type": "string", "label": "Meaning" },
+    "example":     { "type": "text",   "label": "Example" }
+  },
+  "displayField": "word",
+  "kanbanField": "proficiency"
+}
+```
+
+Every key earns its place:
+
+| Key | What it gives the user |
+|---|---|
+| `word` (`string`) | The word to learn, in the **target language**. It is the `displayField`, so it labels every table row and kanban card. |
+| `proficiency` (`enum`) | The four mastery levels and the single source of truth for "how well known". Drives the kanban columns. |
+| `mastered` (`toggle`) | The **checkbox** in every row and card. Checking it sets `proficiency` to `onValue` (`"mastered"`); the card jumps to the Mastered column. `offValue` (`"new"`) is the level to return to on uncheck. Both must be members of the `proficiency` enum's `values`. |
+| `meaning` (`string`) | The translation / definition in the user's native language. Optional, but recommended for real study — a word list without meanings is hard to revise from. |
+| `example` (`text`) | A sentence using the word in context — the fastest way to remember usage, not just the dictionary gloss. |
+| `kanbanField` | Pins the board to `proficiency` (drag a card → writes `proficiency`). |
+| `displayField` | Card / table label (the word itself, not the opaque id). |
+
+**Labels are localizable.** `title`, `label`, and the enum `values` are free
+text — a Japanese learner's deck might use `"未分類" | "要勉強" | "だいたい" |
+"マスター"`. Keep `onValue` / `offValue` in lockstep with whatever `values` you
+choose; they must match exactly.
+
+## SKILL.md
+
+`data/skills/vocabulary/SKILL.md` tells the agent when and how to operate the
+collection. Keep it short — the schema does the heavy lifting. It should cover:
+
+- **Trigger phrases** — "add a word", "vocabulary", "I learned this word",
+  "raise my proficiency", plus the equivalents in the user's language.
+- **Record shape** — point at the schema; note `id` is the filename
+  (`word-<slug>` or `word-<unix-ms>`), `proficiency` starts at `"new"`, and
+  `mastered` is host-computed (never write it directly).
+- **Operations** — record I/O via `manageCollection` (raw Read / Write / Edit
+  on `data/vocabulary/items/<id>.json` is the escape hatch):
+  - **Add** — generate an id, set `proficiency` to `"new"`, putItems with
+    `mode: "create"`.
+  - **List** — getItems (it includes the host-computed `mastered` value);
+    rather than dumping every word into chat, point the user at
+    `/collections/vocabulary`.
+  - **Update proficiency** — putItems with `mode: "merge"` and
+    `{ id, proficiency }` (merge keeps the fields the row omits).
+  - **Edit** — same: putItems `mode: "merge"` with just the changed fields.
+  - **Delete** — remove the JSON file.
+- After any change, call `presentCollection` with slug `vocabulary` (and the
+  record id) to render the result inline.
+
+## How it works for the learner
+
+- The **kanban view** groups by `proficiency` — four columns from `new` →
+  `mastered`. Dragging a card across promotes or demotes the word; the user can
+  run a spaced-review session entirely by dragging.
+- The agent can **bulk-add** words from a passage, a lesson, or a topic the user
+  is studying: extract the unfamiliar words, write one record each at
+  `proficiency: "new"`, fill in `meaning` and a natural `example` sentence.
+- For a **quiz**, the agent reads the items, picks words at the lower proficiency
+  levels, and uses `presentForm` (or just asks in chat) to test the user — then
+  bumps `proficiency` up for the ones they got right.
+- Because each word is its own file, the deck is fully diffable and portable;
+  the user owns it as plain JSON.
+
+## Extending it
+
+- Add a `partOfSpeech` enum (`noun` / `verb` / `adjective` / …) or a `tags`
+  field to group words by lesson or theme.
+- Add a `pronunciation` string (IPA or kana) for spoken practice.
+- Add a `dueDate` date plus `"calendarField": "dueDate"` to schedule spaced
+  repetition on the calendar.
+
+Keep additions minimal — the four core fields (`word`, `proficiency`,
+`meaning`, `example`) are enough to start learning today.

package/assets/helps/wiki.md

@@ -0,0 +1,168 @@
+# Wiki
+
+The wiki is a personal knowledge base that Claude builds and maintains as interconnected Markdown files in the workspace. It is available in the **General** role.
+
+The idea originated from [Andrej Karpathy's LLM Wiki pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f).
+
+## The Core Idea
+
+Most people's experience with LLMs and documents resembles RAG: upload files, retrieve relevant chunks at query time, generate answers. The LLM rediscovers knowledge from scratch on every question — there is no accumulation.
+
+The wiki is different. Instead of retrieving from raw documents at query time, Claude **incrementally builds and maintains a persistent wiki** — a structured, interlinked collection of Markdown files. When you add a new source, Claude doesn't just index it. It reads it, extracts key information, and integrates it into the existing wiki: updating entity pages, revising topic summaries, noting contradictions, strengthening synthesis.
+
+**The wiki is a persistent, compounding artifact.** Cross-references are already there. Contradictions are flagged. The synthesis reflects everything you've read. The wiki grows richer with every source and every question.
+
+You never write the wiki yourself — Claude writes and maintains all of it. You curate sources, explore, and ask questions. Claude does the summarizing, cross-referencing, filing, and bookkeeping.
+
+## What You Can Do With It
+
+- **Research**: go deep on a topic over weeks or months — reading papers, articles, reports, building a comprehensive wiki with an evolving thesis.
+- **Reading a book**: file each chapter as you go, building pages for characters, themes, plot threads, and connections.
+- **Personal knowledge**: track goals, health, self-improvement — file journal entries, articles, podcast notes, and build a structured picture over time.
+- **Business**: feed Slack threads, meeting transcripts, project documents into a wiki that stays current because Claude does the maintenance.
+
+## Your Role vs. Claude's Role
+
+**Your job**: curate sources, direct the analysis, ask good questions, think about what it all means.
+
+**Claude's job**: summarizing, cross-referencing, filing, updating pages, maintaining consistency, bookkeeping — everything that makes humans abandon wikis because the maintenance burden grows too fast.
+
+## Three Operations
+
+### Ingest
+
+Drop a source (article, URL, text) and ask Claude to process it.
+
+Claude will: read the source, identify key entities and concepts, create or update 5–15 wiki pages, add cross-references, append a log entry, and refresh the index. Show the updated index in the canvas when done.
+
+### Query
+
+Ask any question. Claude searches `data/wiki/index.md` for relevant pages, reads them, and synthesizes a grounded answer with citations. Good answers can be filed back into the wiki as new pages — a comparison you asked for, an analysis, a connection you discovered — so they don't disappear into chat history.
+
+### Lint
+
+Ask Claude to health-check the wiki. It scans for contradictions, stale claims, orphan pages, missing cross-references, and concepts that deserve their own page, then fixes issues automatically.
+
+## Chat About a Page
+
+Every wiki page has a built-in chat composer at the bottom. Ask a question, press send, and Claude starts a fresh chat session already pointed at that specific page — the agent reads the page first, then answers with that context loaded.
+
+This is one of the defining features of MulmoClaude. Your wiki is not a static archive: every page is a live entry point into a conversation with Claude about what's on it.
+
+Why it matters:
+
+- **Instant deep dive.** Open any page, ask _"how does this relate to X?"_ or _"summarize the main argument"_ or _"what would change if Y were false?"_ — no need to name the page or construct a prompt.
+- **Scoped grounding.** The prompt pins the page path, so Claude starts from that page rather than searching the index from scratch. Answers stay tight to the material you're actually looking at.
+- **Clean sessions.** Each question spawns its own chat, so spending half an hour drilling into one page doesn't pollute an existing working session. Good answers can be filed back into the wiki as their own pages.
+
+The composer appears on the standalone Wiki view (one of the top-level tabs). When a wiki page is embedded as a tool result inside another chat, that chat's own composer is used instead — no nested sessions.
+
+## Folder Layout
+
+```
+data/wiki/
+  index.md          ← catalog of all pages (title, one-line summary, last updated)
+  log.md            ← append-only chronological activity log
+  summary.md        ← compact key-topics list (loaded into every session as ambient context)
+  SCHEMA.md         ← conventions for page format, index updates, and log entries
+  pages/
+    <topic>.md      ← one page per entity, concept, or theme
+  sources/
+    <slug>.md       ← raw ingested sources (immutable after ingest)
+```
+
+## Page Format
+
+Each page is a plain Markdown file with YAML frontmatter:
+
+```markdown
+---
+title: Transformer Architecture
+created: 2026-04-05
+updated: 2026-04-05
+tags: [machine-learning, architecture, attention]
+---
+
+# Transformer Architecture
+
+Brief summary paragraph...
+
+## Key Concepts
+
+...
+
+## Related Pages
+
+- [[Attention Mechanism]]
+- [[BERT]]
+- [[GPT]]
+```
+
+Cross-references use `[[Page Name]]` wiki-link syntax. Slugs are lowercase, hyphen-separated (e.g. `transformer-architecture.md`).
+
+## `index.md` Format
+
+`data/wiki/index.md` is the catalog — one bullet per page using standard markdown link syntax with the slug embedded in the href. This format works both in-app (the canvas parses it) and in any plain markdown viewer (GitHub, VS Code preview, etc.).
+
+```markdown
+# Wiki Index
+
+## ページ一覧
+
+- [Transformer Architecture](pages/transformer-architecture.md) — foundational seq2seq model #ml #attention #architecture (2026-04-05)
+- [さくらインターネット](pages/sakura-internet.md) — 日本のクラウド事業者 #クラウド #日本企業 #データセンター (2026-04-06)
+- [ECharts DataZoom](pages/echarts-datazoom.md) — ズーム操作の仕組み #echarts #可視化 (2026-04-13)
+
+## タグ一覧
+
+- **AI**: [Transformer Architecture](pages/transformer-architecture.md), [さくらインターネット](pages/sakura-internet.md)
+- **日本企業**: [さくらインターネット](pages/sakura-internet.md)
+```
+
+Key rules:
+
+- Prefer bullet items as `[Title](pages/<slug>.md) — description #tag1 #tag2 (YYYY-MM-DD)` — avoid the `[[slug]]` wiki-link form. The canvas parser extracts the slug from the href so non-ASCII titles (日本語, etc.) keep a navigable slug. Markdown tables are also supported via the alternative format below, but the bullet form is easier to read in plain text and plays nicer with non-ASCII titles.
+- Slugs are lowercase ASCII, hyphen-separated. They match the page filename one-to-one (`pages/sakura-internet.md` → slug `sakura-internet`).
+- `#tag` tokens appear inline in the description (whitespace-bounded on the left). Tokens are extracted and indexed for the Wiki tag-filter UI. Tags accept any Unicode letter or digit (so `#クラウド`, `#可視化`, `#ai-agents` all work); `-` and `_` are allowed as internal joiners but not as the first character. Separate adjacent tags with a space — there is no right-hand boundary char, so `#クラウドデータ` parses as one tag.
+- Below the page list, include a "タグ一覧" / "Tags" section with the same `[Title](pages/<slug>.md)` link form so every mention is clickable.
+- Keep the index in sync with `pages/` — when you add a page, add a row; when you rename a file, update every link that points at it.
+- **The page list is a flat, recency-ordered log — do NOT group pages by category.** Prepend each new page's bullet at the top, not the bottom. When you update an existing page (content, description, tags) move its bullet to the top so the list reads as a journal of recent activity. A rename counts as an update: after fixing every link (see the sync rule above) move the renamed entry to the top. When you delete a page, remove its bullet from the page list **and** from any Tags-section groups that reference it — don't leave orphan mentions.
+- **Tags section: update the page list under each tag when pages are added / renamed / deleted, but do NOT reorder the tags themselves.** The "タグ一覧" / "Tags" section is a set of `- **Tag**: [Title](...), ...` groups — one bullet per tag, each listing every page that carries it. Preserve the existing tag order — don't sort by recency, and don't re-sort by frequency. A new tag gets appended at the end of the Tags section; an existing tag's order doesn't change just because one of its pages was updated.
+
+### Alternative table format
+
+If you prefer a table layout, the canvas also accepts a `Tags` column. Column names are matched by header (case-insensitive), so the order is flexible:
+
+```markdown
+| Slug | Title | Summary | Tags | Updated |
+|------|-------|---------|------|---------|
+| `transformer-architecture` | Transformer Architecture | foundational seq2seq model | ml, attention, architecture | 2026-04-05 |
+```
+
+Pre-existing 3- or 4-column tables (without a Tags header) keep parsing; their entries just have no tags.
+
+## Tag rules
+
+- A page's YAML frontmatter `tags:` field is the source of truth for that page's tags.
+- The tags recorded for that slug in `index.md` must match the frontmatter set exactly (order and case don't matter; we compare as a lowercased set).
+- The Lint button on the `/wiki` UI flags any mismatch as **Tag drift**. Fix by updating whichever side is stale.
+
+## Browsing the wiki
+
+Wiki page Writes/Edits the LLM performs render inline in the chat automatically — no extra display call needed.
+
+For browse / lint queries, point the user at the `/wiki` UI:
+
+- `/wiki` — the page catalog (with tag filters)
+- `/wiki/pages/<slug>` — a specific page
+- `/wiki/log` — the activity log
+- The Lint button on `/wiki` runs a health check
+
+## Relationship to `memory.md`
+
+|        | `memory.md`                              | `data/wiki/`                                |
+| ------ | ---------------------------------------- | ------------------------------------------- |
+| Scope  | Brief distilled facts, always in context | Deep structured knowledge, loaded on demand |
+| Growth | Intentionally small                      | Grows unboundedly                           |
+
+Over time, Claude can distill key insights from the wiki back into `memory.md` as compact ambient context for all roles.

package/assets/skills-preset/mc-cooking-coach/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: mc-cooking-coach
+description: Personal recipe book — save / read / update / delete cooking recipes as markdown files under `data/cooking/recipes/`, with a `README.md` index that lists every recipe. Use when the user asks to remember a recipe, look one up, or refine one.
+---
+
+# Cooking Coach
+
+A bundled MulmoClaude preset skill (`mc-` prefix = launcher-managed; do not edit
+this file in the workspace, it is overwritten on every server boot).
+
+Be the user's cooking-loving friend, not a librarian. Don't talk about file
+paths, frontmatter, or slugs — those exist behind the scenes; the user should
+never need to think about them. When suggesting substitutions or technique,
+keep it short and practical.
+
+## Where things live
+
+Recipes are plain markdown files at `data/cooking/recipes/<slug>.md`
+(cwd-relative — the agent runs with cwd = workspace, so every path in this
+file is plain cwd-relative). A `README.md` in the same directory is the
+catalogue — one bullet per recipe. You maintain both. The user should never
+need to know either path.
+
+## Workflow 1: save a new recipe
+
+**Triggers**: "ピーマンの肉詰めのレシピを保存して", "remember this lasagna",
+"こんど作る用に肉じゃがメモして".
+
+**Step 1 — distil before writing.** Ask follow-ups only if essential
+(ingredients you couldn't infer, servings if the user implied "for the family"
+etc.). Don't ping-pong on metadata; default `servings`, `prepTime`, `cookTime`
+to what the user said and skip them if they didn't say.
+
+**Step 2 — pick a kebab-case ASCII slug.** `ピーマンの肉詰め` → `stuffed-peppers`
+or `piman-no-nikuzume`. Use a romanised form even when the title is non-ASCII.
+
+The slug MUST match the pattern `^[a-z0-9]+(-[a-z0-9]+)*$` — lowercase ASCII
+letters / digits, single hyphens between segments only, no leading / trailing /
+consecutive hyphens, no whitespace, no punctuation (no apostrophes,
+parentheses, accents). Max 64 characters. If the romanisation has any of
+those, strip / replace them before saving. The strict pattern is also a
+**safety boundary**: it's how the delete workflow below stays free of shell-
+metacharacter concerns.
+
+If a recipe with that slug already exists, ask the user (don't overwrite
+without permission).
+
+**Step 3 — Write the recipe file** at `data/cooking/recipes/<slug>.md`:
+
+```markdown
+---
+title: ピーマンの肉詰め
+tags:
+  - 和食
+  - 主菜
+servings: 4
+prepTime: 15
+cookTime: 20
+restTime: 0
+created: 2026-05-11T12:00:00.000Z
+updated: 2026-05-11T12:00:00.000Z
+---
+
+## 材料
+
+- ピーマン 8個
+- 合いびき肉 300g
+- 玉ねぎ 1個
+- 卵 1個
+- パン粉、塩こしょう
+
+## 手順
+
+1. ピーマンを縦半分に切って種を取る
+2. 玉ねぎをみじん切りにして炒める
+3. ひき肉だねをピーマンに詰める
+4. フライパンで両面焼く
+
+## メモ
+
+味噌だれや甘酢あんかけにアレンジしてもよい。
+```
+
+Title can be in the user's language. Body convention: `## 材料` (or `## Ingredients`)
+as a bullet list with quantities, then `## 手順` (or `## Steps`) as a numbered list,
+then optional `## メモ` / `## Notes` / `## バリエーション` sections.
+
+`servings`, `prepTime`, `cookTime`, `restTime` are all integers (in minutes
+for the time fields) and all optional — omit if the user didn't volunteer
+them. `restTime` covers non-active time like marinating, chilling, proofing,
+resting — anything where the user isn't doing work; keep `cookTime` for
+active cooking only so totals stay accurate. `tags` is a free-form list.
+`created` and `updated` are ISO timestamps; on a fresh save they're the same.
+
+**Step 4 — regenerate `data/cooking/recipes/README.md`** (see "The README index"
+below).
+
+**Step 5 — confirm**: one sentence ("Saved as stuffed-peppers.") so the user
+sees the result without scrolling. Offer `generateImage` if the dish would
+benefit from a visual (plating, unfamiliar technique).
+
+## Workflow 2: recall / browse
+
+**Triggers**: "保存したレシピみせて", "肉詰めどう作ったっけ?", "what tag-thai
+recipes do I have?", "show me my recipes".
+
+**Single recipe**: Read `data/cooking/recipes/<slug>.md` and present it
+naturally — render the markdown in chat, don't dump raw frontmatter unless the
+user asks. If you don't know the slug, Read `data/cooking/recipes/README.md`
+first to find it.
+
+**All recipes / filtered**: Read `data/cooking/recipes/README.md` and answer
+from the index. If the user filters by tag ("和食 のレシピは?"), filter the
+bullets and respond conversationally — don't dump the whole README.
+
+## Workflow 3: update / delete
+
+**Update**: read the current file, apply the change, Write with the updated
+frontmatter:
+
+- `created` stays the same
+- `updated` advances to the current ISO timestamp
+- preserve every other frontmatter field unless the user explicitly asked to
+  change it (so a "bump cook time to 25 min" doesn't accidentally wipe tags)
+
+Then regenerate `README.md`.
+
+**Delete**: only when the user explicitly asks. **Re-validate the slug
+against `^[a-z0-9]+(-[a-z0-9]+)*$` BEFORE running the command** — if it
+fails the pattern, refuse and ask the user to confirm by name. When valid,
+quote the path even though the slug pattern already excludes shell
+metacharacters (belt + braces):
+
+```bash
+rm "data/cooking/recipes/<slug>.md"
+```
+
+Then regenerate `README.md`. Confirm afterward.
+
+## Workflow 4: visualise
+
+When the user asks "how does it look?" / "写真みせて" / a step is hard to
+follow without a picture, call `generateImage` with a prompt focused on the
+finished dish — appetising, well-lit, top-down or 3/4 plating shot. One image
+per request unless they ask for variations.
+
+## The README index — keep it current
+
+After every save / update / delete, regenerate `data/cooking/recipes/README.md`
+from the recipe files currently in the directory. Enumerate with the Files
+tool, or with Bash. **The enumeration MUST exclude `README.md` itself** —
+otherwise the index treats its own catalogue as a recipe and emits a
+self-referential entry. Convenient form:
+
+```bash
+find data/cooking/recipes -maxdepth 1 -type f -name '*.md' ! -name 'README.md' | sort
+```
+
+(`find` over `ls *.md` so an empty directory after a delete doesn't error out
+on the glob — also keeps the README exclusion explicit.)
+
+Then Read each frontmatter you don't already know.
+
+Format:
+
+```markdown
+# レシピ一覧
+
+`data/cooking/recipes/` の中身。MulmoClaude が自動更新するので手で編集する場合は
+保存後に更新されることを覚えておいてください。
+
+## 主菜
+
+- [ピーマンの肉詰め](stuffed-peppers.md) — 和食 / 4 人分 / 15 + 20 分
+- [ラザニア](lasagna.md) — イタリアン / 6 人分 / 30 + 60 分
+
+## 副菜・スープ
+
+- [豚汁](tonjiru.md) — 和食 / 4 人分 / 10 + 20 分
+
+## デザート
+
+- [チョコレートムース](chocolate-mousse.md) — フレンチ / 4 人分 / 20 分 + 冷却 120 分
+
+## (タグ未分類)
+
+- [おにぎり](onigiri.md) — 4 人分 / 15 分
+```
+
+Rules for the README:
+
+- **Group by primary tag** (the first item in the recipe's `tags`) when there's
+  a meaningful taxonomy in use; fall back to "(タグ未分類)" otherwise.
+- **One bullet per recipe**: `[Title](slug.md) — tags / servings / time`.
+  Use long-form units in the user's language (人分, 分, mins, etc.). The
+  time column composes `prepTime + cookTime` (active time only) plus a
+  trailing `+ rest <restTime> 分` suffix when `restTime` is present. Examples:
+    - all three set: `15 + 20 分 + 冷却 120 分`
+    - prepTime + cookTime only: `35 分`
+    - restTime only: `冷却 120 分`
+    - none set: omit the time column entirely
+  Tags are slash-joined.
+- **Don't include `created` / `updated` dates** — they're noisy and rarely
+  what the user wants to scan for.
+- **Alphabetical within each group** by display title (Japanese / English
+  collation as it falls out — don't over-engineer).
+- **Keep the opening paragraph** explaining MulmoClaude maintains it (one
+  short sentence).
+
+If the directory is empty after a delete, write a single-line README pointing
+at "(まだレシピがありません)" so the user can tell at a glance.
+
+## Tone
+
+Conversational. The user is your cooking friend, not your customer. When you
+suggest a substitution, do it with a one-line "why" ("the lime brightens it —
+lemon works but skews sour"). Don't recite culinary trivia unless asked.