tool-registry-boundary

Keeps the executable tool registry out of client-reachable module graphs in the Sim codebase.

29.5k|3.8k|Updated Jan 5, 2025
One-click install
npx skills add https://github.com/simstudioai/sim --skill tool-registry-boundary
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tool-registry-boundary
Source: https://github.com/simstudioai/sim/tree/main/.agents/skills/tool-registry-boundary
Command: npx skills add https://github.com/simstudioai/sim --skill tool-registry-boundary

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The Sim repository's tool registry is a ~9,000-line barrel importing all 4,300+ tools, and a single getTool import in client-reachable code drags ~4,700 extra modules into the bundle. This Skill teaches you which lightweight metadata module to import instead, how to regenerate the generated artifacts, and how to verify an import edge was actually cut.

Core Features & Use Cases

  • Import Selection Guide: Maps each need (existence checks, params, outputs, execution) to the correct module: @/tools/tool-ids, @/tools/metadata, @/tools/metadata-outputs, or getTool.
  • Artifact Regeneration: Explains the bun run tool-metadata:generate and tool-metadata:check workflow for the generated tool-ids.ts, tool-metadata.ts, and tool-outputs.ts files, including why they must stay JSON strings rather than .json imports.
  • Boundary Auditing: Covers the check:tool-registry-boundary guard, its baseline ratchet, and how to walk the module graph to confirm a route no longer reaches tools/registry.ts.
  • Use Case: You edited apps/sim/tools/params.ts and CI's registry-boundary audit fails. Use this Skill to find the offending import chain, move the needed symbol to a registry-free module, and re-measure the route's module count.

Quick Start

Ask the AI to check whether your change to a file under apps/sim pulls @/tools/registry into a client-reachable route and to fix it using the metadata modules.

Frequently Asked Questions about tool-registry-boundary

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I read tool params without importing the tool registry?

Import getToolParams or getToolMetadata from @/tools/metadata instead of calling getTool. The metadata module is a generated ~4 MB artifact containing plain param data, while getTool pulls in the entire executable registry with request closures.

When should I use getTool versus @/tools/metadata?

Use getTool only when code actually executes a tool, such as building external requests or transforming responses, and keep that file off client-reachable paths. For reading params, outputs, name, or checking existence, always use @/tools/metadata or @/tools/tool-ids.

Why does the tool registry boundary check fail in CI?

The audit walks the module graph from each workspace route and fails if @/tools/registry is reachable, printing the exact import chain. It also fails when a route's module count exceeds its baseline by more than max(25 modules, 2%), catching bloat unrelated to the registry.

How do I regenerate the tool metadata artifacts after adding a tool?

Run bun run tool-metadata:generate and commit the result; CI runs bun run tool-metadata:check and fails if the artifacts are stale. Never hand-edit the generated files tool-ids.ts, tool-metadata.ts, or tool-outputs.ts.

Why are the generated artifacts JSON strings instead of .json imports?

With resolveJsonModule enabled, a .json import makes TypeScript infer literal types for all 4,300+ entries, slowing tsc --noEmit from 12.6s to over 8 minutes. A single string literal parsed with JSON.parse at runtime is cheap for both the compiler and the bundler.

Why does mocking @/tools/utils not affect tests that read tool params?

Code reading params, outputs, or name goes through @/tools/metadata, so mocking @/tools/utils is a no-op that still passes because real artifacts match the fixtures. Mock both @/tools/utils and @/tools/metadata with the shared mockToolConfigs-backed mocks.