scaffold: preview-site skill — start the harness locally and hand over the link (+ serve prints the preview URL) #245

New issue

Closed

opened 2026-10-12 22:54:49 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-10-12 22:54:49 +02:00

Owner

This was generated by AI during triage.

Summary

Add a scaffolded skill, preview-site, that is the one procedure for "start the harness locally and give me the link": start harness serve without blocking the agent's shell, wait until the editor and the Hugo preview are actually ready, hand the developer the editor URL and the plain preview URL, keep it running, restart it when needed, stop it. Every other skill that needs the editor points at it instead of restating harness serve --site .. As a small engine nicety, harness serve also prints the preview URL once Hugo is ready, so a human running it in a terminal sees both links without the skill.

The goal: a developer (or an agent on their behalf) can start the site locally in one step and get a link, so the customer or the developer can check that everything works and looks the way they want before anything is committed or published.

Current behavior

harness serve --site . is a foreground process. It prints one line at listen time — deckle harness listening on http://127.0.0.1:8090/ — and blocks until SIGINT/SIGTERM. The preview (Hugo) URL is only visible through GET /api/status (hugo.previewURL) and the editor's View module; it is never printed. Readiness is two-phase: the listener is up first, Hugo becomes running later (on a first run the pinned Hugo is downloaded first, which can take a minute), or crashed with hugo.lastBuildError/hugo.output in the status payload.

The scaffolded skills (scaffold/site/.claude/skills/) mention the command inline in five places and say "open the printed address" — verify-site step 3 "Smoke-test in the editor", redo-theme step 3 "The showcase page" and references/showcase-page.md, setup-site step 4 "Report", edit-content (the "open the page once in the editor so the harness stamps them" step), migrate-site step 9 "Verify and hand over". None says how to run it in the background from an agent shell, how to tell it is ready, what link to hand over, what to do when the default port is busy, how to stop or restart it, or that Publish from a local run pushes main. In practice the developer never gets the link.

Desired behavior

The skill `preview-site`

scaffold/site/.claude/skills/preview-site/SKILL.md, with front matter the drift test accepts and a description that covers "run, start, serve, preview, open the site locally, get the link, stop/restart the preview" — the generic run skill in Claude Code looks for a project skill that covers launching the app, so the description must make that match. The procedure, in order:

