pitch-crm-route-migration-enforcer

Migrates legacy Supabase Edge Function calls into grouped API routes with shims and audit reporting.

Updated Sep 24, 2025
One-click install
npx skills add https://github.com/chriso789/pitch-1 --skill pitch-crm-route-migration-enforcer-chriso789
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pitch-crm-route-migration-enforcer
Source: https://github.com/chriso789/pitch-1/tree/main/.agents/skills/pitch-crm-route-migration-enforcer
Command: npx skills add https://github.com/chriso789/pitch-1 --skill pitch-crm-route-migration-enforcer-chriso789

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pitch CRM's Supabase backend has 456 Edge Function folders, causing maintenance bloat and inconsistent frontend invocation patterns. This Skill enforces consolidation of legacy standalone functions into grouped *-api, *-worker, and *-webhook routes while keeping an accurate audit trail. ## Core Features & Use Cases - Frontend call migration: Converts supabase.functions.invoke("old-name") calls into edgeApi("grouped-api", "/route", payload) invocations. - Legacy function shimming: Replaces migrated function folders with shims via _shared/shim.ts to preserve backward compatibility. - Scaffold wiring and audit reporting: Wires real typed routes into scaffold-only grouped functions and reports exact folder, route, shim, and call-site counts after every change. - Use Case: While editing a messaging feature, you find the frontend calling send-sms directly. The Skill routes it through messaging-api as POST /sms/send, shims the old function, updates the audit CSV, and reports the new folder count. ## Quick Start Ask the agent to migrate the frontend's legacy Supabase function calls in the current file into grouped edge API routes and report the updated audit counts.

Frequently Asked Questions about pitch-crm-route-migration-enforcer

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

FAQPage Schema
How do I migrate a legacy Supabase Edge Function call to a grouped route?▼

Replace `supabase.functions.invoke("old-name")` with `edgeApi("grouped-api", "/route", payload)` in the frontend, move the logic into the grouped function's route handler, and shim the old function folder using `_shared/shim.ts`.

What is the difference between *-api, *-worker, and *-webhook Supabase functions?▼

`*-api` functions handle authenticated tenant-scoped app actions, `*-worker` functions run service-role background jobs requiring the service role or INTERNAL_WORKER_SECRET, and `*-webhook` functions receive public provider callbacks with signature validation.

When is it safe to delete a Supabase Edge Function folder?▼

A function is safe to delete only when it has zero frontend references, zero backend references, is not on the public webhook list, and is not referenced in `supabase/config.toml`. All four conditions must be confirmed first.

Can I create a new standalone Supabase Edge Function for a feature?▼

No, new standalone functions are rejected unless they are approved provider webhooks, OAuth callbacks, or cron-pinned workers documented in `docs/EDGE_FUNCTION_RULES.md`. New logic must be routed through an existing grouped function.

Why must tenant IDs not come from the request body in edge routes?▼

Trusting `company_id`, `tenant_id`, or `user_id` from the request body allows callers to spoof other tenants. Tenant and company access must be resolved from the authenticated user via `_shared/auth.ts` and `_shared/tenant.ts`.