website-build-skill 0.1.0

package/skills/website-build-skill/prompts/08-seo-aeo.md

@@ -0,0 +1,72 @@
+ASK DATE prerequisite: follow playbooks/research-and-memory.md#ask-date-rule.
+Researcher establishes it before intake or research; later roles read scope.md.
+Never ask the user for the date or infer it from model knowledge. Apply the
+same source, two-date, freshness, reuse, and blocked-gate rules to this stage.
+
+Research and implement discoverability for this site's actual audience and content.
+First require accepted research and read site-work/research/library/README.md,
+05-search-and-answers.md, 07-measurement-and-operations.md, and their domain checklists.
+Use the areas below only to top up Optimizer's questions against that library; send
+stale or wrong claims back to Researcher before dependent decisions.
+Use SEO and answer-engine practices with evidence, not guarantees about ranking.
+
+STANDARDS
+- Search the web for every dated claim (tool capabilities, pricing, licensing, trends,
+  platform specs). Never answer those from training memory.
+- Every claim gets a source URL, publication/update date (unknown if absent), and
+  an actual access date on or after the ASK DATE. Open every output file with
+  "Research as of <ASK DATE>".
+- Where sources disagree, record the disagreement - never average it.
+- Mark anything you could not verify as UNVERIFIED.
+
+RESEARCH THESE 8 AREAS
+1. Audience questions and page intent - what someone should learn or do on each route.
+   Go deepest here. Do not make keyword lists substitute for useful answers.
+2. Crawlability - initial HTML, robots rules, status codes, canonical URLs, sitemap,
+   redirects, pagination if relevant, and intentional exclusions.
+3. Entity modeling - truthful identities, stable IDs, ownership, and page relationships.
+   Go deep here too. Pick schema types that fit the site rather than copying a graph.
+4. Answer extraction - standalone answer-first sections, clear headings, attribution,
+   dates where meaningful, and visible evidence behind factual claims.
+5. Structured data - current vocabularies, current consumer support, and exact parity
+   between visible content and markup. Never equate valid schema with rich-result eligibility.
+6. Discovery files - a data-derived sitemap and llms.txt; IndexNow only where supported
+   and authorized. Identify what each consumer actually documents.
+7. Social previews - per-route initial metadata, stable image URLs, actual dimensions,
+   and the difference between an origin response and a third-party cache.
+8. Measurement - indexing evidence, search-console access if provided, CWV, and what
+   cannot yet be measured on a new site. Separate traffic from crawler availability.
+
+SAVE THE RESULTS - two places, both required:
+A. site-work/research/optimizer/:
+   - README.md - current findings and decisions
+   - sources.md - claims, URLs, dates, disagreements, unresolved items
+   - route-map.md - intent, canonical URL, status, schema, sitemap membership
+   - qa-checklist.md - checks that run against rendered HTML and live responses
+   - memory-receipt.md - durable save result or pending manual save
+B. Your memory: save the durable rules and research location through an authorized,
+   supported mechanism. Remember truthful schema, generated discovery files,
+   answer-first copy, and re-verification of dated search claims.
+   If memory is unavailable, write site-work/research/optimizer/memory-proposal.md
+   for Coordinator to consolidate into site-work/MEMORY.md for saving or reattachment. Never claim automatic persistence.
+
+APPLY
+- Test intended-public routes and deliberate exclusions against the route map.
+- Use Person, Organization, and ProfilePage only where the visible facts fit.
+- Add FAQPage only for actual visible questions and answers when appropriate.
+- Do not promise Google FAQ rich results; verify current Google support first.
+- Treat llms.txt as navigation assistance, not a proven ranking requirement.
+- Do not add AI-blocking metadata by default; respect an explicit owner policy.
+- Own site-work/optimization/route-map.json, metadata.json, structured-data.json,
+  answers.md, llms.txt, and sitemap.xml as the discovery inputs. Validate them.
+- Builder alone integrates these inputs into implementation paths and generates the
+  deployable HTML, sitemap, and llms.txt. Request changes through a handoff, never
+  edit Builder's source directly. Revalidate the actual rendered candidate afterward.
+- Save implementation evidence to site-work/qa/seo-aeo.md.
+
+When done, report the most surprising findings and ask for any missing owner-approved
+identity, audience questions, canonical domain, or content needed to make the graph true.
+
+EVIDENCE
+Never report a measured, saved, installed, or deployed result without evidence.
+Apply the stage route and named checks in manifest.json before handing off.