Harness current — point at AGENTS.md "Installing the harness" (as migrate-site step 0 does; do not restate the install script).
Reuse or start. If something already listens on the default address, decide whether it is a harness for this site (the GET /api/site payload carries the site title and languages; if that is not enough to tell two sites apart, see "Assumptions to check") and reuse it. Otherwise start the harness in the background — output to a log file, PID recorded — in a way that survives the end of the agent's tool call and does not depend on an exported PATH (AGENTS.md "Installing the harness" explains why). If the default port is taken by something that is not this site's harness, start on a free port with --addr 127.0.0.1:0; the harness prints the real address.
Wait until ready. First the listening on line in the log (gives the editor URL), then poll GET /api/status until hugo.state is running. Say that a first run downloads the pinned Hugo and may take a minute. On crashed, report hugo.lastBuildError and the tail of hugo.output, and stop — do not hand over a link to a broken preview.
Hand over the links. Two URLs: the editor (http://127.0.0.1:<port>/) and the plain rendered site (hugo.previewURL from the status payload), plus what to open for the change at hand (the page just edited; /theme-showcase/ after redo-theme; every language's address on a multilingual site, AGENTS.md "Addresses"). The links are loopback only and that is by design (README.md: --addr refuses non-loopback hosts); say so, so nobody tries to share them.
Keep running, restart, stop. The process outlives the turn; the agent says it is running and how to stop it. Which changes need a restart is documented already (AGENTS.md "Languages": a running serve reads harness.yaml only at start; add-backend-layout's note on defaultBackendLayout) — the skill points there and gives the restart as stop-then-start. Stop is SIGTERM to the recorded PID; the harness shuts Hugo down itself.
The Publish caveat, stated plainly. Saving in a local editor only writes files (WIP mode, HEAD on main: README.md "How it works"). Clicking Publish in a local editor commits and pushes main; on a deckle-hosted site (the "Hosting:" line in AGENTS.md "Layout") that goes live. The skill tells the developer to save freely and not to publish from a local run unless that is the intent.

The skill is a procedure: it cites sections of AGENTS.md and README.md for every fact and restates none (CLAUDE.md "Skills are procedures, AGENTS.md and the theme README are the facts"). Facts the manual lacks today go into AGENTS.md (below), not into the skill.

The other skills point at it

Replace the inline harness serve --site . and "open the printed address" in verify-site step 3, redo-theme step 3 and references/showcase-page.md, setup-site step 4 (the report ends with "the site is running at / " when the preview is up), edit-content's stamping step and migrate-site step 9 with a link to ../preview-site/SKILL.md (the skills link each other with relative links the drift test resolves). What each of those steps checks in the editor stays where it is; only the "get it running and get the link" part moves. verify-site keeps its curl … /api/page example but reads the port from what preview-site reported rather than hard-coding 8090.

`AGENTS.md`

The intro's list of skills names the new one (the drift test checks the intro names the skills).
A new fact section, e.g. "## Previewing locally", that the skill cites: the default address and that only loopback hosts are accepted; --addr 127.0.0.1:0 for a free port and that the real address is printed; the two readiness phases and the GET /api/status fields that report them (hugo.state, hugo.previewURL, hugo.lastBuildError); that the preview URL is printed once Hugo is ready (the nicety below); which changes need a restart (a sentence pointing at the existing "Languages" and layout notes, or a consolidated list — one owner for that list, the other mentions point at it); and the Publish caveat. Keep it short; the host-side preview flags stay in README.md and are not for sites.

Engine nicety: print the preview URL when Hugo is ready

harness serve today prints only the listen line on stdout. Once the supervisor reports running for the first time, print one more line on stdout with the preview URL, e.g. site preview ready at http://127.0.0.1:<port>/ — the same hugo.previewURL value the status endpoint serves (so with --preview-base-url it is the public URL). Print it once per process, not on every restart after a crash; on a crash before the first running, nothing extra is printed (stderr already carries the crash log). README.md "Quick start" and the serve bullet under the command list, and the harness init "Next steps" line if its wording changes, document the second line.

Decisions

One skill, not a section in verify-site. Starting the preview is needed by five skills and by the plain "let me look at it" request that is none of them; a skill of its own is what the generic run skill discovers and what setup-site's hand-over can end with.
Name preview-site. Settled by the maintainer. It is a verb-noun like the others and matches what the developer asks for.
The agent reads readiness from the status endpoint; nothing is re-derived. "Is Hugo ready", "where is the preview" and "what went wrong" are verdicts the server already serves; the skill polls them. "Is this a Hugo site" stays in the serve command. No new rule is introduced.
Default port first, free port as fallback. A stable :8090 makes the link the same across restarts and matches the existing docs; --addr 127.0.0.1:0 already exists and prints the real address, so no port-scanning logic is needed anywhere.
The nicety is a second stdout line, not a change to the first. Tools and docs that grep listening on keep working; the new line uses the status endpoint's value so the two never disagree.
No --open, no daemon mode, no --json for serve. Backgrounding via the shell is enough for the agent, and a human in a terminal sees both links. Not needed for the goal.

Key interfaces

cmd/harness/main.go: serve, parseServeArgs, the listening on print; printInitResult "Next steps".
internal/supervisor: Supervisor.Status() → Status{State, PreviewURL, LastBuildError, Output}; states starting/running/crashed. The nicety needs a way to learn of the first running transition (a callback in supervisor.Config, or polling Status() from serve) — the supervisor owns the state, serve only prints.
internal/server/server.go: handleStatus / statusResponse (hugo.state, hugo.previewURL, hugo.lastBuildError, hugo.output), GET /api/site (siteResponse).
scaffold/skills_test.go: expectedSkills, harnessCommands, TestSkillLinksResolve, TestSkillSectionReferencesExist (every quoted AGENTS.md "…" / README.md "…" heading must exist), TestAgentsDocNamesSkills.
scaffold/site/AGENTS.md, scaffold/site/.claude/skills/*/SKILL.md, README.md.

Skills affected (CLAUDE.md)

New: preview-site.
Edited to point at it: verify-site (step 3), redo-theme (step 3, references/showcase-page.md), setup-site (step 4 report), edit-content (stamping step), migrate-site (step 9).
Unchanged: add-element, remove-element, add-page-type, add-backend-layout, create-feature (they end in verify-site, which now links on).

Rules and owners

Hugo readiness, preview URL, build error: owned by internal/supervisor (Status), served by /api/status; the skill and the new stdout line both read it, neither re-derives it.
"Which changes need a serve restart": today spelled in AGENTS.md "Languages" and in add-backend-layout; after this change one place in AGENTS.md owns the list and the others point at it.
The loopback-only rule for --addr: owned by parseServeArgs; AGENTS.md states the consequence (the link is local), not the rule.

Acceptance criteria

scaffold/site/.claude/skills/preview-site/SKILL.md exists, passes go test ./scaffold/... (skill set, front matter, links, quoted headings, command names), and walks through the six steps above citing AGENTS.md/README.md sections for every fact.
An agent following the skill in a fresh harness init site, with no harness on PATH and the binary at ~/.deckle/harness/harness, ends with both URLs reported, the harness still running after the tool call that started it, and a working stop. Exercise it with a run_in_background-free shell (nohup … & or setsid) to prove it does not rely on the agent runtime.
With another process on 127.0.0.1:8090, the skill's fallback yields a working editor on a different port and reports that port.
With a site whose harness.yaml names a Hugo version that cannot be downloaded (or a theme that fails to build), the skill reports the crash from the status payload and hands over no link.
verify-site, redo-theme (+ showcase reference), setup-site, edit-content, migrate-site no longer contain the inline harness serve --site . start-and-open instruction; each links to preview-site.
AGENTS.md's intro names preview-site, and a "Previewing locally" (or equivalently named) section states the facts listed above; internal/element/agentsdoc_test.go and scaffold/skills_test.go stay green.
harness serve prints, after deckle harness listening on …, exactly one … ready at <previewURL> line on stdout on the first transition to running, none on a crash before it, none again after a crash-and-restart; a test in cmd/harness covers the once-only behaviour with a fake provider or supervisor hook.
README.md Quick start shows both lines; the serve bullet mentions the second.
The Publish caveat appears in the skill (as a pointer) and in AGENTS.md (as the fact).

How to verify

go test ./... and go vet ./....
make build, then in a scratch site from ./harness init --site /tmp/x: run ./harness serve --site /tmp/x in a terminal and see both lines; run it again with --addr 127.0.0.1:0 and see the chosen port in the first line.
Follow preview-site literally from a shell with no PATH export and the binary addressed by full path; confirm the URLs open; kill <pid>; confirm Hugo is gone too (pgrep hugo).
Grep the skills tree for harness serve — the remaining mentions are facts about serve behaviour (restart-on-config, pinned Hugo cache), not start instructions.

Assumptions to check

That GET /api/site carries enough to tell "a harness for this site" from "a harness for another site on the same port" (title plus languages may collide between two sites). If not, either compare the site directory (serve knows siteDir; adding it to the site payload is a small, server-owned verdict) or have the skill treat any foreign listener on the port as "use a free port" and say so.
That the supervisor exposes, or can cheaply expose, the first running transition without a polling loop in serve; check internal/supervisor for an existing readiness channel/callback before adding one.
That the Claude Code run skill's project-skill discovery keys on the description text; phrase the description accordingly and spot-check once.
That no existing test in cmd/harness asserts stdout is exactly one line for serve.

Out of scope

A --open flag, a daemon/detach mode, or --json output for serve.
Making serve fall back to a free port on its own when the default is taken (the skill does it; the command's behaviour stays explicit).
Changing what the editor's Publish does locally.
The host-side preview flags (--preview-port, --preview-base-url) and their docs.
Anything in the View module itself — #241 (remove the editor bridge) edits verify-site step 3 and redo-theme step 4 too; whichever lands second rebases over the other. Not a blocker.

Blocked by

None - can start immediately

> *This was generated by AI during triage.* ## Summary Add a scaffolded skill, `preview-site`, that is the one procedure for "start the harness locally and give me the link": start `harness serve` without blocking the agent's shell, wait until the editor and the Hugo preview are actually ready, hand the developer the editor URL and the plain preview URL, keep it running, restart it when needed, stop it. Every other skill that needs the editor points at it instead of restating `harness serve --site .`. As a small engine nicety, `harness serve` also prints the preview URL once Hugo is ready, so a human running it in a terminal sees both links without the skill. The goal: a developer (or an agent on their behalf) can start the site locally in one step and get a link, so the customer or the developer can check that everything works and looks the way they want before anything is committed or published. ## Current behavior `harness serve --site .` is a foreground process. It prints one line at listen time — `deckle harness listening on http://127.0.0.1:8090/` — and blocks until SIGINT/SIGTERM. The preview (Hugo) URL is only visible through `GET /api/status` (`hugo.previewURL`) and the editor's View module; it is never printed. Readiness is two-phase: the listener is up first, Hugo becomes `running` later (on a first run the pinned Hugo is downloaded first, which can take a minute), or `crashed` with `hugo.lastBuildError`/`hugo.output` in the status payload. The scaffolded skills (`scaffold/site/.claude/skills/`) mention the command inline in five places and say "open the printed address" — `verify-site` step 3 "Smoke-test in the editor", `redo-theme` step 3 "The showcase page" and `references/showcase-page.md`, `setup-site` step 4 "Report", `edit-content` (the "open the page once in the editor so the harness stamps them" step), `migrate-site` step 9 "Verify and hand over". None says how to run it in the background from an agent shell, how to tell it is ready, what link to hand over, what to do when the default port is busy, how to stop or restart it, or that Publish from a local run pushes `main`. In practice the developer never gets the link. ## Desired behavior ### The skill `preview-site` `scaffold/site/.claude/skills/preview-site/SKILL.md`, with front matter the drift test accepts and a description that covers "run, start, serve, preview, open the site locally, get the link, stop/restart the preview" — the generic `run` skill in Claude Code looks for a project skill that covers launching the app, so the description must make that match. The procedure, in order: 1. **Harness current** — point at `AGENTS.md` "Installing the harness" (as `migrate-site` step 0 does; do not restate the install script). 2. **Reuse or start.** If something already listens on the default address, decide whether it is a harness for *this* site (the `GET /api/site` payload carries the site title and languages; if that is not enough to tell two sites apart, see "Assumptions to check") and reuse it. Otherwise start the harness in the background — output to a log file, PID recorded — in a way that survives the end of the agent's tool call and does not depend on an exported PATH (`AGENTS.md` "Installing the harness" explains why). If the default port is taken by something that is not this site's harness, start on a free port with `--addr 127.0.0.1:0`; the harness prints the real address. 3. **Wait until ready.** First the `listening on` line in the log (gives the editor URL), then poll `GET /api/status` until `hugo.state` is `running`. Say that a first run downloads the pinned Hugo and may take a minute. On `crashed`, report `hugo.lastBuildError` and the tail of `hugo.output`, and stop — do not hand over a link to a broken preview. 4. **Hand over the links.** Two URLs: the editor (`http://127.0.0.1:<port>/`) and the plain rendered site (`hugo.previewURL` from the status payload), plus what to open for the change at hand (the page just edited; `/theme-showcase/` after `redo-theme`; every language's address on a multilingual site, `AGENTS.md` "Addresses"). The links are loopback only and that is by design (`README.md`: `--addr` refuses non-loopback hosts); say so, so nobody tries to share them. 5. **Keep running, restart, stop.** The process outlives the turn; the agent says it is running and how to stop it. Which changes need a restart is documented already (`AGENTS.md` "Languages": a running serve reads `harness.yaml` only at start; `add-backend-layout`'s note on `defaultBackendLayout`) — the skill points there and gives the restart as stop-then-start. Stop is SIGTERM to the recorded PID; the harness shuts Hugo down itself. 6. **The Publish caveat, stated plainly.** Saving in a local editor only writes files (WIP mode, HEAD on `main`: `README.md` "How it works"). Clicking **Publish** in a local editor commits and pushes `main`; on a deckle-hosted site (the "Hosting:" line in `AGENTS.md` "Layout") that goes live. The skill tells the developer to save freely and not to publish from a local run unless that is the intent. The skill is a procedure: it cites sections of `AGENTS.md` and `README.md` for every fact and restates none (CLAUDE.md "Skills are procedures, AGENTS.md and the theme README are the facts"). Facts the manual lacks today go into `AGENTS.md` (below), not into the skill. ### The other skills point at it Replace the inline `harness serve --site .` and "open the printed address" in `verify-site` step 3, `redo-theme` step 3 and `references/showcase-page.md`, `setup-site` step 4 (the report ends with "the site is running at <editor link> / <preview link>" when the preview is up), `edit-content`'s stamping step and `migrate-site` step 9 with a link to `../preview-site/SKILL.md` (the skills link each other with relative links the drift test resolves). What each of those steps checks *in* the editor stays where it is; only the "get it running and get the link" part moves. `verify-site` keeps its `curl … /api/page` example but reads the port from what `preview-site` reported rather than hard-coding 8090. ### `AGENTS.md` - The intro's list of skills names the new one (the drift test checks the intro names the skills). - A new fact section, e.g. "## Previewing locally", that the skill cites: the default address and that only loopback hosts are accepted; `--addr 127.0.0.1:0` for a free port and that the real address is printed; the two readiness phases and the `GET /api/status` fields that report them (`hugo.state`, `hugo.previewURL`, `hugo.lastBuildError`); that the preview URL is printed once Hugo is ready (the nicety below); which changes need a restart (a sentence pointing at the existing "Languages" and layout notes, or a consolidated list — one owner for that list, the other mentions point at it); and the Publish caveat. Keep it short; the host-side preview flags stay in `README.md` and are not for sites. ### Engine nicety: print the preview URL when Hugo is ready `harness serve` today prints only the listen line on stdout. Once the supervisor reports `running` for the first time, print one more line on stdout with the preview URL, e.g. `site preview ready at http://127.0.0.1:<port>/` — the same `hugo.previewURL` value the status endpoint serves (so with `--preview-base-url` it is the public URL). Print it once per process, not on every restart after a crash; on a crash before the first `running`, nothing extra is printed (stderr already carries the crash log). `README.md` "Quick start" and the `serve` bullet under the command list, and the `harness init` "Next steps" line if its wording changes, document the second line. ## Decisions - **One skill, not a section in `verify-site`.** Starting the preview is needed by five skills and by the plain "let me look at it" request that is none of them; a skill of its own is what the generic `run` skill discovers and what `setup-site`'s hand-over can end with. - **Name `preview-site`.** Settled by the maintainer. It is a verb-noun like the others and matches what the developer asks for. - **The agent reads readiness from the status endpoint; nothing is re-derived.** "Is Hugo ready", "where is the preview" and "what went wrong" are verdicts the server already serves; the skill polls them. "Is this a Hugo site" stays in the serve command. No new rule is introduced. - **Default port first, free port as fallback.** A stable `:8090` makes the link the same across restarts and matches the existing docs; `--addr 127.0.0.1:0` already exists and prints the real address, so no port-scanning logic is needed anywhere. - **The nicety is a second stdout line, not a change to the first.** Tools and docs that grep `listening on` keep working; the new line uses the status endpoint's value so the two never disagree. - **No `--open`, no daemon mode, no `--json` for serve.** Backgrounding via the shell is enough for the agent, and a human in a terminal sees both links. Not needed for the goal. ## Key interfaces - `cmd/harness/main.go`: `serve`, `parseServeArgs`, the `listening on` print; `printInitResult` "Next steps". - `internal/supervisor`: `Supervisor.Status()` → `Status{State, PreviewURL, LastBuildError, Output}`; states `starting`/`running`/`crashed`. The nicety needs a way to learn of the first `running` transition (a callback in `supervisor.Config`, or polling `Status()` from `serve`) — the supervisor owns the state, `serve` only prints. - `internal/server/server.go`: `handleStatus` / `statusResponse` (`hugo.state`, `hugo.previewURL`, `hugo.lastBuildError`, `hugo.output`), `GET /api/site` (`siteResponse`). - `scaffold/skills_test.go`: `expectedSkills`, `harnessCommands`, `TestSkillLinksResolve`, `TestSkillSectionReferencesExist` (every quoted `AGENTS.md "…"` / `README.md "…"` heading must exist), `TestAgentsDocNamesSkills`. - `scaffold/site/AGENTS.md`, `scaffold/site/.claude/skills/*/SKILL.md`, `README.md`. ## Skills affected (CLAUDE.md) - New: `preview-site`. - Edited to point at it: `verify-site` (step 3), `redo-theme` (step 3, `references/showcase-page.md`), `setup-site` (step 4 report), `edit-content` (stamping step), `migrate-site` (step 9). - Unchanged: `add-element`, `remove-element`, `add-page-type`, `add-backend-layout`, `create-feature` (they end in `verify-site`, which now links on). ## Rules and owners - Hugo readiness, preview URL, build error: owned by `internal/supervisor` (`Status`), served by `/api/status`; the skill and the new stdout line both read it, neither re-derives it. - "Which changes need a serve restart": today spelled in `AGENTS.md` "Languages" and in `add-backend-layout`; after this change one place in `AGENTS.md` owns the list and the others point at it. - The loopback-only rule for `--addr`: owned by `parseServeArgs`; `AGENTS.md` states the consequence (the link is local), not the rule. ## Acceptance criteria - [ ] `scaffold/site/.claude/skills/preview-site/SKILL.md` exists, passes `go test ./scaffold/...` (skill set, front matter, links, quoted headings, command names), and walks through the six steps above citing `AGENTS.md`/`README.md` sections for every fact. - [ ] An agent following the skill in a fresh `harness init` site, with no `harness` on PATH and the binary at `~/.deckle/harness/harness`, ends with both URLs reported, the harness still running after the tool call that started it, and a working stop. Exercise it with a `run_in_background`-free shell (`nohup … &` or `setsid`) to prove it does not rely on the agent runtime. - [ ] With another process on `127.0.0.1:8090`, the skill's fallback yields a working editor on a different port and reports that port. - [ ] With a site whose `harness.yaml` names a Hugo version that cannot be downloaded (or a theme that fails to build), the skill reports the crash from the status payload and hands over no link. - [ ] `verify-site`, `redo-theme` (+ showcase reference), `setup-site`, `edit-content`, `migrate-site` no longer contain the inline `harness serve --site .` start-and-open instruction; each links to `preview-site`. - [ ] `AGENTS.md`'s intro names `preview-site`, and a "Previewing locally" (or equivalently named) section states the facts listed above; `internal/element/agentsdoc_test.go` and `scaffold/skills_test.go` stay green. - [ ] `harness serve` prints, after `deckle harness listening on …`, exactly one `… ready at <previewURL>` line on stdout on the first transition to `running`, none on a crash before it, none again after a crash-and-restart; a test in `cmd/harness` covers the once-only behaviour with a fake provider or supervisor hook. - [ ] `README.md` Quick start shows both lines; the `serve` bullet mentions the second. - [ ] The Publish caveat appears in the skill (as a pointer) and in `AGENTS.md` (as the fact). ## How to verify - `go test ./...` and `go vet ./...`. - `make build`, then in a scratch site from `./harness init --site /tmp/x`: run `./harness serve --site /tmp/x` in a terminal and see both lines; run it again with `--addr 127.0.0.1:0` and see the chosen port in the first line. - Follow `preview-site` literally from a shell with no PATH export and the binary addressed by full path; confirm the URLs open; `kill <pid>`; confirm Hugo is gone too (`pgrep hugo`). - Grep the skills tree for `harness serve` — the remaining mentions are facts about serve behaviour (restart-on-config, pinned Hugo cache), not start instructions. ## Assumptions to check - That `GET /api/site` carries enough to tell "a harness for this site" from "a harness for another site on the same port" (title plus languages may collide between two sites). If not, either compare the site directory (serve knows `siteDir`; adding it to the site payload is a small, server-owned verdict) or have the skill treat any foreign listener on the port as "use a free port" and say so. - That the supervisor exposes, or can cheaply expose, the first `running` transition without a polling loop in `serve`; check `internal/supervisor` for an existing readiness channel/callback before adding one. - That the Claude Code `run` skill's project-skill discovery keys on the description text; phrase the description accordingly and spot-check once. - That no existing test in `cmd/harness` asserts stdout is exactly one line for `serve`. ## Out of scope - A `--open` flag, a daemon/detach mode, or `--json` output for `serve`. - Making `serve` fall back to a free port on its own when the default is taken (the skill does it; the command's behaviour stays explicit). - Changing what the editor's Publish does locally. - The host-side preview flags (`--preview-port`, `--preview-base-url`) and their docs. - Anything in the View module itself — #241 (remove the editor bridge) edits `verify-site` step 3 and `redo-theme` step 4 too; whichever lands second rebases over the other. Not a blocker. ## Blocked by None - can start immediately

dominik.polakovics added the

enhancement

ready-for-agent

labels

2026-10-12 22:54:49 +02:00

dominik.polakovics referenced this issue from a commit

2026-10-12 23:30:38 +02:00

feat(serve): print the preview URL once Hugo is first ready

dominik.polakovics referenced this issue from a commit

2026-10-12 23:30:38 +02:00

feat(scaffold): preview-site skill and AGENTS.md "Previewing locally"

dominik.polakovics referenced this issue from a pull request that will close it,