SkillCDN 팩

A new web app, from an idea to live

What goes in: an idea in the user's words and the answers to a few plain questions. What comes out: a git repository with a TypeScript web app that runs locally and passes one check, mobile-first, speaking every language the user named, ready for search and AI engines, with its share image and favicon set, sign-in, a database, analytics and tests; a brief, a look and a working agreement that let developers, planners and designers keep working in it with their own agents; and, through cloudflare-deploy, the app live at its address with deploys on every push. The user never needs to know the stack: every technical choice is derived from their answers, shown with its reason, and changed when they ask.

How the user is involved

• Questions: one message at the start, the ones in intake.md that the request leaves open, each in plain words. Everything else is derived and shown in the plan.
• Checkpoints: the plan, before any file of the project is written; the look, with the home page in front of them, before the pages are built on it; then the deploy skill's own stops (a purchase, the first deploy, every push). Each is one short message in plain words, with a recommendation, and one word continues.
• Go-ahead: when the user says to go ahead alone, the questions with defaults are not asked (the defaults are shown in the plan) and the look is reported instead of approved. The plan, and every stop of the deploy skill, hold in every mode. An answer that hands one question or one plan to the agent ("you decide the first day", "the rest as you proposed") answers that question; it is not a go-ahead, and the checkpoints stay.
• Changes mid-run: applied from that point. A changed plan after the build rewrites the parts it touches, not the whole app.

Requirements

Check these before the first message. Without Node.js or git, stop and say what to install. Without network, stop: nothing can be scaffolded.

The Cloudflare skills share the area's document set engineering/docs/cloudflare/: platform.md (the runtime, the configuration, bindings and secrets, the framework paths, the plans) is included and arrives with this skill wherever SkillCDN serves it; tokens.md (the token steps) is linked from the intake and automation.md from the launch, read with read_repo_file through the repository or engineering connection, from the engineering plugin's docs/cloudflare/, or from a checkout of this repository. A mount of this skill alone lacks the two linked pages and a copy of its directory lacks all three: say so in the first message, fetch them from engineering/docs/cloudflare/ of the repository this skill comes from (github.com/skillcdn/skills for this pack) where the agent can, and otherwise run on this skill's own files, which carry its workflow and its rules. The launch is cloudflare-deploy of the same area; where it cannot be loaded, the delivery says so and gives the user its name and address. tool-notes.md holds what the tools did in runs, read before the build and when a tool misbehaves.

Inputs

The questions are written in intake.md, in the words to use; intake.md also says what each answer derives and holds the plan message.

Workflow

Each phase produces a named artifact and ends with one line to the user. The build's pieces are reported, not approved one by one.

Phase 1: Intake

Produces the brief as text in the agent's notes: the idea in a paragraph, who uses it and on what, who runs it, the languages, the pages and what each does, what is kept (the data, in plain words), sign-in, the domain, the look direction, and what is out of scope for the first version. Ask the questions of intake.md in one short message, derive the rest. In a second message, tell the user to create the Cloudflare token now with the steps of tokens.md (its always rows, and the Registrar row only if they answer that a domain is to be bought), saved as .cf-token in the folder the project will be created in, so that the launch does not wait; the run goes on while they do. The brief is written to docs/brief.md once the project exists (phase 4).

Phase 2: Plan

Produces the plan, shown at the checkpoint with the message intake.md gives, and kept in the brief. From the brief: the name and the folder, the pages and their routes (intake.md "Pages every app gets"), the data model, the locales, sign-in and the guest path, the stack with the adapter the framework guide names today (platform.md "Next.js and other frameworks"), the folder structure and packages (stack.md), the brand files, analytics, the tests, the agreement, the launch steps and what they cost (platform.md "Plans"). The technical choices are one phrase each, with the reason; the user may change any, including the name.

Phase 3: Design

Produces the look (docs/brand.md, the tokens in the stylesheet, the brand symbol as SVG) and the home page built on it. Derive a palette, type per script, spacing, radius, motion and tone from the look direction (stack.md "The look"); when the host has a design skill installed, use it for this phase and record what it decided in docs/brand.md. Scaffold the project and lay the single sources and the routing (phase 4, steps 1 to 3, minutes of work) so that the home page is built once, in every locale; build the home page (a page that is empty without data gets a development-only switch, a ?preview=<state> query read only on the dev server, that fills it with sample states), and show it: a screenshot when a browser is available, otherwise the local address with "run npm run dev in the project folder and open it in a narrow window; for a phone, start it with the dev server's host flag (--host on a Vite-based server) and open the network address it prints", because a server the agent starts ends with its turn. Checkpoint: "Here is the look: <three words>, <palette>, <type>. The alternative would be <one line>. Keep it?"

Phase 4: Build

Produces the app. In this order, each step reported in a line and verified before the next:

1. Scaffold with the path platform.md names, as stack.md "Scaffold" says (the command and its flags, what it makes, what is moved, the versions pinned, the branch renamed), keep the commit the scaffold makes when it makes one, write docs/brief.md, then the project files of stack.md "Files at the root": .gitignore, .gitattributes, .editorconfig, the Node.js version file, .dev.vars.example, .claude/settings.json, and the scripts check, typecheck, lint, test. The user's .cf-token moves into the project once .gitignore lists it.
2. The structure of stack.md: the single sources (config/i18n.ts, config/site.ts with the site URL read from the public build variable, config/features.ts), the platform access module, the folders, the database entry with its placeholder id.
3. Localization as localization.md says: the locale list, the dictionaries typed for completeness, the routing, per-locale metadata, formatting, the switcher.
4. The pages of the brief on the tokens, mobile-first (stack.md "Mobile first"), with the shell (header, footer, switcher, sign-in state).
5. The data: the first migration, a module per entity under lib/db/, applied locally; the AI module as stack.md "AI text" says when the app writes text (the model chosen from the list and recorded with its price in docs/decisions.md, the key read from the local secrets file, the shape check, the fallback, the daily cap); when the brief asks for sample content (a demo, a mockup's figures), db/seed.sql as stack.md says, applied locally and named in the handover.
6. Sign-in as auth.md says: the core action works for a guest on this device, sign-in claims it, and the provider stays off until its keys exist. Generate the local SESSION_SECRET into .dev.vars here (never shown), so that the dev server signs sessions without a warning, and, when the app has an operator screen, ADMIN_SECRET and ADMIN_PASSWORD, the password also written to a file in the folder above the project so that the user can open the screen locally; the deploy skill generates the live ones.
7. Search and AI readiness, the share image and the favicon set, analytics with its slot for the beacon token, as seo-geo.md says. The rendered share image and icons are looked at with the host's image reading (a PNG opened with the file tool), browser or not.
8. Tests: the dictionary test,