Woobox/hatchable-mcp

# Fix a Hatchable deploy

Investigate and fix: $ARGUMENTS

Use the Hatchable MCP tools (the `hatchable` server bundled with this plugin). If the first tool call returns an authentication error, stop and tell the user: run `/mcp`, pick **hatchable**, sign in, then ask again. Do not guess at the cause from memory when the platform can tell you the answer.

Work the problem in this order:

1. Identify the project (`list_projects` / `search_projects` if the user didn't name one).
2. **Rejected deploy:** run `dry_run_deploy` and read every error. Each names the unsupported pattern and its supported replacement. Call `read_skill('debug-a-failing-deploy')` for the canonical triage path.
3. **Deployed but broken:** `view_logs` for runtime errors, `get_deployment` for the last deploy's status, `get_schema` plus `execute_sql` to check data-shape assumptions.
4. Fix with `patch_file` or `write_files`, then `dry_run_deploy`, then `deploy`.
5. Verify against the live URL before declaring it fixed, and summarize the root cause in one line.

# Import this project to Hatchable

Deploy the current working directory (or the path in "$ARGUMENTS", if given) as a Hatchable project.

Use the Hatchable MCP tools (the `hatchable` server bundled with this plugin). If they are unavailable or unauthenticated, tell the user to run `/mcp` and complete the Hatchable OAuth sign-in first.

1. **Survey the local project.** List its files and identify what maps to Hatchable's structure: static assets to `public/`, server endpoints to `api/*.js` handlers, schema to `migrations/*.sql`, shared code to `lib/`. Read https://hatchable.com/docs/developers/project-structure if unsure of the target shape.
2. **Check the fit before writing.** Hatchable runs plain JS with no build step and no npm install. If the project uses a bundler, TypeScript, an ORM, or a server framework, tell the user what needs restructuring and how much work it is BEFORE creating anything. Small static sites and plain-JS apps import cleanly; framework apps need porting.
3. `create_project`, then push the mapped files with `write_files` in batches.
4. `dry_run_deploy` first. Fix every blocker it reports (the errors name the supported alternative), then `deploy`.
5. Verify the live URL works, then hand it to the user. Mention that the project starts private and how to share or publish it from the console.

If the user's repo is on public GitHub and they'd rather not go file-by-file, they can also paste the repo URL into the console's Import page; offer that as the alternative.

# Build a new app on Hatchable

Build and deploy: $ARGUMENTS

## Step 0: confirm the connection before building anything

Call `list_projects` first. It is cheap, read-only, and proves the Hatchable tools are connected and authenticated.

**If that call fails, is unavailable, or returns an authentication error, STOP immediately.** Write no files, create no artifacts, produce no local version of what was asked. Say exactly this and end the turn:

> Hatchable isn't connected yet, so I can't deploy this. Run `/mcp`, pick **hatchable**, and sign in. It's free and takes about fifteen seconds. Then ask me again and I'll build and deploy it.

A local file or an artifact is not a smaller version of what the user asked for. They asked for something live at a URL; a local file cannot be shared, has no database, and dies when the session ends. Offering one wastes their time and buries the one step that unblocks them. Do not do it, and do not offer it as a consolation.