package/skills/website-build-skill/prompts/09-security-headers.md

@@ -0,0 +1,40 @@
+ASK DATE prerequisite: follow playbooks/research-and-memory.md#ask-date-rule.
+Researcher establishes it before intake or research; later roles read scope.md.
+Never ask the user for the date or infer it from model knowledge. Apply the
+same source, two-date, freshness, reuse, and blocked-gate rules to this stage.
+
+Configure security headers for the real host and built site, then verify their behavior.
+Read playbooks/security-headers.md and inspect the site's actual resource requests first.
+
+INVENTORY
+- Record scripts, styles, fonts, images, media, connections, frames, forms, and endpoints.
+- Explain each external origin and remove unused allowances.
+- Choose the starter matching the host and response type; static configuration does
+  not necessarily cover server-rendered or function responses.
+
+CONFIGURE
+- Enforce a tailored CSP with object-src 'none', base restrictions, and framing protection.
+- Prefer self-hosted fonts and click-to-play embeds to keep permissions narrow.
+- Handle legitimate inline content with exact hashes or an appropriate nonce design.
+- Never add unsafe-eval to production to silence an error.
+- Set nosniff, framing protection, Referrer-Policy, and a relevant Permissions-Policy.
+- Use two-year HSTS only after verifying HTTPS readiness; inspect all subdomains
+  before includeSubDomains, and never opt into preload as an incidental cleanup.
+- Avoid duplicate CSP headers that accidentally intersect into a broken policy.
+
+VERIFY
+- Inspect actual headers for normal pages, redirects, errors, static assets, and functions.
+- Exercise the main journey in a real browser with the enforced policy active.
+- Confirm fonts, images, payments, forms, and authorized embeds still work.
+- Run securityheaders.com and retain the dated grade; target A or A+.
+- A scanner grade cannot prove authorization, input validation, or application security.
+- If the scanner is unavailable, retain direct evidence and mark its grade UNVERIFIED.
+
+SAVE
+Write site-work/qa/security-headers.md with configuration, exceptions, observed responses,
+browser results, scanner result, and any unresolved release blockers.
+Hand the immutable candidate and this report to the independent auditor.
+
+EVIDENCE
+Never report a measured, saved, installed, or deployed result without evidence.
+Apply the stage route and named checks in manifest.json before handing off.

package/skills/website-build-skill/prompts/10-adversarial-pre-ship.md

@@ -0,0 +1,44 @@
+ASK DATE prerequisite: follow playbooks/research-and-memory.md#ask-date-rule.
+Researcher establishes it before intake or research; later roles read scope.md.
+Never ask the user for the date or infer it from model knowledge. Apply the
+same source, two-date, freshness, reuse, and blocked-gate rules to this stage.
+
+Run one independent adversarial audit of this fixed release candidate.
+The reviewer must be a different model family from the builder.
+If that is unavailable, prepare the review packet and mark independence incomplete.
+
+PREPARE THE AUDIT_BRIEF
+- Identify runtime, exact revision or artifact digest, routes, callers, and trust boundaries.
+- State threat model, authorized review scope, and what tests already passed.
+- Explain design decisions and why they were made so the reasoning can be challenged.
+- Include how to reproduce the build and which output is proposed for release.
+- Exclude secrets and unrelated private content from the review packet.
+
+REVIEWER INSTRUCTIONS
+- Work read-only against the named source/artifact. Do not fix implementation files.
+- Challenge untrusted input handling, script-bound JSON, attributes, URL schemes,
+  empty IDs, state/date edges, resource permissions, public endpoints, and exposed secrets.
+- Look for mismatches between source assumptions and generated or live behavior.
+- Inspect relevant flows fully; a pattern match is a lead, not a confirmed vulnerability.
+- For each finding, give location, preconditions, reproducible steps or a test,
+  observed result, impact, and a narrowly described fix.
+- Distinguish reproduced defects, evidence-backed risks, and unverified hypotheses.
+- Return an explicit no-findings result if that is what the review supports.
+
+BUILDER DISPOSITION
+- Reproduce each finding before fixing or relaying it as fact.
+- Record confirmed, not reproduced, accepted limitation, or unresolved, with evidence.
+- For each confirmed fix, add a regression that fails before and passes after the fix.
+- Re-run affected checks against the final artifact.
+- Record ROUND 1 in the brief with finding, disposition, test, and final artifact identity.
+- Use the harness to verify the fixes; do not start an automatic second audit round.
+- Do not bury an unresolved material issue inside a claim that the review passed.
+
+FINISH
+Return the reviewed identity, reviewer family, findings, dispositions, regression results,
+remaining limits, and whether the concrete release candidate meets the agreed gates.
+This audit is evidence, not a guarantee that no other defects exist.
+
+EVIDENCE
+Never report a measured, saved, installed, or deployed result without evidence.
+Apply the stage route and named checks in manifest.json before handing off.

