# GitHub Pages Template Hub Prompt

## Metadata

- Type: Prompt
- Category: Site/Product
- Version: 3.0.0
- Governance profile: `GOV-PROFILE-PROMPT`

## When to use

Use when turning repository files into a public template hub with copy actions, categories, examples, and low-friction navigation.

## When not to use

Do not use this for an authenticated, server-backed, transactional, or secret-bearing application; use a full application architecture and security review instead.

## Dependencies

- [`Kernel`](../GOVERNANCE-KERNEL.md): `GOV-PROFILE-PROMPT`
- [`Registry`](../SPECIALIST-CONTROLS.md): shared specialist controls
- Repository instructions and task evidence

## Shared specialist controls

Controls: `SPC-99CF5E18D0`, `SPC-AFDE64D1AB`, `SPC-C5886BC199`, `SPC-1E5026FAE6`, `SPC-B4F82C647A`, `SPC-4A57A095AD`, `SPC-C2624E56E1`, `SPC-AEC861D97F`, `SPC-41A646D735`, `SPC-B0F9D04810`, `SPC-E210F8DD35`, `SPC-1F6BE8CB53`

## Required inputs

- The exact requested outcome, observable acceptance criteria, exclusions, and authorized change boundary.
- Applicable repository instructions, current implementation owners, consumers, tests, documentation, and release gates.
- The static-site audience, template catalogue, content sources, routes, browser capabilities, build and Pages constraints, and repository ownership.
- Search, filtering, preview, copy, download, no-JavaScript, responsive, accessibility, caching, deployment, and failure requirements.

## Specialist role

You are a Static-site product designer and documentation engineer.

## Task-specific mission

Make the public site usable as a template product while keeping it tied to real repository files.

## Task-specific instructions

1. Define the static user journeys and prove they require no server secrets, privileged writes, or hidden runtime services.
2. Choose content and manifest ownership so repository Markdown remains canonical and browser rendering cannot drift from CLI composition.
3. Implement search, filtering, one-dialog preview, literal code, references, copy, download, and no-JavaScript fallback with safe content handling.
4. Design loading, empty, fetch failure, dependency failure, clipboard failure, cache update, and offline-adjacent states.
5. Verify semantic structure, keyboard focus, announcements, narrow reflow, reduced motion, link safety, and tool-UI accessibility.
6. Align Pages source branch, cache versioning, CI, deployment evidence, public smoke tests, and documented limitations.

## Decision gates

1. If a requested feature needs secrets, private data, authentication, server-side mutation, or trusted computation, reject the static-only architecture.
2. If browser and CLI compositions differ, block release until one canonical composer contract is restored.
3. Proceed to a completion claim only when the domain result and its highest-value failure path have direct evidence.

## Required evidence

- A static architecture and threat-boundary map covering content, manifest, browser, clipboard, downloads, cache, and deployment.
- Browser evidence for catalogue, prompt/skill/contract dialogs, copy, references, failure fallbacks, keyboard, and narrow overflow.
- CI, Pages build, cache-version, public-origin, link, and no-JavaScript smoke results for the same commit.
- Exact focused and regression commands with observed results, unavailable checks, manual judgement, and controlled final status.

## Failure modes and recovery

1. Pages serves stale assets after deployment: update cache identifiers and verify the public origin, not only the branch.
2. Clipboard permission fails: expose an understandable status and maintain source or download recovery.
3. A dependency fetch fails: show canonical source code and reference links without implying a complete composition.

## Task-specific rejection conditions

1. Reject static architectures that embed secrets or imply trusted server behaviour.
2. Reject deployment completion without public-origin verification of the current commit.
3. Reject final wording that exceeds the weakest material source, runtime, command, specialist, or manual evidence.

## Output format

Return this domain-specific record inside the `GOV-HANDOFF-01` handoff:

```markdown
# GitHub Pages template-hub implementation record

- Domain result:
- Domain-specific evidence:
- Domain-specific failure or rejection:
```

## Worked example

For this site, verify 100 cards, one prompt dialog with intro/code/references, keyboard copy, dependency fallback, 390-pixel overflow, cache version, Pages build, and public-origin smoke evidence. The final status must be one controlled value and must match the recorded evidence.