docs(tools): cover tool removal in the regeneration guidance

The three tool-authoring skills said to regenerate after adding or changing a
tool, but not after removing one. Removal is equally breaking and equally
guarded: deleting a tool from `tools/registry.ts` without regenerating fails
`tool-metadata:check` (verified — exit 1), so a contributor following the skill
literally would have hit a CI failure the skill never warned about.

Author: waleedlatif1

.agents/skills/add-block/SKILL.md

@@ -923,7 +923,7 @@ Derive templates from the service's real use cases. Each prompt should name a co
 
 Adding a block on its own needs **no** regeneration — a block references existing tool IDs through `tools.access` and does not change any tool's shape.
 
-But if the same change also adds or edits a tool, run `bun run tool-metadata:generate` and commit the result, or CI fails on stale artifacts. That matters here because a block's `outputs` are authored to match its tools' outputs, and the UI now reads those from the generated metadata rather than the executable registry — an unregenerated tool change makes the block's outputs disagree with what the panel renders. See `.agents/skills/tool-registry-boundary/SKILL.md`.
+But if the same change also adds, edits **or removes** a tool, run `bun run tool-metadata:generate` and commit the result, or CI fails on stale artifacts. That matters here because a block's `outputs` are authored to match its tools' outputs, and the UI now reads those from the generated metadata rather than the executable registry — an unregenerated tool change makes the block's outputs disagree with what the panel renders. See `.agents/skills/tool-registry-boundary/SKILL.md`.
 
 ## Checklist Before Finishing
 
@@ -939,7 +939,7 @@ But if the same change also adds or edits a tool, run `bun run tool-metadata:gen
 - [ ] Tools.config.tool returns correct tool ID (snake_case)
 - [ ] Outputs match tool outputs
 - [ ] Block + meta registered in registry-maps.ts (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`)
-- [ ] If any tool was added or changed alongside the block: ran `bun run tool-metadata:generate` and committed the artifacts
+- [ ] If any tool was added, changed or removed alongside the block: ran `bun run tool-metadata:generate` and committed the artifacts
 - [ ] If icon missing: asked user to provide SVG
 - [ ] If triggers exist: `triggers` config set, trigger subBlocks spread
 - [ ] Optional/rarely-used fields set to `mode: 'advanced'`

.agents/skills/add-integration/SKILL.md

@@ -422,7 +422,7 @@ bun run tool-metadata:generate
 ```
 
 Client code reads `params`/`outputs` from these artifacts rather than importing
-the registry, so a new tool is invisible to the UI until they are regenerated,
+the registry, so a tool you add, change or remove is invisible to the UI until they are regenerated,
 and CI fails on stale ones. See `.agents/skills/tool-registry-boundary/SKILL.md`.
 
 ### Block Registry (`apps/sim/blocks/registry-maps.ts`)

.agents/skills/add-tools/SKILL.md

@@ -303,7 +303,7 @@ bun run tool-metadata:generate
 ```
 
 Client code reads a tool's `params`/`outputs` from generated metadata rather than
-importing the registry, so a new or changed tool is invisible to the UI until
+importing the registry, so a tool you add, change or remove is invisible to the UI until
 these are regenerated — and CI fails on stale artifacts. Commit the result. See
 `.agents/skills/tool-registry-boundary/SKILL.md`.
 

.claude/commands/add-block.md

@@ -922,7 +922,7 @@ Derive templates from the service's real use cases. Each prompt should name a co
 
 Adding a block on its own needs **no** regeneration — a block references existing tool IDs through `tools.access` and does not change any tool's shape.
 
-But if the same change also adds or edits a tool, run `bun run tool-metadata:generate` and commit the result, or CI fails on stale artifacts. That matters here because a block's `outputs` are authored to match its tools' outputs, and the UI now reads those from the generated metadata rather than the executable registry — an unregenerated tool change makes the block's outputs disagree with what the panel renders. See `.agents/skills/tool-registry-boundary/SKILL.md`.
+But if the same change also adds, edits **or removes** a tool, run `bun run tool-metadata:generate` and commit the result, or CI fails on stale artifacts. That matters here because a block's `outputs` are authored to match its tools' outputs, and the UI now reads those from the generated metadata rather than the executable registry — an unregenerated tool change makes the block's outputs disagree with what the panel renders. See `.agents/skills/tool-registry-boundary/SKILL.md`.
 
 ## Checklist Before Finishing
 
