@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?"

**People are not one of the four:** the people a workflow meets (leads, enquiries, customers) go in **Contacts** with
the Awesomate node (Contact: Create or Update) wherever `features.contacts` is on; see the awesomate-n8n
skill's `awesomate-node.md`. Data tables are for the workflow's own working data.

**(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. The table lives in n8n: Claude designs
the columns, the user creates it in n8n (Data tables in the left menu,
inside the project that owns the workflow), or Claude creates it through
their n8n's own MCP server when that server offers a data-table tool. No
Awesomate tool creates or writes a table. 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'}`.
**That read is gated** by the privacy switch **"Let Claude Code work with
your automations"** 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 the read comes 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. → a Postgres
credential the user creates in their own n8n. No Awesomate tool provisions
this any more; it is two steps the user does, and you walk them through:
1. Get a database. If they have an Awesomate hosting account and cPanel
   shows a **PostgreSQL Databases** page (not every package does; check
   before promising it), it makes one (database + user + password) in a
   minute; the awesomate-hosting skill opens cPanel for them. If their data
   already lives in a Postgres somewhere else (their app's database, Supabase,
   Neon), use that one: see (d).
2. Create the credential in n8n at `{instanceUrl}/home/credentials`
   (type Postgres: host, port, database, user, password, SSL as cPanel shows
   them). The password goes from cPanel into n8n and never through the chat.
   Then confirm it exists with `awesomate_n8n_inspect {what:'credentials'}`
   and build the workflow on it (awesomate-n8n skill).
An app database made by `awesomate_app_provision_db` belongs to the app: a
workflow reads it through the app's own API, or through a credential the
user makes on purpose from the app's connection details, never by Claude
copying `DATABASE_URL` into n8n.

**(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.** `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. A workflow Postgres password lives in the n8n
  credential the user created; never ask for it and never put it, or 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

App databases (`awesomate_app_provision_db`) need **Support Plus or
above**. There is **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.

Data tables (a) and a workflow Postgres (c) are n8n's own features on every
plan, with no Awesomate gate, limit or count: the user creates them in n8n
and in cPanel. An instance tops out at 50 data tables (n8n's cap). Reading
tables or credentials from here needs the "Let Claude Code work with your
automations" toggle (§0(a)).

If the user's plan doesn't cover what branch (b) 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 (a)
and (c) still work, and so does (d), keeping the data where it already lives
and connecting to it.

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.