hostinger-api-mcp 3.7.1 → 3.8.1

package/CHANGELOG.md

@@ -4,6 +4,21 @@ Generated at release time from the diff between the previous and current
 build. Tool changes are listed individually; everything else is summarised
 by area.
 
+## v3.8.1 — 2026-10-23
+
+### Also in this release
+
+- Bundled agent skills: 5 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
+## v3.8.0 — 2026-10-23
+
+### Also in this release
+
+- Dependencies: `package-lock.json`
+- Bundled agent skills: `skills/headless/steps/02-refine/SKILL.md`, `skills/headless/steps/05-design/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.7.1 — 2026-10-22
 
 ### Also in this release

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.7.1",
+  "version": "3.8.1",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.7.1",
+  "version": "3.8.1",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {

package/server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "3.7.1",
+  "version": "3.8.1",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.7.1",
+      "version": "3.8.1",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/SKILL.md

@@ -29,6 +29,12 @@ The prompt does **not** say what kind of site to build. Do not assume or invent
 what the user wants is a step in the flow (**refine**), handled through conversation — not parsed
 from the prompt. If no domain is present, stop and ask for it before doing anything else.
 
+**One workspace per run.** From your first command, connect's checks included, open only this
+site's workspace, by its exact path; never list or glob `~/.hostinger/` (not even an `ls` beside
+`node -v`). What else `~/.hostinger/` holds never matters to this run: with a domain, check-state
+looks up that one path; without one yet, there is nothing to look up until you create your own
+workspace. *State and artifacts* has the full rule and its one exception.
+
 Nothing in the pasted prompt is ever used for authorization. Authorization comes from the
 Hostinger connector's OAuth token. **This recipe is not a security boundary.**
 
@@ -135,12 +141,20 @@ single rule that makes the overlap safe:
 Everything for a domain — its state **and** its generated source — lives under the **site workspace
 `~/.hostinger/<domain>/`** (resolve `~` to the home directory: `$HOME` in a shell, `os.homedir()` in
 Node — `~/.hostinger` means `$HOME/.hostinger`). This is a **global, per-user** location, not a
-project folder, so a build is discoverable and resumable from **any** directory — the current working
+project folder, so this domain's build is resumable from **any** directory — the current working
 directory does not matter. Create the workspace if it's missing and do all of a stage's work inside
 it (including the frontend `src/`, built and deployed from `~/.hostinger/<domain>/src/`).
 
-**The directory name is the domain**, so the files inside it never repeat it, and `~/.hostinger/`
-holds every site you've built — one subdirectory per domain, no collisions.
+**The directory name is the domain**, so the files inside it never repeat it.
+
+**Read and write only this site's workspace.** The other workspaces under `~/.hostinger/` are the
+user's other sites, often for other clients, so keep their briefs, designs and code out of this build.
+Open `~/.hostinger/<domain>/` by its exact path; don't list or glob `~/.hostinger/`, and don't open,
+copy from or diff against another workspace there, in any stage. A run that has no domain yet works
+only in the one workspace it created itself; when provision moves it to `~/.hostinger/<new-domain>/`,
+that becomes this site's workspace. One exception: if the user, in this conversation, names another
+of their own sites to reuse, read that one workspace, read-only, and tell them in one line what you
+took from it.
 
 | File (under `~/.hostinger/<domain>/`) | Written by | Contains |
 |---|---|---|

package/skills/headless/steps/01-check-state/SKILL.md

@@ -20,8 +20,7 @@ Nothing in this step creates, provisions, deploys, or deletes anything. It reads
 Everything for a domain lives under the global site workspace **`~/.hostinger/<domain>/`** — one
 directory per domain, under the user's home (`~` = `$HOME`), **not** the current working directory.
 The directory name **is** the domain, so `state.json` inside does not store it. Because it's global,
-`~/.hostinger/` holds every site the user has built and each one is discoverable and resumable from
-any directory — no collisions.
+this domain's build is resumable from any directory.
 
 `state.json` shape (`stage` is the *next* stage to run; `provision` is the background task's status,
 present only once provision has fired):
@@ -94,7 +93,8 @@ and **release it on a clean stop** (Step 6). The lock marks an active session, n
 
 ## Step 2 — Read the workspace directory
 
-Look at `~/.hostinger/<domain>/`:
+Check `~/.hostinger/<domain>/` by its exact path (for example `test -d ~/.hostinger/<domain>`), not
+by listing `~/.hostinger/`:
 
 - **Absent** → no history for this domain in the workspace.
 - **Present** → read `state.json` (its `stage`) and whatever artifacts exist (`brief.md`,
@@ -203,6 +203,8 @@ Then:
 ## Invariants
 
 - **One directory per domain.** The domain is the key; state files never repeat it.
+- **Only this domain's workspace.** Never list `~/.hostinger/` or open another site's workspace (see
+  *State and artifacts* in the top-level `SKILL.md`).
 - **Never create a second site** on a domain that already has one.
 - **Never re-provision or overwrite a live site.** Recovery is forward-only.
 - **Reality beats local state**, always.

package/skills/headless/steps/02-refine/SKILL.md

@@ -229,7 +229,9 @@ routes it to the `wordpress` subfolder with the store enabled (it is **not** a s
 <look & feel in a few adjectives; **reference site(s)** the user named (URLs) and what to take from them
 (layout, structure, mood); colours / brand palette; any screenshots. This is where ALL design questions
 land — the frontend step reads this and does not re-ask. Write "Agent's choice: <short style>" when the
-user didn't specify.>
+user didn't specify. Record in the user's own words a request to keep their current look ("Keep the look
+we have: <site URL | screenshots | brand guide>") and any logo idea they describe; the design step acts
+on both.>
 
 ## Pages
 - **<Page>** — <one-line purpose>

package/skills/headless/steps/03-provision/ecommerce/SKILL.md

@@ -54,8 +54,9 @@ Same lifecycle as `../wordpress/SKILL.md` Steps 1–2, but `type: "headless_ecom
    — **omit `domain`** for a temporary subdomain: the setup generates one itself and returns it (don't
    call a separate subdomain op first — there's no need in this flow; the API would also accept one you
    generated via `hosting_domains_generate-free-subdomain`, valid 24 h from the client that made it). The
