Agentic Tooling Registry

The habit this skill exists to enforce: search before you build. An agent that needs a helper, script, or endpoint should check whether one already exists before writing a near-duplicate. This registry is the place that search runs against.

Trigger: search 1-2x per task, with keywords for what you're working on, before implementing any new helper, function, or endpoint.

Default: local, file-backed registry

Ships with nothing else required. The registry is a JSON file at the path printed by:

alignment-harness records tool-registry

Each tool is one entry: { "slug": "...", "name": "...", "description": "...", "toolType": "function|endpoint|skill|component|mcp|hook", "category": "...", "sourceFile": "...", "certainty": 0-100, "status": "proposed|approved", "tags": [...] }.

• Search: read the JSON file and filter by keyword against name, description, and tags. If the file doesn't exist yet or is empty, say so plainly ("nothing registered yet — this may be new") rather than silently returning nothing.
• Register / propose: append a new entry. For a solo user, "approve" can simply mean the person confirms it once when you show them the entry — there's no need to model a multi-person review queue unless they actually have one. Default new agent-found entries to status: "proposed", certainty: 50; the person bumps it to approved/100 by saying so.
• Update / approve: edit the entry in place.

Seed it on first use. If the registry is empty, offer to scan the person's own project — package.json scripts, the skills folder, any OpenAPI/Swagger file, existing route files — and register what's found as unreviewed (certainty: 50 or similar), so the first search isn't against an empty file. Say what you found and where, and let them confirm before you write a large batch.

Numbered results display convention

🔍 Found 4 tools matching "commit":

[1] commit
    Skill | git, workflow, staging
    Handle git commits with structured messages and verification checklists

[2] contribute
    Skill | git, upstream, atomic-changes
    Professional contribution workflow for upstream repos with atomic PRs

[3] api-alignment-check
    Skill | api-validation, routing
    Validate API alignment before commits affecting endpoints

[4] ux-assignment-generator
    Skill | verification, code-review
    Generate UX assignments after code changes

Optional: point this at your own admin backend

If you've built (or a reference setup provides) a real database-backed tool registry with its own HTTP API, key, and admin UI, use that instead of the local file — same shape of data, same search-before-you-build discipline, just served over HTTP with auth rather than read from a local JSON file. That's advanced, optional infrastructure, not something this skill requires or assumes.

Bulk registering endpoints

When new endpoints are added and agents can't find them, sync your routes into the registry in one pass rather than one at a time: read the route files, register each endpoint as a toolType: "endpoint" entry with its method, path, and purpose. This keeps the registry from drifting away from what the codebase actually exposes ("invisible endpoints").

When to search

• Starting a task → search task keywords (e.g., commit, modal, validation)
• About to create a helper → search function purpose (e.g., scroll, format, parse)
• New endpoints added → search by workflow nouns (e.g., segment compare, cell audit)