package/skills/website-build-skill/prompts/11-ship-and-verify.md

@@ -0,0 +1,44 @@
+ASK DATE prerequisite: follow playbooks/research-and-memory.md#ask-date-rule.
+Researcher establishes it before intake or research; later roles read scope.md.
+Never ask the user for the date or infer it from model knowledge. Apply the
+same source, two-date, freshness, reuse, and blocked-gate rules to this stage.
+
+Ship the checked website only within the release authorization already on record.
+Read the brief, selected design, gate receipts, and ROUND 1 audit dispositions first.
+
+PREPARE
+- Identify the exact artifact to release and its reviewed predecessor if fixes changed it.
+- Verify the post-fix harness passed and no unexplained files changed afterward.
+- Exclude research, private brand material, secrets, and unrelated files from deployment.
+- Name the target account, project, domain, rollback artifact, and release operator.
+- If authorization is missing, finish the reviewable candidate and ask at this boundary.
+
+PROMOTE
+- Use the documented host procedure for the selected stack.
+- Do not silently create accounts, incur charges, alter unrelated domains, or rotate keys.
+- Record the deployment identifier, timestamp, public URLs, and artifact identity.
+
+VERIFY LIVE
+- Test HTTPS, redirects, intended routes, error paths, assets, and the primary journey.
+- Inspect actual security headers, metadata, canonical URLs, sitemap, and llms.txt.
+- Check mobile/desktop rendering and functionality with the production CSP enforced.
+- Record direct social-bot response checks separately from external preview cache results.
+- Mark missing field performance or third-party analytics evidence UNVERIFIED.
+- If a critical check fails, use the documented rollback and record the outcome.
+
+ONE OPERATIONS DOCUMENT
+Write SITE_OPERATIONS.md with these sections in order:
+what and why; trigger; invocation chain; dependencies; reads; writes; the closed loop;
+failure modes; run-and-verify by hand; source of truth.
+Name what watches the site, including "nothing", and who should receive a failure report.
+Include content editing, clean build, release verification, rollback, and credential
+locations by mechanism only, never secret values. Mark untested procedures UNVERIFIED.
+
+FINISH
+Give me the live URL, release identity, checks that passed, unresolved limits,
+operations-document location, and the next measurement owner if field data is pending.
+Do not call a deploy command's success a verified working website.
+
+EVIDENCE
+Never report a measured, saved, installed, or deployed result without evidence.
+Apply the stage route and named checks in manifest.json before handing off.

package/skills/website-build-skill/prompts/12-web-design-team.md

