Skip to content
MCP Servers
Skill

/headless

Orchestrator for the Hostinger Headless build flow — build and deploy a real website on the user's Hostinger account from a single prompt that names a domain. Holds the stage flow and the state contract, and drives each stage in sequence: connect, check state, refine, provision,

BOOST
From plugin
api-mcp-server
16320 skills
Install
$ npx -y skills add hostinger/api-mcp-server --skill headless --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/headless

Context preview

The summary Claude sees to decide when to auto-load this skill.

Orchestrator for the Hostinger Headless build flow — build and deploy a real website on the user's Hostinger account from a single prompt that names a domain. Holds the stage flow and the state contract, and drives each stage in sequence: connect, check state, refine, provision,

SKILL.md

headless.SKILL.md
name: hostinger-headless
description: "Orchestrator for the Hostinger Headless build flow — build and deploy a real website on the user's Hostinger account from a single prompt that names a domain. Holds the stage flow and the state contract, and drives each stage in sequence: connect, check state, refine, provision, content model, design, frontend, validate, deploy, done. Triggers: build a headless site for <domain>, build me a site, create a website, make me a website, deploy this to Hostinger, host this on Hostinger, connect this project to Hostinger."

Hostinger Headless — build a website with your own AI tool

Context

You are an AI coding agent. The user pasted a short prompt that points you here — something like:

> Build a Headless site for `example.com` using hostinger.com/headless/skill.md

Your job is to build and deploy a real website on the user's Hostinger account by following this recipe and the recipes it links to — nothing more, nothing less.

This file is the **orchestrator**. It is public and stable: it never changes and never moves. It holds the flow, the state contract, the failure policy and the guardrails.

The domain parameter

The pasted prompt contains exactly two things that matter:

  • **This URL** — `hostinger.com/headless/skill.md`, the stable entry point.
  • **A domain** — e.g. `coral-pottery-1847.hostingersite.com` (a temporary Hostinger subdomain) or

the user's own purchased domain. This is the single site you may touch.

The prompt does **not** say what kind of site to build. Do not assume or invent it. Discovering 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.

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.**

---

The flow stages - STEPS TO FOLLOW

Work through the steps in the order below, each reading its recipe and writing its artifact into the site workspace `~/.hostinger/<domain>/`.

The order is sequencial run and check the whole headless flow:

| # | Stage | Skill / source | Writes | Instance? | |---|--------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------|---|---| | — | **connect** — connect the Hostinger connector, auth, get active plan | `connect/SKILL.md` → `connect/tools/<tool>.md` | `connect.json` | no | | 1 | **check state** — where does this domain stand? resume / switch / start over | `steps/01-check-state/SKILL.md` | `state.json` | no | | 2 | **refine** — discover what the user wants, in conversation | `steps/02-refine/SKILL.md` | `brief.md` | no | | 3 | **provision** — choose the backend from the brief, then provision it | `steps/03-provision/<backend>/SKILL.md` | `site.json` | **bg** — fire, then poll in the background | | 4 | **content model** — define + create content/images, then push to the backend | `steps/04-content-model/<backend>/SKILL.md` | `content-model.md` | prepare: no · **push: yes** | | 5 | **design** — derive design directions from the brief, pick one, write the `design.md` contract + logo | `steps/05-design/SKILL.md` | `design.md`, `brand/` | no | | 6 | **frontend** — pick/confirm the framework (default Next.js SSR), implement `design.md` against the backend | `steps/06-frontend/SKILL.md` | source in `<workspace>/src/` | shell: no · **data: yes** | | 7 | **validate** *(optional)* — quick instance+API confirmation; rebuild/preview/approval only when a person signs off | `steps/07-validate/SKILL.md` | — | no (local) | | 8 | **deploy** — upload source, trigger the build | `steps/08-deploy/SKILL.md` | `deploy.json` | **yes** | | 9 | **done** — hand over URLs, dashboard, summary, next steps (the **final report**) | `steps/09-done/SKILL.md` | — | no |

**The most important is that connect stage runs first and always** It's fetched from the public URL and runs *before* the Hostinger MCP Server is loaded, the main goal of this is to have the Hostinger MCP Server.

You can find those connect skills under `connect/`. The main skill lives in `connect/SKILL.md`. There are also specific tools under `connect/tools/`.

The other 9 numbered steps live under `steps/` and are read from the installed skill folder (this will be guided in connect step).

**One concurrency rule:** two *independent* stages in a single session may run at once, but never two writers of the same artifact, and never two agents/windows on the same domain — the `.lock` (Step 1) guards that. Parallelism is always *optional*: an agent that can't interleave work runs the steps serially and is still correct. Saying this, Always that you consider, you can run the steps in parallel using different threads or processes to save time, but always ensure the right output.

Steps can generate **State files** those files are only hints; the truth is what the Hostinger connector reports, so verify a "done" marker against re

Read more
Ships withapi-mcp-server

Model Context Protocol (MCP) server for Hostinger API.

Get the whole plugin

Other skills on api-mcp-server.