catalyst-by-zoho

Catalyst by Zoho — Skill Index

This is the routing layer. Load the most specific matching skill — do not answer from this file alone.

Philosophy

• Prefer MCP over asking — for resource IDs, not for the org/project itself. If the ZohoMCP_* meta-tools are available, use them to fetch table IDs, ZAIDs, bucket names, etc. (the CatalystbyZoho_* operations are invoked through them — see below); never ask the user to copy those from the console.
• 🔒 NEVER assume the org or project. The active org/project must always be resolved from an authoritative source (.catalystrc, or an MCP list the user confirms) — never guessed, inferred from the directory name, carried over from a past session, or auto-picked because "only one showed up." A single project in the list is not permission to select it silently — confirm it. If no project is initialized (.catalystrc absent) or the project cannot be resolved, STOP and ask the user which project (and org) to work in before any CLI command, MCP resource call, scaffold, or deploy. This is the one place the "prefer MCP over asking" default does not apply — see the Golden Rule in skills/catalyst-basics/references/preflight.md.
• Default to Development (via Local first). Iterate against Local, then deploy to the Development environment — never target Production unless the user explicitly says "production" or "deploy to prod". Production is reached only by migrating a verified Development setup up, not by direct deploys or resource creation.
• "Build an app" means Slate + Function by default. When a user says "build an app", "create an app", or "make a simple app" without specifying backend-only, the default output is a Slate frontend + Advanced I/O function backend. Do NOT build only a function and call it an app. If the user's intent is clearly backend-only (e.g. "build an API", "write a function"), skip Slate.
• Local-first: serve and test before you deploy. Catalyst has three environments — Local (the dev machine), Development (remote sandbox), and Production (remote, live). For any component you run yourself (Functions, AppSail, Slate), always catalyst serve and test locally first, then catalyst deploy to Development, and only migrate up to Production once Development is verified. Never deploy freshly written or changed serve-able code to Development without a local serve + test pass first, unless the user explicitly says to skip it. Local is coupled to Development (managed-service calls like Data Store/Stratus proxy to Development). The canonical model + loop lives in skills/catalyst-basics/references/project-basics.md → Environments.
• Prefer Functions over AppSail for simple HTTP. Functions are cheaper (per-invocation billing), simpler to deploy, and require no infrastructure management. Reach for AppSail only when the use case genuinely requires a persistent process, or a custom runtime.
• Show cost before building. For any new infrastructure (functions, AppSail, Stratus buckets), load catalyst-pricing and give a brief estimate before writing code. Most small projects stay within free tier — say so when true.
• Recommend the current service, not the deprecated one. File Store → Stratus. Event Listeners → Signals. Cron → Job Scheduling. Never mention the deprecated name in generated code or config.
• Warn before the region bites. Circuits and Integration Functions do not work in most data centers. Check the user's DC before suggesting them.