@@ -0,0 +1,141 @@
+ASK DATE prerequisite: follow playbooks/research-and-memory.md#ask-date-rule.
+Researcher establishes it before intake or research; later roles read scope.md.
+Never ask the user for the date or infer it from model knowledge. Apply the
+same source, two-date, freshness, reuse, and blocked-gate rules to this stage.
+
+Run option 2, Give me the team, using the human's recorded install choice.
+Needs Claude Code, Codex, Hermes, Antigravity, or Grok Bot. Follow the setup line for that host.
+
+Every agent runs its own research pass before it touches your site, so it works from what is
+true as of the date of your ask, not from what its model happens to remember.
+
+Researcher does the full sweep first. Every other role learns the saved library,
+then tops up only its own domain. Research, then learn, then ingest, then execute.
+
+SET UP
+- Read roles/researcher.md first, then roles/coordinator.md, roles/designer.md,
+  roles/graphics.md, roles/builder.md, roles/optimizer.md, roles/reviewer.md,
+  and templates/handoff.yaml. Use each complete body, not these short summaries.
+- Create or identify Website Researcher first, then Website Coordinator,
+  Website Designer, Website Graphics, Website Builder, Website Optimizer, and
+  Website Reviewer as separate sessions, Bots, or terminals. Parent may coordinate
+  only after the research gate. Use supported setup mechanisms, not invented imports.
+- Installer or human checks routes and obtains seven setup acknowledgements.
+  These confirm receipt of instructions, not permission to start downstream work.
+- A role label in one conversation is option 1. Record SOLO and use prompts/00-start.md
+  if separate workers cannot be reached. A same-family team remains a team but
+  cannot pass independent review. Respect host concurrency limits.
+- Antigravity setup uses generated agent definitions and per-role tool declarations;
+  Hermes setup uses the verified definition branch or generated session packets and
+  bundle alias. Read the host adapter and receipt; pending discovery, trust, tools,
+  or independent review checks cannot be reported as a ready team.
+- Supply the request, authorized workspace, source assets, and tools to Researcher.
+  All other roles wait. Use the manual fallback in the team bundle if setup cannot
+  be automated; actual package integration remains UNVERIFIED until tested.
+
+RESEARCHER
+- Own site-work/research/library/ and handoffs/researcher/; own both research resources.
+- Run prompts/01-website-deep-research.md, with the inactive graphics original as
+  provenance. Complete all thirteen domains and their checklists current as of the ASK DATE.
+- Save the library before any other role works. Gate: the library exists on disk,
+  every domain this project touches has a substantive file and checklist, and every
+  acted-on claim has an opened source URL, a publication/update date or explicit unknown, and an access date on or after the ASK DATE. UNVERIFIED cannot pass a claim.
+- Include README headlines, source/disagreement ledgers, user surprises, memory
+  proposal/receipt, and earliest staleness/recheck markers. Proposal is not saved memory.
+- Hand research-to-coordinator over only after the gate passes. Accept corrections
+  from specialists, update canonical evidence, and invalidate affected old receipts.
+
+COORDINATOR
+- Start after Researcher's passing receipt; read the files and verify that gate.
+- Learn the named library files and top up current host/worker capability questions.
+- Own brief, capabilities, stage state, ownership, gate acceptance, and integration.
+- Record routes, family evidence, tools, and ownership after research acceptance.
+- Assign bounded handoffs and open every returned artifact before accepting a gate.
+- Capture Reviewer's packet verbatim. Scope changes return to Researcher first.
+
+DESIGNER
+- After research, learn the library's design/UX, graphics/rights and accessibility
+  files and checklists; top up only this brief's current design/browser questions.
+- Own brand extraction, tokens, contrast, three mockups, and selection record.
+- Obtain user confirmation of inferred rules and a named design before site code.
+
+GRAPHICS
+- After research, learn graphics/rights and experience/performance files; top up
+  chosen-tool/tier rights, current destination sizes, safe zones, and asset licenses.
+- Work with Designer; own assets, cards, icons, inspected exports and rights evidence.
+- Deliver immutable revisions with measured dimensions and verified intended-use rights.
+
+BUILDER
+- After mockup selection, learn codebase/stack, accessibility/performance and
+  security/delivery research; top up chosen APIs, headers, and measurement rules.
+- Own stack choice, implementation, performance, headers, build evidence and release.
+- Integrate Graphics and Optimizer outputs without editing their original sources.
+- Prepare the immutable candidate/audit brief; reproduce findings and test fixes.
+
+OPTIMIZER
+- With and after Builder, learn search/answers and measurement research; top up
+  current schema support, crawler/citation behavior, llms.txt and indexing APIs.
+- Own SEO/AEO inputs, schema, sitemap, llms.txt, answer-first content and validation.
+- Hand discovery inputs to Builder, then validate the rendered candidate.
+- Claim neither indexing, received analytics nor schema validity without evidence.
+
+REVIEWER
+- Last before ship, use a different model family or return INTERNAL, gate BLOCKED.
+- Learn the relevant library and top up current attack, accessibility and scanner facts.
+- Review the fixed candidate read-only; return findings and research without edits.
+- Return reproducible evidence or an explicit scoped no-findings result.
+- Apply checklists/ship.md ASK DATE checks to library and top-ups; reject undated,
+  stale-access and stamped-but-unrevalidated claims as findings.
+
+EVERY HANDOFF
+Include stage, status, input_revision, artifact_revision, producer_role,
+producer_model_family, artifacts, checks, limitations, next_owner,
+changed_assumptions, and framing_reset. Use explicit empty lists where appropriate.
+Attach actual files or complete contents; an inaccessible path is not a handoff.
+Each writer saves site-work/handoffs/<role>/<stage>-<revision>.yaml. Reviewer returns
+its receipt for Coordinator to capture at site-work/review/<revision>/handoff.yaml.
+Every downstream role reads its WHAT YOU MUST LEARN library filenames first and
+saves a learning/checklist receipt before execution. Its WHAT YOU MUST RESEARCH
+is a domain top-up; flag stale/wrong claims back to Researcher and pause affected work.
+Coordinator alone accepts gates in site-work/status.md; authors keep their receipts.
+Changed inputs invalidate affected evidence. Failed gates stop dependent work.
+If group messages cannot carry images, attach directly to each receiving worker.
+Complete one independent review round; verify reproduced fixes through the harness.
+Use playbooks/research-and-memory.md's degradation table for missing capabilities.
+In SOLO do the Researcher's complete job first, save and reopen the library before
+any design, and leave research BLOCKED if current search or disk persistence fails.
+Finish each stage with its next concrete action and accountable owner.
+
+EVIDENCE
+Never report a measured, saved, installed, or deployed result without evidence.
+Apply checklists/research.md before downstream dispatch and checklists/ship.md before release.
+
+PORTABLE MANUAL SETUP
+Use this fallback when native adapters or generated bundles are not supplied.
+Native loading, automatic worker creation, routing, tool enforcement and different-family
+availability are UNVERIFIED until the actual host/session checks succeed.
+A missing host adapter does not authorize inventing a native file format or import API.
+
+1. Open the host's verified worker/session creation surface, if available.
+2. Create Researcher first, then Coordinator, Designer, Graphics, Builder, Optimizer,
+   and Reviewer. Paste each full roles/<role>.md body, not this prompt's summary.
+3. Supply SKILL.md, manifest.json and every linked resource as readable files or full
+   labeled text. Give Researcher the inactive graphics archive for provenance only.
+4. Get each worker's setup acknowledgement: received role, actual route, model family
+   with evidence, tools, inaccessible files, and owned paths. Keep downstream work pending.
+5. Give Reviewer a read-only candidate packet or verified read-only session. Broad
+   inherited tools do not become restricted because role prose says read-only.
+6. Verify a bounded setup message reaches each intended route through supported controls.
+   When group automation is absent, the human can relay addressed packets and attachments.
+7. Give the user's actual request, authorized workspace, assets and constraints to
+   Researcher alone. It establishes ASK DATE and completes the library and gate first.
+8. Relay its complete passing receipt and readable library to Coordinator. Coordinator
+   reopens them before accepting research and releasing design/graphics assignments.
+
+Preserve seven acknowledgements separately from research and work-readiness receipts.
+A text-only group requires direct image attachments to each receiving visual reviewer.
+Inaccessible files or routes keep the relevant handoff BLOCKED.
+No automatic creation support means a manual setup limit, not a claimed ready team.
+No separate workers means SOLO; no independent family means independent review BLOCKED.
+Never invent a platform capability to fill a setup gap.
+

