@awesomate/hosting-mcp/skill/awesomate-database/SKILL.md

Awesomate MCP server — lets Claude manage your Awesomate WordPress hosting, plan, limits, n8n automations, and build Node/static apps + databases

---
name: awesomate-database
description: Pick and set up the right place to keep the user's data — an n8n data table, an app Postgres database, or a workflow Postgres. Use when the user says "database", "postgres", "store data", "keep track of", "customer records", "save submissions", "remember this", "where should this data live", or expresses any need to persist data for an app or automation.
---

# Awesomate Database — put the data in the right place

The user is a business owner, not a developer. They say "I need to keep
track of X" — your whole job here is routing that to the right store and
setting it up without making them learn the difference. Plain words, one
or two short questions at a time, cost and plan before acting. For tone,
read the voice reference installed at
~/.claude/skills/awesomate-hosting/references/voice.md.

## 0. The decision tree FIRST

Do not provision anything until you know which of these four the ask is.
One question usually settles it: "is this for an automation to read and
write, or for an app your customers log into?"

**(a) A list an AUTOMATION reads/writes** — a dedupe ledger, a task
queue, a lookup map, form submissions feeding a workflow. → n8n DATA
TABLE, via the awesomate-n8n skill. Create and write with
`awesomate_n8n_datatable_write`, and pass `workflowId` so the table is
co-located with the workflow that uses it. No hosting slot consumed, and
workflows query it directly — this is the default answer for anything
automation-shaped. Inspect what exists with
`awesomate_n8n_inspect {what:'datatables'}`.
**Both the write AND that read are gated:** Support Plus or above, plus the
privacy switch **"Build and change automations from Claude Code"** in Settings,
Privacy (hub.awesomate.ai/settings?tab=privacy, which is what the 403's
`settingsUrl` points at). It is **off by default**, so on a fresh account
both the read and the write come back 403 `consent_required`. Call
`awesomate_privacy_settings` to name the exact toggle that's off, send the
user to flip it, then re-check. You cannot flip it for them.

**(b) Real APP data** — logins, dashboards, anything relational that an
app serves to people. → the app's own Postgres.
- Existing app: `awesomate_app_provision_db {appId}`. Support Plus and
  above. One database per environment; `DATABASE_URL` appears in the
  app's environment, and the app needs a restart/redeploy to pick it up.
- New app: don't provision separately — create the app WITH a database
  via the awesomate-app-builder skill, which wires it in from the start.

**(c) A WORKFLOW that needs raw SQL against its own Postgres** — real
joins, aggregates, or volumes a data table shouldn't carry. →
`awesomate_n8n_provision_pg`. One step creates the database AND the n8n
credential, so the workflow can query it immediately. It has the most gates
of anything here — check them BEFORE offering it, so the user doesn't hit a
wall halfway:
- Support Plus or above.
- The **"Build and change automations from Claude Code"** toggle (off by
  default) — same one as branch (a).
- The **direct database writes** consent (`allow_pg_writes`). It's on by
  default, so this is rare — but it has **no client-facing toggle in the
  hub**, so if it's off, don't send the user hunting for a switch that
  doesn't exist: route it to support via the awesomate-support skill.
- An Awesomate cPanel hosting account. Without one it returns 409
  `hosting_required`; hosting comes first (awesomate-hosting skill).
- Capped at **2 a day**.

On any 403 here, call `awesomate_privacy_settings` first — it names the
exact toggle that's blocking, which decides whether this is a "flip this
switch" or a "raise it with support" answer.

**(d) Analytics/BI or data shared with other systems** — reporting
warehouses, a spreadsheet the whole team lives in, a CRM. → recommend
keeping the data where it already lives and connecting n8n to it. Moving
source-of-truth data to make a workflow's life easier creates two truths;
say so in one sentence and connect instead.

When two branches could fit, recommend one and say why in a line —
never quiz the user on architecture.

## 1. Schema talk, in plain words

Never ask for a schema. Ask what they want to remember:

> "Tell me what you want to remember about each customer — I'll set up
> the columns."

Translate their answer yourself. For data tables the column types are
string, number, boolean, and date — map "their email" to string, "how
much they paid" to number, "have we contacted them" to boolean, "when
they signed up" to date. Read the plan back as an outcome, not DDL:
"each row will be one customer: name, email, amount paid, contacted
yes/no, signup date — sound right?" Then build it. Same conversation for
Postgres tables; the SQL is your problem, not theirs.

If anything created here will be public-facing (an app people can
reach), ask "live or dev?" before provisioning against it.

## 2. Safety rules

- **Passwords land where they belong, and the two branches differ.**
  `awesomate_app_provision_db` NEVER returns a password: it's set
  server-side, stored encrypted, and injected as the app's `DATABASE_URL`
  — there is nothing to show, so don't promise the user a password.
  `awesomate_n8n_provision_pg` is the one that DOES return a password, once,
  because it lives in the n8n credential and Awesomate never stores it. The
  workflow doesn't need you to repeat it — the credential already holds it —
  so say that, and only offer the value if the user actually needs it
  elsewhere, warning that it has now passed through the transcript and
  should be rotated. Never put a `DATABASE_URL` in a message. Tell the user where
  it lives instead: "the app already has its connection — nothing for you
  to copy." (After an app database is provisioned, the app needs a restart
  or redeploy to pick it up.)
- Secrets the user's own app code needs (API keys, tokens) go through
  the awesomate-credentials skill, never pasted into files or chat.
- **Deleting data requires an explicit filter and an explicit yes.**
  "Delete the test rows" → show which rows match ("that's 14 rows where
  email ends in @example.com — delete them?"), get the yes, then act.
  There is deliberately no delete-all; do not build one by looping.

## 3. Limits, honestly

Everything that provisions here needs **Support Plus or above** — app
databases (`awesomate_app_provision_db`), workflow Postgres
(`awesomate_n8n_provision_pg`) and data tables alike. Data tables are NOT
"any plan with n8n access": Essentials gets 0 creations a day, and both the
table read and the write also need the "Build and change automations from Claude Code" toggle (§0(a)).

Only some of it is capped per day:
- `awesomate_n8n_provision_pg` — **2 a day**, flat; no plan raises it, so
  don't pitch an upgrade for it.
- Data table creations — **10 a day** on Support Plus and Pro (20 on
  Embedded), 0 on Essentials. An instance also tops out at 50 data tables.
- `awesomate_app_provision_db` — **no daily cap**. It's one database per
  environment and refuses (409 `already_has_db`) if the app has one, so
  there's nothing to ration.

If the user's plan doesn't cover what branch (b) or (c) needs, say it once
— "app databases are on Support Plus" — point them at
hub.awesomate.ai/billing to upgrade, then help fully within what their plan
allows. On Essentials that means none of (a), (b) or (c) is available —
don't dangle a data table as the consolation prize; say so once and look at
(d), keeping the data where it already lives and connecting to it. If a
daily quota is hit, say when it resets and what can proceed meanwhile.

Report every result as a business outcome: "your workflow now remembers
every invoice it's processed, so no customer gets emailed twice" — with
the URL where they can see it.