Update to Clawnify

{
  "description": "Turn a dump of raw company files into a clean, foldered, citable Company Knowledge corpus — the company's brain. Use when the user has dropped many files into the Company Knowledge section (or connected a Drive) and wants the agent to distill and organize them: cluster by topic, distill each into a canonical markdown doc (merging across sources into reusable playbooks), file it into a folder, tag and link it, and propose it for review.",
  "included_files": [],
  "name": "organize-company-knowledge",
  "skill_md_contents": "---\nname: organize-company-knowledge\ndescription: >-\n  Turn a dump of raw company files into a clean, foldered, citable Company\n  Knowledge corpus — the company's brain. Use when the user has dropped many\n  files into the Company Knowledge section (or connected a Drive) and wants the\n  agent to distill and organize them: cluster by topic, distill each into a\n  canonical markdown doc (merging across sources into reusable playbooks), file\n  it into a folder, tag and link it, and propose it for review.\nmetadata:\n  clawnify:\n    displayName: Organize my knowledge\n    trigger: manual\n    inputs: []\n---\n\n# Organize Company Knowledge\n\nThe user dumped a pile of files and wants them turned into the company's\n**brain** — organized, official Company Knowledge that every agent can draw on\nand cite. Your job is to **curate, not mirror**: distill the material that is\n*answer authority or reusable know-how* (policies, pricing, brand, SOPs, product\nfacts, FAQs, legal — **and the playbooks hidden inside the company's own\ndeliverables**) into a small set of clean markdown docs, each filed into the\nright folder and linked to its neighbours — then hand the result to a human to\npublish.\n\nNothing you create goes live automatically. You **propose**; a person reviews\nand publishes from the dashboard.\n\n## The mental model (read this first)\n\n- **This builds the company brain, not a client filing cabinet.** Company\n  Knowledge is the org-wide corpus every agent retrieves from and cites (`Per\n  <Title> v<N>`). The goal of organizing a dump is to grow that shared brain.\n  Almost everything answer-authority or reusable belongs here.\n\n- **Deliverables are the richest brain material — distill the PATTERN, not the\n  client.** An agency's dump is mostly *deliverables*: proposals, strategies,\n  case studies, decks. A single raw proposal is not company fact — but the\n  **pattern across all of them** (\"how we structure a winning proposal\", \"how we\n  run a festival digital strategy\") is exactly the company's intelligence, and it\n  IS citable. So **cluster deliverables across clients into canonical playbooks**\n  — ONE \"Proposal Playbook\" distilled from seventeen proposals, not seventeen\n  client-named docs. Strip the client-specific numbers; keep the reusable method.\n\n- **Client-scoped facts are the rare exception, and you default away from them.**\n  Only genuinely client-bound working facts (a specific client's budget, contacts,\n  live campaign state) are *not* brain material. Those belong in that client's\n  **Project** — but only when the org actually runs a per-client agent that needs\n  them. Do **not** route deliverables there to \"keep them separate\": that buries\n  the brain in silos. When unsure, it goes in the **brain** (the corpus).\n\n- **Three axes inside Company Knowledge, kept separate.** A doc has:\n  - a single **`folder`** — its ONE home, a slash-nested path like\n    `playbooks/strategy`, shown as the browse tree (a doc appears in exactly one\n    place). Omit for a top-level (Unfiled) doc.\n  - many **`tags`** — cross-cutting labels for search/filter (e.g. `festival`,\n    `enterprise`). NOT folders. A doc lives in one folder but can carry several\n    tags.\n  - optional **`meta`** — structured properties distilled from the material\n    (e.g. `effective_date`, `owner`). Preserved for the human reviewer.\n\n- **The dump's folder structure is a HINT, not a spec.** Whatever folders the\n  client shipped (`Training Docs/`, `Strategies/`, `Proposals/`, `Brand/`) are\n  *signal* about topic — read them, get inspired, reuse the parts already\n  coherent. But you are curating, not copying: if their structure is messy,\n  redundant, or one-doc-per-client, **re-derive a cleaner taxonomy** (e.g. collapse\n  a `Proposals/` folder of per-client files into one `playbooks/` doc). Do not\n  preserve a structure just because it was theirs.\n\n- **Structure is also links.** Use `[[Doc Title]]` wikilinks between related docs.\n  These render as the knowledge graph next to the folder tree. Forward references\n  to docs you haven't written yet are fine — they mark what's worth writing next.\n\n- **Binary assets are not knowledge.** Fonts, logo files, raw images, signed\n  contract scans — these carry no distillable *answer authority*. Don't force\n  them into the corpus. Reference them from the relevant doc (e.g. the brand doc\n  lists the brand fonts and logo files by name); leave the blobs in the file\n  library.\n\n## Procedure\n\n### 1. Survey the dump and read its structure as signal\n\n- Use `company_knowledge_search` with broad, business-topic queries (\"pricing and\n  discounts\", \"brand voice and tone\", \"onboarding SOP\", \"digital strategy\n  approach\", \"proposal structure\", \"case study results\") to pull the salient\n  content the user dropped in. Files uploaded to the Company Knowledge section are\n  auto-indexed and searchable to you.\n- Note the **folders the dump arrived in** — they hint at topic (a `Proposals/` or\n  `Strategies/` folder tells you there's a playbook to distill out of many\n  deliverables). Use them as inspiration, not as the final taxonomy.\n\n> Note: today you read the dumped material through `company_knowledge_search`\n> (semantic retrieval). If a `company_files_list` / `company_file_read` tool is\n> available to you, enumerate and read each dumped file directly for a more\n> complete pass — otherwise work topic-by-topic from search.\n\n### 2. Cluster into canonical brain docs (merge across sources)\n\nGroup the material into a SMALL set of **topics**, each becoming one canonical\ndoc. The key move for a deliverable-heavy dump:\n\n- **Many deliverables of one kind → one playbook.** Seventeen proposals → a\n  \"Proposal Playbook\". Nine strategies → a \"Digital Strategy Playbook\" (split by\n  segment only if the method genuinely differs, e.g. festivals vs. artists).\n- **Training / SOP files → the how-we-work docs** (`doc_type: sop`).\n- **Brand deck / overview → brand + positioning docs** (`doc_type: brand`).\n- **Prefer a few dense, canonical docs over many thin ones.** If you're about to\n  write a doc whose title is a client's name, stop — that's a signal you're\n  mirroring a deliverable instead of distilling the pattern.\n\n### 3. Learn the existing taxonomy BEFORE inventing folders\n\nThe single most important step — this is what keeps folders coherent instead of\nsprouting `pricing`, `Pricing`, and `price-list` as three bogus folders.\n\n- Call `company_knowledge_list` and read the `folder` values already in use across\n  the corpus. That set **is** the current folder tree. Note the `tags` too (the\n  label vocabulary), so you reuse those instead of coining synonyms.\n- Reuse existing folders wherever the material fits. Only create a new folder when\n  nothing existing fits, and prefer a shallow, obvious name (`playbooks`, `sales`,\n  `brand`, `people`, `legal`, `pricing`, `product`). If the org has no docs yet,\n  propose a small, conventional top level matching the doc types.\n\n### 4. Distill each cluster → propose it\n\nCall `company_knowledge_propose` once per topic with:\n\n- **`title`** — the canonical name (\"Proposal Playbook\", \"Enterprise Pricing\").\n  A pattern/method name, not a client name.\n- **`description`** — one load-bearing line; it drives the knowledge index and\n  ranking. Always write one: if omitted, the server falls back to the doc's\n  opening line, which is rarely as good.\n- **`content`** — the distilled markdown. A clean, self-contained statement that\n  **merges the sources and resolves overlaps** — the authoritative method the org\n  would publish, not a summary of each file. Use `[[Other Doc Title]]` to link\n  related docs.\n- **`doc_type`** — one of policy / sop / pricing / product / brand / faq / legal /\n  reference.\n- **`folder`** — the single home path, e.g. `playbooks/strategy`. Reuse taxonomy\n  from step 3. Omit for a top-level doc.\n- **`tags`** — cross-cutting labels (e.g. `[\"festival\",\"q3\"]`), NOT the folder.\n  Optional.\n- **`meta`** — optional structured properties, e.g.\n  `{ \"owner\": \"Strategy\", \"reviewed\": \"2026-01-01\" }`.\n- **`source_ref`** — provenance: the source file id(s)/name(s) you distilled from.\n  **Always set this** so a re-run recognises what's already organized instead of\n  duplicating, and the reviewer can trace a doc back to its source.\n\nYou can also put the metadata in the markdown itself as YAML frontmatter — it is\nparsed on save and wins over the fields, so this is equivalent and round-trips\nwith export (`folder`/`tags` are separate keys; any other key is preserved as a\n`meta` property):\n\n```markdown\n---\ntitle: Festival Digital Strategy Playbook\ndoc_type: sop\nfolder: playbooks/strategy\ntags: [festival, launch]\nowner: Strategy\n---\n# Festival Digital Strategy Playbook\nThe canonical method, distilled across past strategies. See [[Proposal Playbook]].\n```\n\n### 5. Avoid duplicates on a re-run\n\nBefore proposing, check `company_knowledge_list` for an existing doc with the same\n`source_ref` or an obviously-equivalent title. If one exists, fold the new thinking\ninto that doc's proposal rather than creating a second near-duplicate.\n\n### 6. Hand off to the human\n\nWhen done, tell the user plainly: how many docs you proposed and the folders you\nfiled them under, that they should **review in the Knowledge → Map view and\npublish** (nothing reaches their agents until they do), and anything you dropped\nas asset/noise or were unsure how to file.\n\n## Guardrails\n\n- **Grow the brain; don't silo it.** Deliverables become shared, citable playbooks\n  in the corpus. Never route reusable know-how into a per-client Project to \"keep\n  it separate\" — that buries the company's intelligence. When unsure, it's brain.\n- **Never publish.** `company_knowledge_propose` only. Publishing is a human,\n  owner/admin action.\n- **Curate, don't mirror.** Don't propose one doc per file, and don't preserve the\n  dump's folder structure just because it was theirs. Merge across sources into\n  playbooks, distill, drop noise, re-derive a cleaner taxonomy.\n- **No secrets or per-customer facts in Company Knowledge.** Credentials, API keys,\n  and one-customer working details (a specific client's budget/contacts) never\n  belong in the org corpus — strip them when distilling a deliverable into a\n  playbook.\n- **Reuse the taxonomy** (step 3). Inventing ad-hoc folders/tags per file recreates\n  the mess you're here to fix.\n- **Ceiling:** this is a one-shot / periodic *curate* pass. Keeping a large,\n  constantly-changing Drive continuously in sync is a different mechanism\n  (scheduled connector → markdown sync), not this skill. If the user wants\n  always-fresh mirroring of a big source, say so and stop — don't turn this into\n  a whole-Drive re-crawler.\n"
}