---
name: create-full-template
description: Use when creating a new full website template or theme from a design brief, commit, branch diff, existing page, or HTML reference while preserving only required page-content DOM/classes and adding a commented plain-HTML playground.
---

# Create Full Template

Use this skill only for new full website templates or themes.

Read and follow `Prompt: Build a Full Website Template` as the canonical workflow. Ask the required questions before editing, unless the user has already answered them.

Core constraints:

- Default output is static HTML.
- Preserve page-content DOM/classes from the playground and CMS content references only.
- Treat the entire template shell as 100% unrestricted design space.
- Add simple comments before every dynamic/default replacement section.
- Use `Docs/skills/create-full-template/playground-html-ref.html` as the component reference, never as an include or iframe.
- Build the playground in plain HTML with all current component examples.
- Keep the full form first and the plain form second in the forms category.
- Keep approved empty placeholders empty.
- Use plain HTML or existing component methods; do not invent custom data-config systems.
- Do not include production content templates or database-backed renderers in the playground.
- Use `components-base.template.php` and `components-form-base.template.php` as page-content output references; do not change their required page-content classes/hierarchy without approval.

When the task supplies a commit, branch diff, page, or HTML, inspect that input first and limit repository analysis to the references needed by the prompt.

# Prompt: Build a Full Website Template

Create a new full website template for this project.

The default output technology is static HTML. Use another technology only when the user explicitly requests it. The template itself is 100% unrestricted. Only page-content blocks and component output structures must remain compatible with the existing playground and content references.

## Required Questions

Ask all unanswered questions in one message before editing:

| Area | Question |
|---|---|
| Identity | What is the template name and destination directory? |
| Inspiration | Is any existing theme or template useful as visual inspiration? This is optional and does not restrict the new template. |
| Scope | Which routes, pages, and states must be previewed? |
| Design | What visual direction, colors, typography, density, and layout should be used? |
| Branding | Which logos, icons, images, fonts, and existing assets are available? |
| Responsive | Which mobile widths, menu behavior, and sidebar behavior are required? |
| States | Must guest, logged-in, GM/admin, empty, error, and client-mode states be shown? |
| Dynamic areas | Which values are already loaded by the game/CMS and must receive replacement comments? |
| Components | Which component methods must be customized, and which should retain defaults? |
| Playground | Where should the plain-HTML playground screen live and should its filters be interactive? |
| Dependencies | Are new libraries or remote assets allowed? |
| Validation | Which browsers, viewport sizes, routes, and screenshots should be checked? |
| Input | Is the source a commit, branch diff, existing page, HTML, or a written design brief? |

Do not ask the user to choose the technology unless they request something other than HTML. Do not invent missing brand assets, routes, states, or dynamic data requirements.

## Required References

Read the smallest relevant references after the questions are answered:

- `Docs/knowledge/index.md`
- `Docs/knowledge/01-code-conventions.md`
- `Docs/knowledge/02-architecture.md`
- `Docs/api/template-components.md`
- `Docs/api/form-components.md`
- `src/core/templates/components-base.template.php`
- `src/core/templates/components-form-base.template.php`
- `Docs/knowledge/05-content-management.md`
- `Docs/skills/create-full-template/playground-html-ref.html`
- `src/pages/public/playground/playground.view.php`
- `src/pages/public/playground/playground.js`
- `src/core/modules/Content/Content.php`
- `src/core/modules/Content/templates/news-content.php`
- `src/core/modules/Content/templates/news-category-description.php`
- `src/core/modules/Content/templates/news-category-children.php`
- `src/core/modules/Content/templates/news-category-dropdown.php`
- `src/core/modules/Content/templates/news-category-cards.php`

Use `playground-html-ref.html` as the visual/component reference. It is a reference snapshot to copy from, not a file to import or include in the generated template.

Inspect an existing theme only when the user provides it as inspiration or the supplied source requires comparison. Never treat an existing theme's header, footer, CSS, JavaScript, classes, or DOM as mandatory for the new template.