package/skills/website-build-skill/references/stacks/framework.md

@@ -0,0 +1,76 @@
+# Framework recipe
+
+Date rule: [ASK DATE and source evidence](../../playbooks/research-and-memory.md#ask-date-rule).
+Use this recipe only after accepted research and a named visual mockup selection.
+Example commands and host/runtime support are UNVERIFIED until executed or sourced
+for the chosen project. Save actual results; never claim this recipe was deployed.
+
+Use when named application requirements earn a server/client framework.
+
+## Justify the runtime
+
+Compare a small endpoint with a full application for each server requirement.
+Name authentication state, server secrets, request-time behavior, integration needs,
+content authoring, deployment runtime, and maintenance owner.
+Select supported versions from current official documentation and actual source inspection.
+MDX or payments may support this decision but do not mandate a particular framework.
+
+## Map responsibilities
+
+```text
+routes/                   Framework-native route files after version verification.
+server/                   Authorized secrets, validation, integrations, access checks.
+components/               Shared presentation and bounded client interactions.
+content/                  Validated authored data and owner-approved entity facts.
+public/                   Approved images, local fonts, discovery/static assets.
+test/                     Server boundaries, rendering, state and primary journeys.
+framework configuration   Verified runtime, output, routing and security behavior.
+dependency lock           Reproducible chosen toolchain.
+SITE_OPERATIONS.md        One complete run/release/verify/recovery document.
+```
+
+These are responsibility names, not invented vendor directory requirements.
+Use the actual framework's versioned directory and API contracts.
+Keep server secrets out of public environment variables, serialized props, and client bundles.
+Authorize each private action on the server; hiding a button is not access control.
+
+## Establish the command contract
+
+Record exact dependency installation, development, type-check, test, production build,
+production preview/start, deploy and rollback commands for the chosen host/version.
+Do not paste generic commands as successful runs.
+Require a clean production build and the same output/runtime class used for release.
+Record environment variable names, purpose, scope, and injection mechanism without values.
+Verify build-time versus request-time behavior, caching, route fallback and error handling.
+
+## Render safely and usefully
+
+Keep useful initial HTML and truthful per-route metadata.
+Validate data, URL schemes and required identifiers before rendering controls.
+Use safe script-bound JSON serialization even if the framework escapes normal text.
+Test server/client state parity and boundary dates with an explicit timezone policy.
+Keep client work small; add it for actual interaction rather than all page content.
+
+## Verify the application surface
+
+- Access: test unauthenticated and wrong-authority requests on each protected action.
+- Inputs: test malformed bodies, rejected URLs, uploads and third-party responses where applicable.
+- Rendering: run build B04/B05 and discovery parity against actual production output.
+- CSP: inspect emitted inline content and test an exact hash or per-response nonce design.
+- Responses: check normal, redirect, error, asset and dynamic/function headers separately.
+- Journey: complete mobile/desktop, keyboard, failure/retry and reduced-motion paths.
+- Release: freeze a candidate, obtain different-family read-only review, reproduce findings,
+  verify fixes, then promote the checked artifact within existing authorization.
+
+## Limits and exit
+
+More runtime means more dependency, patching, secret, and operational responsibility.
+Record the upgrade cadence, watchers, failure recipient, and tested recovery commands.
+Keep content portable and isolate external integrations behind narrow interfaces.
+A supported framework name does not prove that a selected host tier runs its features.
+
+## Research starting points
+
+Open the chosen framework's current routing, rendering, security, environment, and CSP docs.
+Open the target host's current runtime/plan constraints and deployment/recovery docs.
+Compare a real application repository at an inspected revision, with its license recorded.

package/skills/website-build-skill/references/stacks/scripted-static.md

@@ -0,0 +1,76 @@
+# Scripted static recipe
+
+Date rule: [ASK DATE and source evidence](../../playbooks/research-and-memory.md#ask-date-rule).
+Use this recipe only after accepted research and a named visual mockup selection.
+Example commands and host/runtime support are UNVERIFIED until executed or sourced
+for the chosen project. Save actual results; never claim this recipe was deployed.
+
+Use when many pages share structure and must derive metadata from the same records.
+
+## File responsibilities
+
+```text
+src/data/                 Authored records and route registry.
+src/render/               Shared escaping, URL, JSON and state helpers.
+templates/                Page and component rendering.
+scripts/build.ts          Validate, render, derive discovery, report omissions.
+scripts/images.ts         Deterministic authorized image transformations.
+public/                   Approved static files copied to output.
+test/                     Data boundaries, rendered adverse cases, route parity.
+dist/                     Generated deployable output, never hand edited.
+package.json              Exact project scripts and declared dependencies.
+package-lock.json         Reproducible dependency resolution when npm is selected.
+SITE_OPERATIONS.md        Content, build, release, verify and recovery in one file.
+```
+
+Builder owns implementation and generated output.
+Graphics supplies versioned assets; Optimizer supplies versioned discovery inputs.
+Do not let integrations overwrite their authored sources.
+
+## Define the command contract
+
+```text
+npm ci             Install the project's reviewed locked dependencies.
+npm run build      Validate -> images -> render -> discovery -> inspect/report.
+npm test           Run meaningful boundary and generated-output checks.
+npm run preview    Serve the built output for local browser verification.
+```
+
+These commands are a proposed project contract, not scripts supplied by this skill.
+Builder must implement and verify the scripts and document the actual TypeScript runtime.
+Use the chosen runtime's supported compilation/execution path after a current-source check.
+Vite is optional when bundling or development behavior serves a named requirement.
+Sharp is a build dependency when the image transformation pipeline needs it.
+Do not introduce a client framework merely to map records to HTML.
+
+## Build deterministically
+
+Validate required fields, route uniqueness, URLs, dates, and relations before rendering.
+Compute publication state once with an explicit clock/timezone and named rebuild trigger.
+Generate HTML, metadata, social inputs, schema, sitemap, and llms.txt from validated records.
+Omit absent optional provider controls and report the omission.
+Sort output and use stable content/transformation asset identities.
+Exclude site-work, originals not intended for publication, credentials, and scratch files.
+
+## Prove the next-item workflow
+
+Add one invented valid record in a disposable copy, run the clean command chain,
+and inspect the new route and every derived surface.
+Confirm no template or separate metadata list needed manual edits.
+Remove the demonstration record before the real release and rebuild its exact candidate.
+Keep adverse cases for quotes, script terminators, unsafe schemes, empty IDs,
+duplicate slugs, missing assets, long copy, and publication boundaries.
+Apply checklists/build.md and the remaining QA/security/ship gates.
+
+## Limits and exit
+
+A generated page changes only when rebuilt and promoted.
+A browser interaction cannot keep a private server credential.
+Move to a justified endpoint or framework when request-time/authenticated state needs it.
+Keep records and pure rendering helpers separable so the content is portable.
+
+## Research starting points
+
+Read current runtime, template library, sharp, optional bundler, and selected host docs.
+Inspect actual build/helper/test files in reference repositories at recorded revisions.
+Use playbooks/data-and-templates.md and image-pipeline.md for acceptance contracts.

package/skills/website-build-skill/references/stacks/static-html.md

@@ -0,0 +1,72 @@
+# Static HTML recipe
+
+Date rule: [ASK DATE and source evidence](../../playbooks/research-and-memory.md#ask-date-rule).
+Use this recipe only after accepted research and a named visual mockup selection.
+Example commands and host/runtime support are UNVERIFIED until executed or sourced
+for the chosen project. Save actual results; never claim this recipe was deployed.
+
+Use for a small information site without repeated publishing or application state.
+
+## File responsibilities
+
+```text
+site/
+  index.html              Main audience/action page.
+  visit/index.html        Deliberate second route when the brief needs it.
+  assets/styles.css       Approved tokens, layout, states, responsive rules.
+  assets/site.js          Optional interaction only.
+  assets/images/          Approved measured exports with required notices.
+  assets/fonts/           Licensed woff2 and license notices if used.
+  robots.txt              Owner-approved crawl policy.
+  sitemap.xml             Intended canonical public routes.
+  llms.txt                Truthful navigation map.
+  404.html                Useful error and recovery page.
+  SITE_OPERATIONS.md      Complete operational handoff, excluded from upload if private.
+```
+
+Choose the selected host's static header configuration separately.
+Keep source and output identical only while this remains a genuine no-build site.
+Deployment uses an explicit file allowlist, not every file in the workspace.
+
+## Preview and check
+
+From the approved site directory, a local preview example is:
+
+```sh
+python3 -m http.server 8000 --bind 127.0.0.1
+```
+
+Open the local root and every intended route in a browser.
+This preview does not prove production redirects, custom error handling, HTTPS, or headers.
+Inspect those separately on the authorized host preview and final release.
+There is no package installation or build command required by this recipe.
+Record any added tool as a project-specific dependency with a reason.
+
+## Verify the contract
+
+- Build: run checklists/build.md against source and browser DOM, including missing optional IDs.
+- Accessibility: complete keyboard/error journeys and computed contrast checks.
+- Performance: retain the declared cold mobile series and all reports.
+- Discovery: inspect initial HTML, canonicals, internal links, route map and metadata parity.
+- Security: inspect actual host headers, enforced-policy behavior, and scanner evidence.
+- Release: apply checklists/ship.md to the exact uploaded files and independent review.
+
+## Add the next page
+
+A unique second page can be authored directly with the same approved styles.
+When repeated structure or metadata requires recurring copy/edit work, revisit the
+scripted-static recipe before duplicating a growing set of pages.
+Record how shared navigation and discovery files remain consistent in the interim.
+
+## Limits and exit
+
+Browser JavaScript cannot safely store server secrets or enforce private authorization.
+Use a separately justified endpoint or reconsider the framework branch for server state.
+Scheduled changes require a real editing/release trigger; static files do not self-update.
+Move validated content into records before repetition creates divergent page state.
+
+## Research starting points
+
+Read the selected host's static routing/headers documentation and the current HTML standard.
+Inspect a real no-build repository at an identified revision and check its license.
+Use playbooks/choose-stack.md for the recorded decision and rejected alternatives.