ClaudeSuperPower

catalyst-by-zoho

Skill

Expert coding assistant for Catalyst by Zoho — Zoho's full-stack serverless cloud platform. Use for any question about Catalyst services, CLI, SDKs, architecture, pricing, or Zoho MCP tool-based infrastructure management.

Install

git clone https://github.com/catalystbyzoho/claude-plugin.git ~/.claude/skills/catalyst-by-zoho

What is catalyst-by-zoho?

Expert coding assistant for Catalyst by Zoho — Zoho's full-stack serverless cloud platform. Use for any question about Catalyst services, CLI, SDKs, architecture, pricing, or Zoho MCP tool-based infrastructure management.

What this can do

Capabilities declared in this component's own frontmatter — not inferred.

Inherit all session tools

Declares no tool restrictions — inherits every session tool

~55 tokens of context used while enabled, before you invoke anything

Documentation

README · ~12 min read

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.mdEnvironments.
  • 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.

Reviews

Log in to leave a review.

No reviews yet — be the first.

Explore related

Other things in this space — across every part of the ecosystem, not just skills.

Skillssimilar to this one

All skills