Use these application references when their sections are included:

- `src/index.php`
- `src/pages/routes.php`
- `src/settings/helpers.php`
- `src/settings/config.example.php`
- `src/core/admin-bar/admin-bar.php`
- `src/assets/css/global.css`
- `src/assets/css/forms-and-grids.bootstrap.css`

## Workflow

1. Inspect the supplied commit, branch diff, page, HTML, or design brief first.
2. Identify the required page-content contracts from the playground and content references.
3. Map the default header, main, sidebar, footer, and state sections only as commented replacement locations.
4. Build the static HTML structure first.
5. Add any template styles and interactions freely; do not constrain the template chrome to an existing theme.
6. Add simple replacement comments for every dynamic or PHP-owned area.
7. Add the plain-HTML playground screen using the reference snapshot.
8. Validate required page-content classes, nesting, responsive behavior, and replacement comments.

Do not perform broad application analysis after the selected base and supplied input make the implementation path clear.

## Template Freedom

The complete template shell is free design. The new template may invent its own:

- HTML document structure
- Header, navigation, hero, sidebar, footer, and utility layout
- Classes, IDs, wrappers, grids, typography, colors, spacing, and visual language
- Responsive strategy and menu behavior
- Asset placement and decorative elements
- JavaScript interactions and component presentation

Do not copy or preserve an existing theme's outer DOM merely because it exists. Use existing themes only as optional visual or behavior references.

## Page Content Contract

The content rendered inside pages is the compatibility boundary. Preserve the current classes and hierarchy when reproducing these page-content cases. The template shell around them may be completely different.

### Playground Cards

The playground reference uses this hierarchy for every component case:

```text
.playground-components
  section.panel.panel-playground-component[data-playground-category][data-playground-component]
    .playground-component-header
      .playground-component-title
      .playground-component-description (optional)
    component output
```

Preserve the card classes, `data-playground-category`, `data-playground-component`, category/subcategory values, component order, and all current examples from `Docs/skills/create-full-template/playground-html-ref.html`.

### Template Components

When page content uses these methods, keep the output structure represented by the current playground/reference and the component base classes:

| Method | Main structure/classes |
|---|---|
| `StartPage` / `EndPage` | Page-content root; preserve the active reference output |
| `PageTitle` | Theme/component title output; preserve the reference output |
| `StartBlock` / `EndBlock` | Block/panel wrapper and `.panel-body` where present |
| `BlockTitle` / `SubTitle` | `.panel-title` heading output where present |
| `showAButton` | `.btn.btn-default` link |
| `showAccordion` | `.accordion > .accordion__box-title + .accordion__box-content` |
| `printFields` | `.row.fake-table > .fake-table__row > .row > .label + .value` |

The component internals may be restyled freely, but do not change the page-content contract used by the reference screen.

### Form Components

Keep these structures when the form component is represented in page content:

| Component | Main structure/classes |
|---|---|
| `startForm` / `endForm` | `.form-horizontal.needs-validation` form when non-plain |
| `showTextRaw` | `.form-group.row > .offset-4.col-sm-8` |
| `showAlert` | `.alert.alert-{level}` |
| Text/password/number inputs | `.form-group.row > label.col-sm-4.control-label + .col-sm-8 > input.form-control` |
| Textarea | `.form-group.row > label.col-sm-12.control-label + .col-sm-12 > textarea.form-control` |
| `showSelect` | `.form-group.dropdown.row > label.col-sm-4.control-label + .col-sm-8 > select.form-control` |
| `showButton` | `.form-group.row > .offset-4.col-sm-8 > button.btn.btn-primary` |
| `showRadioButton` | `.radio > label > input.form-check-input` |
| `showCheckbox` | Checkbox input structure from `showInputText` |
| `showRadioButtonList` | `.form-group.row > label.col-sm-4.control-label + .col-sm-8 > .radio` items |
| `showSecurityCode` | Form row with security input and CAPTCHA image |
| Plain controls | No component wrapper; preserve the direct control output and caller-provided wrapper |

