[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FVJ5N2X93KBEV41WYWQB2":3,"skill-same:01M70FVJ5N2X93KBEV41WYWQB2":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M70FVJ5N2X93KBEV41WYWQB2","cook",null,"The core knowledge compilation skill. Reads raw notes and external sources, then distills them into structured, cross-referenced knowledge pages in entities\u002F, concepts\u002F, comparisons\u002F, and queries\u002F. Keeps SCHEMA.md tag and domain taxonomy in sync when new tags or domains appear. Use this skill whenever the user mentions compiling notes, digesting material, updating the knowledge base, running a cook cycle, or says anything like \"process my notes\", \"compile this\", \"add this to the wiki\", \"what's new in my notes\", or \"update knowledge pages\". Also activate when the user pastes external content and wants it integrated into the knowledge base.","JayJiangCT\u002Fknowlery","JayJiangCT","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F59813406?v=4","01M70FV52GQJT4F12FBSYG48R2","Jay Jiang","01M70FV536R3NCMG5ZB0TMEWNP",15,"MIT","https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fcook\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"update knowledge","core","domain","running","add","compiling","concepts","my","sync","update","knowledge base","notes","activate","when","wiki","knowledge","domains","cycle","sources","2026-11-10 10:12:30",false,"---\nname: cook\ndescription: >\n  The core knowledge compilation skill. Reads raw notes and external sources, then\n  distills them into structured, cross-referenced knowledge pages in entities\u002F, concepts\u002F,\n  comparisons\u002F, and queries\u002F. Keeps SCHEMA.md tag and domain taxonomy in sync when new\n  tags or domains appear. Use this skill whenever the user mentions compiling notes,\n  digesting material, updating the knowledge base, running a cook cycle, or says anything\n  like \"process my notes\", \"compile this\", \"add this to the wiki\", \"what's new in my notes\",\n  or \"update knowledge pages\". Also activate when the user pastes external content and wants\n  it integrated into the knowledge base.\n---\n\n# \u002Fcook — Knowledge Compilation\n\nYou are a knowledge compiler. Your job is to read raw material (user notes, external sources)\nand distill it into structured, cross-referenced knowledge pages.\n\n## Parameters\n\n- **target** (optional): What to cook. Default: incremental (new\u002Fmodified notes since last cook).\n  - `--all` or `full`: Read all user notes in the vault\n  - `\"Topic Name\"`: Read notes matching this keyword\n  - `path\u002Fto\u002Fnote.md`: Read a specific note\n  - `\u003CURL>`: Fetch external article and digest it\n\n## Input Scope\n\n### Incremental Mode (default)\n\nWhen user runs `\u002Fcook` with no arguments, get the scope from the deterministic\nstaleness report (first transport available). If the knowlery MCP `stale` tool\nis present, call it with the KB name — it is the same report; otherwise:\n\n```bash\nobsidian knowlery:stale\n# or, with Obsidian closed:\nknowlery stale\n# or, with only Node available:\nnode .knowlery\u002Fbin\u002Fquery.mjs --stale\n```\n\nThe report has three parts:\n\n1. **Stale pages** — compiled pages whose cited sources changed after the page was\n   last written. Re-read only the listed changed sources and fold what changed into\n   those pages.\n2. **Uncooked notes** — user notes cited by no compiled page, most recent first. These\n   are candidate new material; use judgment (or ask) about which are worth compiling —\n   many notes are legitimately never compiled. Notes under `inbox\u002F` are the exception:\n   they were captured from conversations (MCP `capture`) precisely to be compiled —\n   treat them as first-priority cook material. Notes under installed bundles\n   (`Library\u002F`) and under reference directories (`referenceDirs` in\n   `.knowlery\u002Fconfig.json`, e.g. an imported team KB) are never listed here —\n   if a whole directory of external material shows up as uncooked, suggest\n   `knowlery reference add \u003Cdir>` instead of cooking it.\n3. **Dangling sources** — pages citing notes that no longer exist. Mention them in the\n   report; fixing them is \u002Faudit territory.\n\n**Jev-ranked uncooked notes.** When the user has configured a Jev key (in the\nKnowlery plugin settings, or as `TYPESAFE_API_KEY` in their shell), uncooked notes carry a `jev` field — `{ worth, target }` in JSON, `jev 0.92 → update\n\u003Cpage>` in text — read from `.knowlery\u002Ftriage.json`; the list is then ordered scored\nnotes by `worth` first, unscored notes most-recent-first, and notes Jev rates ≤ 0.2\nlast. `worth` is the probability, from the note's title, frontmatter and first lines,\nthat it holds durable knowledge; `target` is the compiled page Jev judged to be about\nthe same subject (null = a new page is the better fit). Use it to decide where to\nstart, not what to skip: work down the list in order, open `target` before creating\na new page and fold the note in if the subject really matches, and still glance at the\n≤ 0.2 band — a short preview can miss a decision buried further down. Never ask the\nuser for the key and never call Jev yourself; the scores arrive through the report.\n`stale` only tops up 40 unscored notes per call, so when most of a long list is\nunscored, suggest `knowlery triage` (scores the whole backlog, about $0.0001 a note)\nrather than running it — it spends the user's money, so it is their call.\n\nNote: sync tools can rewrite file mtimes and produce a large stale list at once; that\nis expected — cook selectively rather than mechanically.\n\n**Fallback (degraded mode).** Only if neither transport is available: scan for `.md`\nfiles outside agent directories modified since the last entry in `log.md`, and say\nscope detection ran in degraded mode.\n\n### Full Mode\n\nWhen user runs `\u002Fcook --all`:\n- Read all user notes in the vault. Exclude what the staleness report excludes:\n  `entities\u002F`, `concepts\u002F`, `comparisons\u002F`, `queries\u002F`, `Library\u002F`, reference\n  directories and ignored directories (`referenceDirs` \u002F `ignoreDirs` in\n  `.knowlery\u002Fconfig.json`), and the directories `knowlery health` lists under\n  \"Skipped directories\" (`node_modules\u002F`, build output beside a project manifest)\n- Re-evaluate all entities and concepts\n\n### Targeted Mode\n\nWhen user runs `\u002Fcook \"Feature A\"` or `\u002Fcook path\u002Fto\u002Fnote.md`:\n- Read only the specified notes or notes matching the keyword\n\n### External URL\n\nWhen user provides a URL:\n1. Fetch content using WebFetch or Obsidian Web Clipper\n2. Save as a user note in the vault (ask the user where to save, or use a sensible default like the vault root with a descriptive filename: `\u003Cslug>.md`)\n3. Add frontmatter: `title`, `source_url`, `fetched` date\n4. Process normally — the saved note becomes raw material for \u002Fcook\n\n**Note:** No dedicated `raw\u002F` directory. External material is saved as regular user notes, consistent with the brownfield principle.\n\n## Processing Pipeline\n\n### Step 1: Read & Parse\n- Read all target notes\n- Extract frontmatter, content, wikilinks\n- Identify entities (named things), concepts (abstract ideas), decisions, contradictions\n\n### Step 2: Match Against Existing Pages\n- Find existing pages by running the retrieval engine on the candidate entity and concept names (`obsidian knowlery:query question=\"\u003Cnames>\"` — the same ladder **`\u002Fask`** uses), or `obsidian properties` by `type` for a fast listing; `INDEX.base` is a human preview, not a lookup\n- Determine: create new vs. update existing\n- Read `SCHEMA.md` (Obsidian CLI) for current tag and domain taxonomy so new pages prefer existing tags when they fit\n\n### Step 3: Create\u002FUpdate Pages\n- **New entities:** Create in `entities\u002F\u003Cname>.md`\n- **New concepts:** Create in `concepts\u002F\u003Cname>.md`\n- **Updates:** Add new information, bump `updated` date\n- **Contradictions:** Follow Update Policy\n\n**Record aliases (retrieval-aware compiling).** Lexical retrieval can only match what\nis written down. On every page you create or update, record into `aliases` frontmatter:\n\n- colloquial or team nicknames (\"colld\" for the collector daemon)\n- abbreviations and acronyms (SLO, p95)\n- the **cross-language title** whenever the sources are in a different language than\n  the page (a page compiled from Chinese notes gets its Chinese name as an alias, and\n  vice versa)\n\n**Create page thresholds:**\n- Appears in 2+ notes, OR is central subject of one note\n- Do NOT create for: passing mentions, minor details, out-of-domain topics\n\n**Writing tool (by operation, not by environment):** full knowledge pages are long\nand carry code blocks and quotes — write the `.md` file directly at its exact path\n(`entities\u002F\u003Cname>.md`, …); Obsidian indexes new files automatically. Use\n`obsidian append` for small content additions, `obsidian property:set` for\nfrontmatter field updates on existing pages,\nand `obsidian rename` for renames\u002Fmoves (it rewrites wikilinks across the vault).\nIf you use `obsidian create` for a short page, pass `path=` (not just `name=`) so\nit lands in the right directory — and if it fails on content escaping, write the\nfile directly instead of fighting the shell. In headless environments, write files\ndirectly. Either way, run `knowlery health` (or `node .knowlery\u002Fbin\u002Fquery.mjs\n--stale`) after bulk changes to verify the result.\n\n### Step 4: Cross-Reference\n- Ensure every new\u002Fupdated page has at least 2 outbound wikilinks\n- Check existing pages link back where relevant\n\n### Step 5: Sync SCHEMA.md\nAfter Step 3–4, reconcile agent pages touched this cycle with `SCHEMA.md`:\n\n- Re-read `SCHEMA.md` if you have not just read it.\n- If **any** new or updated agent page uses a `tag` not listed under **Current Tags** (or **Domain Taxonomy** \u002F **Knowledge Domains** for a new `domain` value), **update `SCHEMA.md`** (a small structured edit — edit the file directly or via Obsidian CLI): add the missing tag(s) or domain line(s), keep lists alphabetically sorted where the file already uses lists, and **preserve** unrelated sections and the user's prose.\n- If every tag and domain on those pages already appears in `SCHEMA.md`, **do not** rewrite the file.\n- Do **not** remove tags or domains from `SCHEMA.md` during \u002Fcook unless the user explicitly asked to prune taxonomy.\n- Stay consistent with SCHEMA rules: singular tags, 2–5 tags per page on agent pages, new tags documented here before (or as soon as) use.\n\n### Step 6: Update Navigation\n- `INDEX.base` (the human preview of compiled pages) stays current in Obsidian on its own via its Base query — nothing to maintain; only if views, filters, or columns need tuning after large cooks, edit the file per the **obsidian-bases** skill\n- Append entry to `log.md` (human-readable history only — incremental scope comes from the staleness report, never from this file)\n\n### Step 7: Report\nPresent structured summary (see Output Report Format below). Mention `SCHEMA.md` when you added tags or domains, or say it was unchanged.\n\n## Contradiction Handling\n\n### Detection\n- Compare claims across notes about the same entity\u002Fconcept\n- Check dates — newer claims may supersede older\n- Look for explicit contradictions (e.g., \"we changed from X to Y\")\n\n### Resolution Workflow\n1. Note both positions with dates and source references\n2. Mark in frontmatter: `contradictions: [page-name]`\n3. Report to user with specific sources\n4. Offer to create a comparison page\n5. User decides\n\n### Update Policy\n- Newer sources generally supersede older\n- If both positions still valid (e.g., A\u002FB testing), note both\n- Never silently overwrite — always flag for review\n\n## Output Report Format\n\n```\nCook complete. Here's what changed:\n\nNew knowledge:\n• [[feature-a]] — Response time monitoring feature\n• [[response-time-metrics]] — Why median replaced avg\n\nUpdated:\n• [[zhang-san]] — Added Feature A assignment\n\nContradiction found:\n⚠ PRD says avg(response_time) > baseline, but experiment notes say median\n  Sources: Projects\u002FFeature-A-PRD.md vs Daily\u002F2026-04-05.md\n  Want me to create a comparison page?\n\nLog: 1 entry added to log.md\nSCHEMA.md: added tags: observability, backend (or: SCHEMA.md — no taxonomy changes)\n```\n\n**Design principles:**\n- Natural language, no technical jargon\n- Structured for quick scanning\n- Actionable (asks for decisions on contradictions)\n- Wikilinks for easy navigation\n\n## Auto-Trigger Behavior\n\nThe Agent should automatically run `\u002Fcook` after:\n- Writing a note (brief report: \"Cooked 1 note. Updated [[x]], created [[y]].\")\n- User drops new files into the vault\n\n**When NOT to auto-trigger:**\n- Rapid-fire note creation (batch and cook once at the end)\n- `\u002Fcook` was already run in the last 5 minutes\n\n## Agent Page Identification\n\nAgent pages are identified by directory:\n| Location | Ownership |\n|----------|-----------|\n| `entities\u002F**\u002F*.md` | Agent |\n| `concepts\u002F**\u002F*.md` | Agent |\n| `comparisons\u002F**\u002F*.md` | Agent |\n| `queries\u002F**\u002F*.md` | Agent |\n| All other `.md` | User (read-only during \u002Fcook) |\n\nNo `owner` frontmatter field needed.\n\n## Key Principles\n\n- **Evidence-based**: Every knowledge page cites its sources\n- **Never modify user notes**: User notes are read-only during \u002Fcook\n- **Aliases are retrieval**: Record nicknames, abbreviations, and cross-language titles in `aliases` — a name that is not written down cannot be found\n- **SCHEMA.md stays accurate**: New tags or domains on agent pages are reflected in `SCHEMA.md` in the same cook cycle when possible\n- **Thresholds matter**: 2+ mentions or central subject to create a page\n- **Split at 200 lines**: Break large pages into sub-topics\n- **Flag contradictions**: Never silently overwrite\n","# \u002Fcook — Knowledge Compilation\n\nYou are a knowledge compiler. Your job is to read raw material (user notes, external sources)\nand distill it into structured, cross-referenced knowledge pages.\n\n## Parameters\n\n- **target** (optional): What to cook. Default: incremental (new\u002Fmodified notes since last cook).\n  - `--all` or `full`: Read all user notes in the vault\n  - `\"Topic Name\"`: Read notes matching this keyword\n  - `path\u002Fto\u002Fnote.md`: Read a specific note\n  - `\u003CURL>`: Fetch external article and digest it\n\n## Input Scope\n\n### Incremental Mode (default)\n\nWhen user runs `\u002Fcook` with no arguments, get the scope from the deterministic\nstaleness report (first transport available). If the knowlery MCP `stale` tool\nis present, call it with the KB name — it is the same report; otherwise:\n\n```bash\nobsidian knowlery:stale\n# or, with Obsidian closed:\nknowlery stale\n# or, with only Node available:\nnode .knowlery\u002Fbin\u002Fquery.mjs --stale\n```\n\nThe report has three parts:\n\n1. **Stale pages** — compiled pages whose cited sources changed after the page was\n   last written. Re-read only the listed changed sources and fold what changed into\n   those pages.\n2. **Uncooked notes** — user notes cited by no compiled page, most recent first. These\n   are candidate new material; use judgment (or ask) about which are worth compiling —\n   many notes are legitimately never compiled. Notes under `inbox\u002F` are the exception:\n   they were captured from conversations (MCP `capture`) precisely to be compiled —\n   treat them as first-priority cook material. Notes under installed bundles\n   (`Library\u002F`) and under reference directories (`referenceDirs` in\n   `.knowlery\u002Fconfig.json`, e.g. an imported team KB) are never listed here —\n   if a whole directory of external material shows up as uncooked, suggest\n   `knowlery reference add \u003Cdir>` instead of cooking it.\n3. **Dangling sources** — pages citing notes that no longer exist. Mention them in the\n   report; fixing them is \u002Faudit territory.\n\n**Jev-ranked uncooked notes.** When the user has configured a Jev key (in the\nKnowlery plugin settings, or as `TYPESAFE_API_KEY` in their shell), uncooked notes carry a `jev` field — `{ worth, target }` in JSON, `jev 0.92 → update\n\u003Cpage>` in text — read from `.knowlery\u002Ftriage.json`; the list is then ordered scored\nnotes by `worth` first, unscored notes most-recent-first, and notes Jev rates ≤ 0.2\nlast. `worth` is the probability, from the note's title, frontmatter and first lines,\nthat it holds durable knowledge; `target` is the compiled page Jev judged to be about\nthe same subject (null = a new page is the better fit). Use it to decide where to\nstart, not what to skip: work down the list in order, open `target` before creating\na new page and fold the note in if the subject really matches, and still glance at the\n≤ 0.2 band — a short preview can miss a decision buried further down. Never ask the\nuser for the key and never call Jev yourself; the scores arrive through the report.\n`stale` only tops up 40 unscored notes per call, so when most of a long list is\nunscored, suggest `knowlery triage` (scores the whole backlog, about $0.0001 a note)\nrather than running it — it spends the user's money, so it is their call.\n\nNote: sync tools can rewrite file mtimes and produce a large stale list at once; that\nis expected — cook selectively rather than mechanically.\n\n**Fallback (degraded mode).** Only if neither transport is available: scan for `.md`\nfiles outside agent directories modified since the last entry in `log.md`, and say\nscope detection ran in degraded mode.\n\n### Full Mode\n\nWhen user runs `\u002Fcook --all`:\n- Read all user notes in the vault. Exclude what the staleness report excludes:\n  `entities\u002F`, `concepts\u002F`, `comparisons\u002F`, `queries\u002F`, `Library\u002F`, reference\n  directories and ignored directories (`referenceDirs` \u002F `ignoreDirs` in\n  `.knowlery\u002Fconfig.json`), and the directories `knowlery health` lists under\n  \"Skipped directories\" (`node_modules\u002F`, build output beside a project manifest)\n- Re-evaluate all entities and concepts\n\n### Targeted Mode\n\nWhen user runs `\u002Fcook \"Feature A\"` or `\u002Fcook path\u002Fto\u002Fnote.md`:\n- Read only the specified notes or notes matching the keyword\n\n### External URL\n\nWhen user provides a URL:\n1. Fetch content using WebFetch or Obsidian Web Clipper\n2. Save as a user note in the vault (ask the user where to save, or use a sensible default like the vault root with a descriptive filename: `\u003Cslug>.md`)\n3. Add frontmatter: `title`, `source_url`, `fetched` date\n4. Process normally — the saved note becomes raw material for \u002Fcook\n\n**Note:** No dedicated `raw\u002F` directory. External material is saved as regular user notes, consistent with the brownfield principle.\n\n## Processing Pipeline\n\n### Step 1: Read & Parse\n- Read all target notes\n- Extract frontmatter, content, wikilinks\n- Identify entities (named things), concepts (abstract ideas), decisions, contradictions\n\n### Step 2: Match Against Existing Pages\n- Find existing pages by running the retrieval engine on the candidate entity and concept names (`obsidian knowlery:query question=\"\u003Cnames>\"` — the same ladder **`\u002Fask`** uses), or `obsidian properties` by `type` for a fast listing; `INDEX.base` is a human preview, not a lookup\n- Determine: create new vs. update existing\n- Read `SCHEMA.md` (Obsidian CLI) for current tag and domain taxonomy so new pages prefer existing tags when they fit\n\n### Step 3: Create\u002FUpdate Pages\n- **New entities:** Create in `entities\u002F\u003Cname>.md`\n- **New concepts:** Create in `concepts\u002F\u003Cname>.md`\n- **Updates:** Add new information, bump `updated` date\n- **Contradictions:** Follow Update Policy\n\n**Record aliases (retrieval-aware compiling).** Lexical retrieval can only match what\nis written down. On every page you create or update, record into `aliases` frontmatter:\n\n- colloquial or team nicknames (\"colld\" for the collector daemon)\n- abbreviations and acronyms (SLO, p95)\n- the **cross-language title** whenever the sources are in a different language than\n  the page (a page compiled from Chinese notes gets its Chinese name as an alias, and\n  vice versa)\n\n**Create page thresholds:**\n- Appears in 2+ notes, OR is central subject of one note\n- Do NOT create for: passing mentions, minor details, out-of-domain topics\n\n**Writing tool (by operation, not by environment):** full knowledge pages are long\nand carry code blocks and quotes — write the `.md` file directly at its exact path\n(`entities\u002F\u003Cname>.md`, …); Obsidian indexes new files automatically. Use\n`obsidian append` for small content additions, `obsidian property:set` for\nfrontmatter field updates on existing pages,\nand `obsidian rename` for renames\u002Fmoves (it rewrites wikilinks across the vault).\nIf you use `obsidian create` for a short page, pass `path=` (not just `name=`) so\nit lands in the right directory — and if it fails on content escaping, write the\nfile directly instead of fighting the shell. In headless environments, write files\ndirectly. Either way, run `knowlery health` (or `node .knowlery\u002Fbin\u002Fquery.mjs\n--stale`) after bulk changes to verify the result.\n\n### Step 4: Cross-Reference\n- Ensure every new\u002Fupdated page has at least 2 outbound wikilinks\n- Check existing pages link back where relevant\n\n### Step 5: Sync SCHEMA.md\nAfter Step 3–4, reconcile agent pages touched this cycle with `SCHEMA.md`:\n\n- Re-read `SCHEMA.md` if you have not just read it.\n- If **any** new or updated agent page uses a `tag` not listed under **Current Tags** (or **Domain Taxonomy** \u002F **Knowledge Domains** for a new `domain` value), **update `SCHEMA.md`** (a small structured edit — edit the file directly or via Obsidian CLI): add the missing tag(s) or domain line(s), keep lists alphabetically sorted where the file already uses lists, and **preserve** unrelated sections and the user's prose.\n- If every tag and domain on those pages already appears in `SCHEMA.md`, **do not** rewrite the file.\n- Do **not** remove tags or domains from `SCHEMA.md` during \u002Fcook unless the user explicitly asked to prune taxonomy.\n- Stay consistent with SCHEMA rules: singular tags, 2–5 tags per page on agent pages, new tags documented here before (or as soon as) use.\n\n### Step 6: Update Navigation\n- `INDEX.base` (the human preview of compiled pages) stays current in Obsidian on its own via its Base query — nothing to maintain; only if views, filters, or columns need tuning after large cooks, edit the file per the **obsidian-bases** skill\n- Append entry to `log.md` (human-readable history only — incremental scope comes from the staleness report, never from this file)\n\n### Step 7: Report\nPresent structured summary (see Output Report Format below). Mention `SCHEMA.md` when you added tags or domains, or say it was unchanged.\n\n## Contradiction Handling\n\n### Detection\n- Compare claims across notes about the same entity\u002Fconcept\n- Check dates — newer claims may supersede older\n- Look for explicit contradictions (e.g., \"we changed from X to Y\")\n\n### Resolution Workflow\n1. Note both positions with dates and source references\n2. Mark in frontmatter: `contradictions: [page-name]`\n3. Report to user with specific sources\n4. Offer to create a comparison page\n5. User decides\n\n### Update Policy\n- Newer sources generally supersede older\n- If both positions still valid (e.g., A\u002FB testing), note both\n- Never silently overwrite — always flag for review\n\n## Output Report Format\n\n```\nCook complete. Here's what changed:\n\nNew knowledge:\n• [[feature-a]] — Response time monitoring feature\n• [[response-time-metrics]] — Why median replaced avg\n\nUpdated:\n• [[zhang-san]] — Added Feature A assignment\n\nContradiction found:\n⚠ PRD says avg(response_time) > baseline, but experiment notes say median\n  Sources: Projects\u002FFeature-A-PRD.md vs Daily\u002F2026-04-05.md\n  Want me to create a comparison page?\n\nLog: 1 entry added to log.md\nSCHEMA.md: added tags: observability, backend (or: SCHEMA.md — no taxonomy changes)\n```\n\n**Design principles:**\n- Natural language, no technical jargon\n- Structured for quick scanning\n- Actionable (asks for decisions on contradictions)\n- Wikilinks for easy navigation\n\n## Auto-Trigger Behavior\n\nThe Agent should automatically run `\u002Fcook` after:\n- Writing a note (brief report: \"Cooked 1 note. Updated [[x]], created [[y]].\")\n- User drops new files into the vault\n\n**When NOT to auto-trigger:**\n- Rapid-fire note creation (batch and cook once at the end)\n- `\u002Fcook` was already run in the last 5 minutes\n\n## Agent Page Identification\n\nAgent pages are identified by directory:\n| Location | Ownership |\n|----------|-----------|\n| `entities\u002F**\u002F*.md` | Agent |\n| `concepts\u002F**\u002F*.md` | Agent |\n| `comparisons\u002F**\u002F*.md` | Agent |\n| `queries\u002F**\u002F*.md` | Agent |\n| All other `.md` | User (read-only during \u002Fcook) |\n\nNo `owner` frontmatter field needed.\n\n## Key Principles\n\n- **Evidence-based**: Every knowledge page cites its sources\n- **Never modify user notes**: User notes are read-only during \u002Fcook\n- **Aliases are retrieval**: Record nicknames, abbreviations, and cross-language titles in `aliases` — a name that is not written down cannot be found\n- **SCHEMA.md stays accurate**: New tags or domains on agent pages are reflected in `SCHEMA.md` in the same cook cycle when possible\n- **Thresholds matter**: 2+ mentions or central subject to create a page\n- **Split at 200 lines**: Break large pages into sub-topics\n- **Flag contradictions**: Never silently overwrite\n",{"name":5,"description":7},"main","0e53802c0c332ab23445b83651f15999e1ac89b8","plugin\u002Fskills\u002Fcook",1,"https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery","https:\u002F\u002Fgithub.com\u002FJayJiangCT","2026-11-09 16:04:29",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add JayJiangCT\u002Fknowlery --skill cook",{"tool":61,"command":62},"bunx","bunx skills add JayJiangCT\u002Fknowlery --skill cook",{"tool":64,"command":65},"pnpm","pnpm dlx skills add JayJiangCT\u002Fknowlery --skill cook","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fcook\u002FSKILL.md",true,[],[70,86,106,125,156,172],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":43},"01M70FWHK80WMW5C9Y12KEZ8RG","vault-conventions","Use when creating or modifying notes in a Knowlery-structured vault. Enforces frontmatter requirements, wikilinks, and naming conventions.","https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fvault-conventions\u002FSKILL.md",[],[77,78,79,35,80,81,82,37,83,84,85],"vault","vault conventions","conventions","naming","use","naming conventions","frontmatter","requirements","structured",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":43},"01M70FWF616X3Z6BPPW6A96VHT","organize","Directory organization based on frontmatter metadata. Suggests and applies file moves to keep the vault structured. Use when the user wants to reorganize notes, fix directory placement, clean up the vault structure, or says anything like \"organize my notes\", \"clean up the vault\", \"move files to the right folders\", \"tidy up\", or \"restructure my notes\".","https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Forganize\u002FSKILL.md",[],[88,93,94,95,96,97,98,81,37,99,100,35,101,77,102,103,31,83,104,105],"move","up","fix","clean","tidy","files","keep","file","structure","organization","directory","user","metadata",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":115,"publishedAt":43},"01M70FWC3VG73VJD8C56SEPM3X","obsidian-markdown","Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax. Use when working with .md files in Obsidian, or when the user mentions wikilinks, callouts, frontmatter, tags, embeds, or Obsidian notes.","https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fobsidian-markdown\u002FSKILL.md",[112],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",[116,117,118,98,81,37,119,120,121,35,122,123,124,83,104],"obsidian","obsidian markdown","markdown","tags","with","create","properties","edit","syntax",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":139,"publishedAt":43},"01M70FW95K6BD12KQERZS0FWHW","obsidian-cli","Interact with Obsidian vaults using the Obsidian CLI to read, create, search, and manage notes, tasks, properties, and more. Also supports plugin and theme development with commands to reload plugins, run JavaScript, capture errors, take screenshots, and inspect the DOM. Use when the user asks to interact with their Obsidian vault, manage notes, search vault content, perform vault operations from the command line, or develop and debug Obsidian plugins and themes.","https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fobsidian-cli\u002FSKILL.md",[131,136],{"categoryNo":132,"categoryName":133,"taxonomyType":134,"taxonomyTypeDesc":135},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":137,"categoryName":138,"taxonomyType":134,"taxonomyTypeDesc":135},"01JBSEEDCAT000000000000036","内容创作者",[116,140,141,142,143,144,145,37,146,121,35,147,148,149,150,151,152,153,154,155],"cli","obsidian cli","inspect","search","errors","themes","tasks","command","run","line","read","commands","take","vaults","screenshots","theme",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":43},"01M70FW75P9SEH28NWR115GZNN","obsidian-bases","Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries. Use when working with .base files, creating database-like views of notes, or when the user mentions Bases, table views, card views, filters, or formulas in Obsidian.","https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fobsidian-bases\u002FSKILL.md",[],[116,163,164,165,166,98,167,81,168,37,120,121,35,169,123,170,104,171],"obsidian bases","bases","formulas","card","filters","database","summaries","base","table",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":43},"01M70FW4ASRQ42NW1AC0AAWWAC","knowlery-mcp","Work a Knowlery knowledge base through its MCP tools — choose the right tool for the job, run the capture-to-cook loop, and behave well while doing it. Use when Knowlery MCP tools (query, capture, stale, health, init_kb, register_kb, sync, list_kbs, list_bundles) are available in the session, especially in clients without a shell.","https:\u002F\u002Fgithub.com\u002FJayJiangCT\u002Fknowlery\u002Fblob\u002Fmain\u002Fplugin\u002Fskills\u002Fknowlery-mcp\u002FSKILL.md",[178],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[180,181,182,183,184,185,186,187,188,189,39,81,190,37,191,192,34,193,148,194],"knowlery mcp","MCP","kb","register","for","choose","session","tool","behave","init","loop","query","health","work","shell"]