audit-hosting
Audit a Hostinger web hosting account (Shared, Cloud and Agency plans) and report what needs attention: every plan and website,…
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,
$ npx -y skills add hostinger/api-mcp-server --skill headless --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/headlessContext 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,
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."
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 pasted prompt contains exactly two things that matter:
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.**
---
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
Audit a Hostinger web hosting account (Shared, Cloud and Agency plans) and report what needs attention: every plan and website,…
Connect a custom domain to a website on Hostinger web hosting (Shared, Cloud or Agency plans) end to end: attach the domain to…
Deploy an existing project to a website on Hostinger web hosting (Shared, Cloud or Agency plans) and keep it deployed: picks the…
Connect step for the Hostinger Headless flow — verify Node, run the bootstrap (reach the Hostinger MCP server + OAuth sign-in),…
First build step of the Hostinger Headless flow, run right after connect. Works out where a given domain's build stands — is a…
Step 2 (refine) of the Hostinger Headless flow. Turns the user's seed — often just a domain — into a brief through conversation:…