Keep the full form first and the plain form second in the forms category. Every plain-capable control in the plain form must remain `$plain=true` in the eventual PHP replacement.

### CMS Content

Use the exact classes and hierarchy from the current Content templates. Do not reduce these to isolated title, image, breadcrumb, or description cards:

| Case | Required structure/classes |
|---|---|
| Category page | Title, `.content-breadcrumb`, `.panel.panel-content-category > .panel-body`, optional `.content-category-description`, `.content-node-image.content-category-image`, then `.content-category-news`, `.news-list.content-category-cards`, or `.faqs.content-category-dropdown` |
| News content child | `article.blog-item > .blog-content > .entry-header > h3 > a`, `.content-node-image`, `.blog-story.short-story` |
| Category cards child | `.news-list.content-category-cards > article.news-card > .news-date + h3 > a + p.text-muted` |
| Category description preview | `article.blog-item > .blog-content > .entry-header`, `.content-node-image`, `.blog-category.short-story > .content-category-description` |
| Category children preview | `.blog-category.short-story > .content-category-preview-list > .content-category-preview-item > a + time` |
| Category dropdown preview | `.blog-category.short-story > .faqs.content-category-dropdown > .accordion` items |
| Content node page | Title, `.content-breadcrumb`, `.panel.panel-content-article > .panel-body`, `.content-node-image.content-article-image`, `.content-article-body` |
| Breadcrumb | `.content-breadcrumb > .breadcrumb-title` and the current linked path hierarchy |

References:

- `Docs/knowledge/05-content-management.md`
- `src/core/modules/Content/Content.php`
- `src/core/modules/Content/templates/news-content.php`
- `src/core/modules/Content/templates/news-category-description.php`
- `src/core/modules/Content/templates/news-category-children.php`
- `src/core/modules/Content/templates/news-category-dropdown.php`
- `src/core/modules/Content/templates/news-category-cards.php`

### Common Page Markup

When reproducing existing page cases, preserve the relevant classes and nesting from the source page:

- Tables: `.table`, `.ranking-table`, `.myaccount-table.vertical-cell`, `.cart-table`, `.notifications-table`
- Profile layouts: `.row`, `.player-face`, `.player-face--big`, `.player-info.row.fake-table`, `.flex-center-align`
- Store layouts: `.box-style1`, `.product__category`, `.products`, and product classes emitted by the product component
- Cart layouts: `#cart-content`, `.cart-items`, `.cart-table`, `.cart-actions`, `#cart-confirmation-template`
- Generic page wrappers: `pageContent`, `panel`, `panel-body`, `panel-title`, rows, columns, and the existing page-specific block class

Use the actual source page and the playground reference to confirm hierarchy instead of guessing from the class name.

## Default Section Comments

Place a short HTML comment immediately before every section that will later receive PHP, CMS, game, session, or theme data. Comments must describe the replacement point without embedding full PHP code.

Use comments like:

```html
<!-- Dynamic: primary navigation items -->
<!-- Dynamic: online player count from the game -->
<!-- Dynamic: logged-in account actions -->
<!-- Dynamic: page content rendered by the selected route -->
<!-- Dynamic: server information block -->
<!-- Dynamic: footer statistics and rankings -->
```

Comment every relevant section, including:

- Primary menu and language options
- Guest, account, and GM/admin actions
- Online count and other game-loaded information
- Download and registration links
- Sidebar blocks and server information
- User/profile data
- Ranking, event, and social blocks
- CMS news/content areas
- Store, cart, payment, and pending-order areas
- Footer links, statistics, rankings, events, and scripts
- Every playground component example that will later map to a PHP helper

Keep comments simple. Do not paste full PHP implementations into static HTML.