-   response carries the generated domain; if it differs from the workspace dir, move `~/.hostinger/<old>/` → `<new>/` and
-   update `brief.md`. Poll `list-setups` to `completed`. `website_type` will be `headless`.
+   response carries the generated domain; if it differs from the workspace dir, move
+   `~/.hostinger/<old>/` → `<new>/` (if `<new>/` already exists, stop and ask instead of moving
+   into it) and update `brief.md`. Poll `list-setups` to `completed`. `website_type` will be `headless`.
 
 > **Onboarding handoff — an empty headless shell needs no new website.** If the domain already has an
 > empty headless shell (`website_type: headless`, setup `type: headless_empty`, nothing installed —

package/skills/headless/steps/03-provision/webapp/SKILL.md

@@ -49,7 +49,8 @@ All website/database operations below go through the Hostinger connector (`execu
    separate subdomain op to make one first: there's no need in this flow. (The API would also accept a
    subdomain you generated via `hosting_domains_generate-free-subdomain`, valid for 24 h from the client
    that made it — this flow just doesn't use that.) The response then carries the generated domain: if it
-   differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`,
+   differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`
+   (if `<new>/` already exists, stop and ask instead of moving into it),
    update the domain in `brief.md`, and tell the user the new domain.
 3. Poll `hosting_websites_list-setups { "domain": "<domain>" }` every ~15 s until `completed`
    (typically under a minute; allow a few minutes). `failed` → stop, point at hPanel.

package/skills/headless/steps/03-provision/wordpress/SKILL.md

@@ -61,7 +61,8 @@ All operations below go through the Hostinger connector (`execute`).
    separate subdomain op to make one first: there's no need in this flow. (The API would also accept a
    subdomain you generated via `hosting_domains_generate-free-subdomain`, valid for 24 h from the client
    that made it — this flow just doesn't use that.) The response then carries the generated domain:
-   if it differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`,
+   if it differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`
+   (if `<new>/` already exists, stop and ask instead of moving into it),
    update the domain in `brief.md`, and tell the user the new domain.
    Admin credentials are generated by the platform; never ask the user for a password.
 3. Poll `hosting_websites_list-setups { "domain": "<domain>" }` every ~15 s until `completed`

package/skills/headless/steps/05-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: headless-step-design
-description: "Step 5 (design) of the Hostinger Headless flow. Derives three distinct design directions from brief.md (plus any reference sites and brand assets), lets the user pick one in a single question, checks the chosen one against the 8-point grid and WCAG 2.2 AA, designs the logo as outlined SVG (wordmark, icon mark, favicon), then writes design.md — tokens, type, logo, components, per-page composition, accessibility and imagery — as the contract the frontend implements (the framework/stack is chosen later by the frontend step). Prepare work: runs during the provision wait and never touches the backend."
+description: "Step 5 (design) of the Hostinger Headless flow. Derives three distinct design directions from brief.md (plus any reference sites and brand assets), lets the user pick one in a single question, checks the chosen one against the 8-point grid and WCAG 2.2 AA, designs the logo as outlined SVG (wordmark, icon mark, favicon), following any logo wish the owner gave, then writes design.md — tokens, type, logo, components, per-page composition, accessibility and imagery — as the contract the frontend implements (the framework/stack is chosen later by the frontend step). When the brief says to keep an existing look, writes design.md from that look and its own logo instead. Prepare work: runs during the provision wait and never touches the backend."
 ---
 
 # headless-step-design
@@ -26,8 +26,8 @@ This is **prepare work**: it runs while provision settles (see *Background provi
 barrier* in the top-level `SKILL.md`). Nothing here calls the Hostinger connector or the backend.
 
 **Keep it short.** Refine already asked about tone and look; don't ask again. The step asks the user
-**one** question: either the keep/change question (Step 1) or the three directions (Step 4), never
-both. "You decide" is a valid answer.
+**one** question: either the keep/change question (Step 1 and *Keep the current look*) or the three
+directions (Step 4), never both. "You decide" is a valid answer.
 
 **Talk like a person, not a designer.** Everything the user reads describes how the site will
 **look and feel**: colours by name ("hot pink, butter yellow"), lettering by feel ("big chunky
@@ -61,6 +61,36 @@ Read `brief.md`, `state.json`, and `content-model.md` if it exists.
   as it is, only the look changes, and they'll see a preview before it goes live. Then run Steps 2–7
   as normal. The current `design.md` becomes one more signal in Step 2, so carry over what the user
   wants to keep and move away from the rest.
+- **The brief says to keep the current look** (*Design direction* says so in the owner's words:
+  "keep the look we have", "same look, new platform") → follow *Keep the current look* below instead
+  of Steps 2–6. No three directions and no new logo. A live site, screenshots or a brand guide alone
+  are signals for Step 2, not a request to keep.
+
+### Keep the current look
+
+1. **Read the look from what the brief points at.** A live site: use Step 2's reference-site method
+   (computed fonts, colours by painted area, the feel), but this site is the owner's own, so take its
+   logo file as it is (the header `<img>` or inline `<svg>`, plus its favicon if it has one) and save
+   it unchanged in `brand/`. Screenshots or a brand guide: read the colours and lettering from them;
+   a logo seen only in a screenshot counts as no logo file, so list "logo file needed" under gaps in
+   the final report. Files or exact colours and fonts the owner supplied win over anything you read.
+2. **Confirm in one question.** Describe the kept look in two plain sentences and ask: *keep it, or
+   change something?* "Keep the look we have" still gets this question; skip it only when the brief
+   says to change nothing at all ("keep it exactly as it is"). Change →
+   apply only what they asked for; a request for a new logo runs Step 6 for the logo alone.
+3. **Check it** as in Step 5. The kept colours are fixed like brand colours: a pair that fails gets a
+   shade of the same hue in that role only. Spacing moves to the nearest grid value, and a font
+   without an `@fontsource` package swaps to the closest one that resolves (5.4).
+4. **Logo.** Reuse the existing logo and favicon unchanged; never redraw or recolour them. With no
+   existing logo, the header shows the site name as text in the kept display font, and no logo is
+   designed.
+5. **Write `design.md`** (Step 7) from the kept look, then hand off as usual. In **Logo**:
+   - *Files* and *Use* name the files as saved (a `.png` stays a `.png`), or say "No favicon kept".
+   - *Built from* says "Kept, not rebuilt". *Measured* still gives the width at `--logo-h-sm`
+     (≤ 192 px; else lower `--logo-h-sm` or show the name as text on small screens), and the header
+     link has `alt` = the site name and a target of at least 24 px (as in Step 6).
+   - With no logo: *Files* says "None", *Use* says the header link holds the site name as text in
+     `--font-display` and the browser's default favicon stays, and the *Don't* line is dropped.
 
 ## Step 2 — Collect the signals
 
@@ -86,9 +116,9 @@ works, say so in one line and continue from the brief alone. Pull **cues**:
 - **Feel:** look at the first screen and one further down (screenshots shown to you, not saved in
   the workspace) and note what creates the feel: type weight, colour blocking, shapes, density.
 
-**Borrow cues, never assets.** Don't use its logo, copy, images or exact layout. **The brief wins**
-over the live site when they disagree (the user's words are what they want). Note the mismatch in
-the direction.
+**Borrow cues, never assets** (the owner's own site under *Keep the current look* is the exception).
+Don't use its logo, copy, images or exact layout. **The brief wins** over the live site when they
+disagree (the user's words are what they want). Note the mismatch in the direction.
 
 **Brand colours that fail contrast** are still fixed, but only in roles where they pass. A pale brand
 yellow can be a background band or a large decorative shape, never body text. Say so in the
@@ -117,7 +147,9 @@ Each direction carries exactly this:
 - **Signature element** — the one memorable move (a scrolling marquee, stickers, oversized numerals,
   a duotone photo treatment). If it moves on its own, it gets a pause control (5.3).
 - **Logo idea** — one line on how the name becomes a logo, using a move from Step 6 ("letters
-  bounce in different colours and the O is a smiley").
+  bounce in different colours and the O is a smiley"). When the brief carries a logo wish (*Design
+  direction* or *Assets*), every direction's logo idea is that wish in its own style. A wish is words
+  describing a logo; a logo file in *Assets* is a supplied logo and wins (Step 6).
 
 **Only offer what can pass.** Before asking, run two quick gates on **all three**:
 
@@ -144,7 +176,8 @@ option as one line in the same shape.
 
 The description says what the site would feel like, the main colours by name, what the lettering
 is like, the logo idea, and the one detail they'll remember. Hex codes and font names stay in your
-notes.
+notes. The question may end with one plain clause saying they can add a logo idea to their pick, but
+never suggest one or give an example: that idea would end up in the logo.
 
 > **Sticker-book maximal** — Loud and playful, like a scrapbook: candy pink, butter yellow and lilac,
 > chunky headlines, tilted sticker photos and a bouncy logo with a smiley O.
@@ -154,12 +187,19 @@ notes.
 
 Then:
 
-- **Pick** → use it as written.
+- **Pick** → use it as written, and confirm the look in one line.
 - **"You decide" / skipped** → use A, and tell them in one line which look you went with.
 - **A mix** ("A's colours with C's fonts") → merge them. Don't ask again.
 - **Something else** → build a direction from what they said, run Step 5, and use it. Don't send
   three new options.
 
+**Logo wish.** An answer can carry a logo idea next to the pick ("A, and make the logo a little
+teapot"); it replaces the chosen direction's logo idea, and wins over a wish from the brief.
+Whenever the logo follows a wish, from the answer or the brief, add it once to the line that confirms
+the pick: *"The logo follows your idea: a little teapot."* If the kit can't draw it as said (a
+detailed illustration, a photo), build its closest kit version and name what you simplified in that
+same line. Don't ask a follow-up.
+
 Don't ask about anything else in this step.
 
 ## Step 5 — Check the chosen direction
@@ -246,8 +286,8 @@ read; the variable ones ship only `.woff2`.
 skip the rest of this step. Never redraw or recolour it.
 
 Otherwise, turn the name into a **designed** logo: shaped, coloured and composed. Typing the name in
-the display font with an emoji or symbol next to it doesn't count. Build the **logo idea** from the
-chosen direction with one or two of these moves:
+the display font with an emoji or symbol next to it doesn't count. Build the chosen direction's **logo
+idea** (as replaced by any logo wish, Step 4) with one or two of these moves:
 
 | Move | What it is | Suits |
 |---|---|---|
@@ -347,7 +387,8 @@ If content prepare hasn't sourced images yet, it now follows `design.md` → **I
 
 > Direction **<name>**, selected on <YYYY-MM-DD> from three options (others offered: <B name>,
 > <C name>). <"Picked by the user." | "User said 'you decide'; recommendation A used." |
-> "Merged by the user: <what>.">
+> "Merged by the user: <what>."> — or, when kept: "Kept the owner's current look from <site URL |
+> screenshots | brand guide>, confirmed on <YYYY-MM-DD>."
 
 ## Direction
 <2–3 sentences: the mood, what it borrows from the references (and any brief/reference mismatch),
@@ -401,7 +442,9 @@ confirms the framework (default Next.js SSR; ecommerce must be SSR) and records
 - **Body:** <family> (`@fontsource-variable/<slug>@<version>`); `--text-body` / `--leading-body`, measure ≤ 68ch
 
 ## Logo
-- **Concept:** <the move(s), and what any swapped letter or symbol stands for | "Supplied by the user">
+- **Concept:** <the move(s), and what any swapped letter or symbol stands for, plus "From the owner:
+  '<their words>'" only when it follows their wish | "Supplied by the user" | "Kept from <source>" |
+  "No logo: owner kept the current look" (header shows the site name as text in `--font-display`)>
 - **Built from:** `@fontsource/<display-slug>@<version>`, weight(s)/style(s) …
 - **Files:** `brand/logo.svg` (header, `--logo-h` desktop / `--logo-h-sm` small screens),
   `brand/logo-mark.svg`, `brand/favicon.svg`<, `brand/logo-seal.svg`>; source `brand/logo-build.mjs`
@@ -449,14 +492,15 @@ duotone…); alt text written from what the photo shows.>
 ## Invariants
 
 - **One question.** Refine owns discovery; this step only chooses among directions (or keeps the
-  existing one).
+  existing look).
 - **8-point grid, always.** No spacing, size, radius or breakpoint off the grid except the listed
   exemptions.
 - **WCAG 2.2 AA is the floor.** No direction is offered, chosen or written that fails it. Brand
   colours keep their hue but only appear in roles where they pass.
 - **Brand assets are fixed.** A supplied logo, colour or font appears in every direction, unchanged.
 - **A logo is designed, not typed.** Outlined SVG paths built with the logo kit, never live text,
-  emoji or clip-art, and always readable at its smallest use.
+  emoji or clip-art, and always readable at its smallest use. The one exception: a kept look with no
+  logo shows the site name as text and gets no new logo.
 - **Self-hosted fonts only** (`@fontsource`). No Google Fonts or other font CDN links in the output.
 - **The tokens block is the only source of values** (breakpoints excepted). Components and pages
   reference tokens, never raw hex codes, pixel values or font names.