Update to Kowalah

{
  "description": "See which AI tools you use in your assistant (Claude, ChatGPT, Codex and others) — connectors, apps, skills, plugins, projects — check they're set up properly, and share them with your organisation's AI register. Use for \"what AI tools do I have\", \"what's connected\", \"is my setup right\", \"add my tools to the register\", \"my AI lead asked everyone to share their tools\", or when someone has been asked to take part in an AI tools review.",
  "included_files": [],
  "name": "my-ai-tools",
  "skill_md_contents": "---\nname: my-ai-tools\ndescription: See which AI tools you use in your assistant (Claude, ChatGPT, Codex and others) — connectors, apps, skills, plugins, projects — check they're set up properly, and share them with your organisation's AI register. Use for \"what AI tools do I have\", \"what's connected\", \"is my setup right\", \"add my tools to the register\", \"my AI lead asked everyone to share their tools\", or when someone has been asked to take part in an AI tools review.\n---\n\n# My AI tools\n\nFor anyone in the organisation. Most people's AI setup has grown one connector and one skill\nat a time, and nobody, including them, has the full picture. This skill shows them theirs,\nfixes what's half set up, and, with their say-so, adds it to the organisation's AI register\nso the AI lead can see what's actually in use.\n\n**What this skill sends, and when.** Only what the user approves leaves the conversation,\nand only to their own organisation's AI register in Kowalah, with the\n`kowalah_record_ai_assets` tool: first a list of tool names, kinds and ids, and then, if they\nchoose to do part two, their own answers about each tool. Nothing is sent before the user\nhas seen exactly what will be saved and said yes. If they say no, or say nothing, nothing is\nsent.\n\n## 1. Say what you'll do, and what you won't\n\nBefore looking at anything, tell them in two or three sentences:\n\n- You'll list the connectors, skills, plugins and projects **this session** can see, in\n  whichever assistant they're using.\n- Only **names and ids** get recorded. You won't read or record what's inside a skill, a\n  project or a conversation.\n- They'll see the list first and choose what to share. Anything personal stays out unless\n  they say otherwise.\n\nThen ask whether to go ahead. If they'd rather just see their setup without sharing\nanything, do step 2 and step 6 and send nothing.\n\n## 2. List what this session uses\n\nWork from what you can actually see in this session, not from memory or guesses. Each\nassistant shows different things; list what yours shows and nothing it doesn't:\n\n- **Connectors** (called apps in some assistants) — each one's name, and its id when the\n  assistant shows one. Note its state: connected, needs authorising, disconnected, setup\n  not finished.\n- **Plugins** — name and id as the assistant shows it (in Claude, `plugin_…`), and the\n  skills inside each.\n- **Skills** — name, and id where there is one (in Claude, `skill_…`). Skills built into\n  the assistant by its maker are recorded by name.\n- **Projects** — you will usually see an id but not a name.\n- **Custom GPTs aren't recorded.** They are being retired; if the work matters, record what\n  replaces it.\n\nIf you can't tell what something is, or the assistant shows you very little of its own\nsetup, say so plainly and record only what you're sure of. A short honest list beats a\nlong guessed one.\n\n**Leave out** built-in and local tools: memory, the file system, the browser, widgets,\nanything running on their own computer. They aren't the organisation's AI estate.\n\n**Never describe or send what's in a project, a skill or a chat.** For a project, record its\nid and ask the user what it's called. If you can tell a project is personal, don't list it\nfor sharing at all.\n\nShow the list grouped by kind, with anything that needs attention marked. Keep it scannable:\na table per kind, or a short list, not a paragraph per item.\n\n## 3. Let them choose\n\nAsk which to share. Make it easy: \"all of these, except …\" is the usual answer.\n\n- **Personal things are out by default.** A connector to their own Gmail, a personal\n  project, a skill they wrote for home. Offer once, plainly: sharing a personal tool as\n  *personal* helps the AI lead see where people are using their own accounts for work, but\n  it is their call.\n- **Anything they haven't seen, you don't send.**\n- **Confirm the final list.** Show exactly what will be sent (each item's name, kind and id)\n  and ask \"Send these to your organisation's AI register?\" Only a clear yes counts.\n\n## 4. Record it, and keep this pass quick\n\nOnce they've confirmed the list, call **`kowalah_record_ai_assets`** with `surface` set to\nwhere this session runs and only the items they approved. Use the surface you're actually on:\n\n| Assistant | `surface` |\n|---|---|\n| Claude on the web, desktop, Claude Cowork, Claude Code | `claude_ai`, `claude_desktop`, `cowork`, `claude_code` |\n| ChatGPT on the web or desktop, Codex | `chatgpt`, `chatgpt_desktop`, `codex` |\n| Microsoft 365 Copilot (Chat or Cowork), Gemini | `copilot`, `gemini` |\n| Anything else, or you're not sure | `other` |\n\nNever pick a Claude surface for another assistant. `other` is the honest answer when it\ndoesn't fit: the tools are recorded with no platform, which is a gap someone can fix, not\na mistake someone has to find.\n\nFor each item:\n\n- `kind`, `name`, and `external_ref` whenever there is an id. The id is how the register\n  recognises the same tool next time, and across the places they use it.\n- Plugins **before** the skills inside them, with `parent_external_ref` on each skill.\n- `connection_status` on connectors.\n- `scope: \"user\"` on the personal items they chose to share.\n- `origin` where you know it: `anthropic` for Claude's own built-in skills, `vendor` for\n  another assistant's own built-in tools and for a connector's maker, `kowalah`, or\n  `in_house` for something the organisation built.\n\nYou don't need to say which platform anything runs on: what this session uses is put on\nthe platform the surface runs on (Claude, ChatGPT, …) when the organisation's systems\nregister holds it, and each connector is linked to the system it's named for. If the\nresponse says the platform isn't in the register, tell them: their AI lead can add it.\n\nThe response has one short line per item: **new** or **seen again**, its gaps, and\n`ask: true` on the ones nobody has described yet (`ask_about` is how many). For those, ask\n**one** quick question in this pass: is it just them, their team, or provided to everyone?\nThat's `scope`. Everything else waits for part two.\n\nThis first pass has to stay fast, or people won't run it. Someone running it for the\nsecond time should be done in a minute.\n\n**Some fields are for admins.** Owner, status and organisation-wide scope are set by admins\nand core team (or the tool's owner). If Kowalah won't accept one of those values from this\nuser because of their role, it records the tool without that value. Tell the user which\nvalue wasn't saved, and that their AI lead can set it.\n\n## 5. Part two: what each tool does (when there's time)\n\nA register of names says what exists, not what it does. Part two fills that in, and it's\n**separate** from the first pass so capture stays quick. Offer it at the end (\"have you got\nfive minutes to say what a few of these are for?\"), run it on a re-run, or when the AI lead\nasks from `ai-estate`. Never make it a condition of sharing.\n\nWork only on items with gaps, a few at a time, **organisation-wide and live ones first**.\nBefore recording anything they tell you here, say what you'll save against which tool, and\nsave it only if they agree:\n\n- **What's it for?** Their words become `description`. Never write one yourself from what a\n  skill or tool contains.\n- **Does it do a job in one of the organisation's processes?** If so, which step: find it\n  with `kowalah_get_process` and pass `serves_step_ids`. This is how \"Brian drafts the\n  replies\" becomes a real record on that step. `kowalah_get_ai_estate` lists\n  `suggested_step_links`, steps that already name the tool in their text, so start there\n  and ask the person to confirm each one.\n- **For a connector: whose login does it run on, can it act** (send, sign, write) **or only\n  read, and does anyone approve what it does first?** Record the answers as:\n  - `connection_holder_user_id`: their own id, for their own login\n  - `access_level`: `read_only` or `can_act`\n  - `human_approval`\n\n  Record only what they actually know, and leave the rest unset: \"not sure\" is a gap, not\n  read-only. They can set these on their own personal tools. For shared ones, admins and\n  core team decide, so put what the person said in `notes` instead.\n- **Has it saved them time, or made something possible?** If they say so, offer to record\n  it with the `outcomes` skill: on the step it serves, linked to this tool. Take their\n  figure and how they know. Don't push for a number they don't have.\n\nStop when they've had enough. Whatever's left shows as a gap for next time.\n\n## 6. Give something back\n\nThis is why it's worth their time. From what you listed:\n\n- **Connectors that need authorising or have disconnected** — name them and say how to fix\n  it in their assistant's connector or app settings. Installed-but-never-connected is common\n  and usually an oversight.\n- **Duplicates** — the same skill in several plugins, or an account skill that a plugin\n  now provides.\n- **Something already exists** — if they described a job a tool of theirs half-does, check\n  `kowalah_find_accelerator`; there may be a better one off the shelf.\n- **The organisation's position** — if a tool they use sits on a platform the systems\n  register shows as unreviewed or prohibited (`kowalah_get_systems`), tell them straight.\n  Not as a telling-off: they are the reason the AI lead can now sort it out.\n\nClose with one line: what was shared, and what (if anything) they should do next.\n\n## Running it again\n\nPeople's setups change. Running this again is how the register stays current: known tools\nare simply \"seen again\", and only new ones get questions. It only ever runs when the user\nasks for it. If the AI lead wants a refresh, `ai-estate` shows what has gone quiet and they\nask the team to run it.\n\n## Scope and permissions\n\nAnyone in the organisation can share their tools. Everyone can read the register with\n`kowalah_get_ai_estate`, but others' use shows as counts, not names, unless you are an\nadmin or core team.\n\nIf the user belongs to more than one Kowalah organisation, pass `organization_id`. Call\n`kowalah_get_update` with no query to list their organisations, then ask which one.\n"
}