## Components and Methods

The template shell is unrestricted. For page content, use the existing methods and the following files as the output reference:

- `src/core/templates/components-base.template.php`
- `src/core/templates/components-form-base.template.php`

Use their default HTML as a reference when useful. Keep the page-content classes and hierarchy documented above, even when the new template gives the components a completely different visual treatment. Do not modify those core files as part of template creation unless explicitly requested.

Prefer the existing component methods and wrappers for page, block, title, button, accordion, field, form, input, choice, alert, security, product, and cart areas. When static HTML is required, mirror the method output and add a replacement comment.

Do not create custom data configuration objects, fixture systems, or rendering abstractions unless the user explicitly approves them. Static examples use plain HTML or hardcoded values; integrated implementations use the existing component methods and application data contracts.

## Playground Screen

Create a plain-HTML playground screen containing all available component examples from the current playground reference.

Requirements:

- Copy the reference markup; do not include or iframe `playground-html-ref.html`.
- Keep every component card, category, subcategory, shared class, and data attribute needed for validation.
- Keep the category and component filter controls if interactive filtering is requested or already part of the target template.
- Keep `All` behavior and URL-backed filter state when the existing playground behavior is reused.
- Keep the full form example first in the forms category.
- Keep the plain form immediately after it; every plain-capable control uses `$plain=true` in the eventual PHP replacement.
- Keep content-management examples as complete category/node cases, not individual helper cards.
- Keep ranking generic, profile cases separate, and Store/full-cart as one combined case.
- Leave approved empty placeholders empty.
- Add comments before each example indicating the corresponding component/helper replacement point.
- Use plain HTML and hardcoded fixture values only; do not load CMS/game data.
- Do not include production templates or call database-backed renderers.

The playground reference is for user validation of the final visual design. Do not reduce it to a few representative components.

The current playground inventory is:

| Category | Subcategories |
|---|---|
| `template` | `PageTitle`, `BlockTitle`, `SubTitle`, `showAButton`, `showAccordion`, `printFields` |
| `forms` | `full-form`, `plain-form`, `startForm`, `startEmptyRow`, `showSeparator`, `showTextRaw`, `showText`, `showInputText`, `showInputTextArea`, `showInputPassword`, `showInputNumber`, `showSelect`, `showButton` |
| `choices` | `showRadioButton`, `showCheckbox`, `showRadioButtonList`, `showLanguageOptions` |
| `feedback` | `showAlert`, `showSuccessError`, `showSecurityCode`, `showCaptcha`, `showToken` |
| `commerce` | `getProductImageURL`, `getProductName`, `showProduct`, `showFloatingCartItem`, `store-cart` |
| `ranking` | `generic-ranking` |
| `profiles` | `user-details`, `guild-details`, `guild-members`, `player-icons` |
| `content` | `category-list`, `category-dropdown`, `category-description`, `category-children`, `category-preview-dropdown`, `content-node` |
| `markup` | `table`, `list`, `media` |

Keep empty approved placeholders empty. Do not create independent cards for paired end methods, full-page wrappers, or content helpers that already belong to a complete case.

## HTML Rules

- Output HTML by default.
- Keep semantic elements where the current structure uses them.
- Keep forms non-destructive in the static preview.
- Do not add real endpoints, database calls, payment actions, or authentication behavior.
- Do not add a framework or dependency unless approved.
- Use existing asset paths when available; use obvious placeholders when assets are not supplied.
- Keep accessible labels, button types, image alt text, focus states, and keyboard navigation.
- Make the layout usable at mobile, tablet, and desktop widths without changing required classes.
- Avoid embedding the entire generated default template in comments or documentation.

## Replacement Notes

At the end, report:

- Created template files and entry points
- Base theme and DOM contract preserved
- Dynamic sections marked with comments
- Playground screen location and reference coverage
- Components intentionally customized
- Components intentionally left at defaults
- Validation performed and any remaining manual checks