@@ -938,7 +938,7 @@ But if the same change also adds or edits a tool, run `bun run tool-metadata:gen
 - [ ] Tools.config.tool returns correct tool ID (snake_case)
 - [ ] Outputs match tool outputs
 - [ ] Block + meta registered in registry-maps.ts (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`)
-- [ ] If any tool was added or changed alongside the block: ran `bun run tool-metadata:generate` and committed the artifacts
+- [ ] If any tool was added, changed or removed alongside the block: ran `bun run tool-metadata:generate` and committed the artifacts
 - [ ] If icon missing: asked user to provide SVG
 - [ ] If triggers exist: `triggers` config set, trigger subBlocks spread
 - [ ] Optional/rarely-used fields set to `mode: 'advanced'`

.claude/commands/add-integration.md

@@ -421,7 +421,7 @@ bun run tool-metadata:generate
 ```
 
 Client code reads `params`/`outputs` from these artifacts rather than importing
-the registry, so a new tool is invisible to the UI until they are regenerated,
+the registry, so a tool you add, change or remove is invisible to the UI until they are regenerated,
 and CI fails on stale ones. See `.agents/skills/tool-registry-boundary/SKILL.md`.
 
 ### Block Registry (`apps/sim/blocks/registry-maps.ts`)

.claude/commands/add-tools.md

@@ -302,7 +302,7 @@ bun run tool-metadata:generate
 ```
 
 Client code reads a tool's `params`/`outputs` from generated metadata rather than
-importing the registry, so a new or changed tool is invisible to the UI until
+importing the registry, so a tool you add, change or remove is invisible to the UI until
 these are regenerated — and CI fails on stale artifacts. Commit the result. See
 `.agents/skills/tool-registry-boundary/SKILL.md`.
 

.cursor/commands/add-block.md

@@ -917,7 +917,7 @@ Derive templates from the service's real use cases. Each prompt should name a co
 
 Adding a block on its own needs **no** regeneration — a block references existing tool IDs through `tools.access` and does not change any tool's shape.
 
-But if the same change also adds or edits a tool, run `bun run tool-metadata:generate` and commit the result, or CI fails on stale artifacts. That matters here because a block's `outputs` are authored to match its tools' outputs, and the UI now reads those from the generated metadata rather than the executable registry — an unregenerated tool change makes the block's outputs disagree with what the panel renders. See `.agents/skills/tool-registry-boundary/SKILL.md`.
+But if the same change also adds, edits **or removes** a tool, run `bun run tool-metadata:generate` and commit the result, or CI fails on stale artifacts. That matters here because a block's `outputs` are authored to match its tools' outputs, and the UI now reads those from the generated metadata rather than the executable registry — an unregenerated tool change makes the block's outputs disagree with what the panel renders. See `.agents/skills/tool-registry-boundary/SKILL.md`.
 
 ## Checklist Before Finishing
 
@@ -933,7 +933,7 @@ But if the same change also adds or edits a tool, run `bun run tool-metadata:gen
 - [ ] Tools.config.tool returns correct tool ID (snake_case)
 - [ ] Outputs match tool outputs
 - [ ] Block + meta registered in registry-maps.ts (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`)
-- [ ] If any tool was added or changed alongside the block: ran `bun run tool-metadata:generate` and committed the artifacts
+- [ ] If any tool was added, changed or removed alongside the block: ran `bun run tool-metadata:generate` and committed the artifacts
 - [ ] If icon missing: asked user to provide SVG
 - [ ] If triggers exist: `triggers` config set, trigger subBlocks spread
 - [ ] Optional/rarely-used fields set to `mode: 'advanced'`

.cursor/commands/add-integration.md

@@ -416,7 +416,7 @@ bun run tool-metadata:generate
 ```
 
 Client code reads `params`/`outputs` from these artifacts rather than importing
-the registry, so a new tool is invisible to the UI until they are regenerated,
+the registry, so a tool you add, change or remove is invisible to the UI until they are regenerated,
 and CI fails on stale ones. See `.agents/skills/tool-registry-boundary/SKILL.md`.
 
 ### Block Registry (`apps/sim/blocks/registry-maps.ts`)

.cursor/commands/add-tools.md

@@ -297,7 +297,7 @@ bun run tool-metadata:generate
 ```
 
 Client code reads a tool's `params`/`outputs` from generated metadata rather than
-importing the registry, so a new or changed tool is invisible to the UI until
+importing the registry, so a tool you add, change or remove is invisible to the UI until
 these are regenerated — and CI fails on stale artifacts. Commit the result. See
 `.agents/skills/tool-registry-boundary/SKILL.md`.