Ucoz Template Creator Skill

---
name: ucoz-template-creator-skill
version: "1.0"
description: >
  Creates a complete original uCoz site template and carries one coherent design across
  the entire site: expressive composition, a responsive framework, templates for every
  active module, custom Pages, SEO, informers, native rating with a custom SVG sprite,
  and system pages with no leftover standard styling. Use when building a site template
  from scratch, performing a complete redesign, or generating, publishing, migrating,
  and auditing a framework through ucoz-mcp. Do not use for a small edit to one page
  template or an isolated CSS fragment.
author: uCoz
license: MIT
requires:
  - official ucoz-mcp for tmaker, templates, modules, and usage accounting
metadata:
  hermes:
    tags: [ucoz, mcp, templates, template-creator, tmaker, design, redesign, css, svg, informers, rating, seo, cms]
  compatible_agents: [Hermes, Claude Desktop, Cursor, Codex, OpenAI Agents, OpenWebUI, generic MCP clients]
  required_mcp_servers: [ucoz-mcp]
---

# uCoz Template Creator

Create an original, production-ready uCoz design as one framework plus one complete CSS table. Treat publication as a site-wide migration: it overwrites every generated template.

## Rule 0 — Usage accounting

After the skill's main work completes successfully, record usage:

```text
skills_tool(action="register_usage", skill_id="ucoz-template-creator-skill")
```

If the usage API is unavailable or returns an error, show a brief warning and continue the skill's main workflow. Do not ask the user for a UUID, token, or site URL — the site and token come from the active `ucoz-mcp` connection.

## Route the request first

- Full design, new framework, global structure, `new_informer`, framework `global_x`, `popup`, `config`, or PDA design → use this skill and `tmaker_tool`.
- Small change in one existing template → use `templates_tool.patch_template`; stop this workflow.
- Full replacement of one existing template → use `templates_tool.update_template`; stop this workflow.
- Small change in an existing CSS table → read `3/3`, then use `patch_template`; stop this workflow.

Never publish a framework as a shortcut for a local edit. Framework changes do not receive later `patch_template` edits back; the next framework publication erases them.

## Read before generating

Always call, in order:

1. `tmaker_tool(action="skeleton_guide")`.
2. `tmaker_tool(action="skeleton_rules")`.
3. `tmaker_tool(action="project_list")` and the relevant `project_get`, or `designs_list` and one `design_get`.

Treat the live guide, rules, and retrieved source as authoritative. Never invent service blocks or uCoz variables. Read these bundled references only as needed:

- Platform workflow, module contracts, template migration, and QA: [references/FRAMEWORK.md](references/FRAMEWORK.md)
- Informer creation, placement, and varied layouts: [references/INFORMERS.md](references/INFORMERS.md)
- Native rating generator and custom state sprite: [references/RATING.md](references/RATING.md)
- Visual directions and semantic SVG system: [references/DESIGN-DIRECTIONS.md](references/DESIGN-DIRECTIONS.md)
- Reusable but stylistically varied patterns: [references/EXAMPLES.md](references/EXAMPLES.md)
- Custom Pages and SEO: [references/CUSTOM-PAGES.md](references/CUSTOM-PAGES.md)

## Establish the design brief

Clarify only missing decisions that materially change the result:

- new design or evolution of the current saved project;
- required modules, sidebars, custom global blocks, informers, and rating;
- content character and desired visual direction;
- desktop (`pda=0`) or PDA (`pda=1`);
- whether existing brand assets must be preserved.

Select a direction from `DESIGN-DIRECTIONS.md`, then adapt it to the content. Do not default every site to dark gradients, glass cards, centered heroes, identical pills, or the same layout.

Before any write, explain that two resources will be replaced: the complete CSS table and all templates generated by the framework. Obtain explicit consent before `update_template(3/3)` or `skeleton_publish(confirm=true)`. A request to install, activate, test on the site, or show the design on the site counts as publication intent after these consequences are stated; a request to generate, preview, or review does not.

## Build the framework

1. Start from `project_get` or `design_get`; do not compose blind.
2. Preserve valid uCoz expressions, system-language markers, form IDs, and platform variables.
3. Include the structural blocks required by the live guide: `header`, `middle`, `footer`, `popup`, `config`, containers, and any selected module blocks.
4. Keep one visible `$POWERED_BY$` in the footer path.
5. Keep `[TITLE]` and `[BODY]` intact inside `popup`.
6. Declare custom global blocks with lowercase Latin names of 1–10 letters. Their declaration is their render position: nest the marked block at the intended conditional/component location and do not add a second explicit `$GLOBAL_NAME$` call.
7. Inventory every enabled content module before writing views. Add verified `*_entry_view` and `*_entry_page__body` blocks where the framework supports them. For a template without a framework block, style standard uCoz markup in the site-wide CSS and use narrowly scoped SVG masks on known metadata classes when an icon is required; do not publish a framework and leave enabled modules visually standard by accident.
8. Read the icon contract in `DESIGN-DIRECTIONS.md`, then use accessible inline SVG icons with `viewBox` and `currentColor`; reuse or adapt [assets/ui-icons.svg](assets/ui-icons.svg). Every custom material card and full material page must pair date, views, category, author, comments, downloads/redirects, duration, cart, or voting values with the matching semantic icon. Never use one generic icon for unrelated values, emoji, or a broken icon font.
9. Build a mobile off-canvas header. Keep fixed overlays outside ancestors using `transform`, `filter`, `backdrop-filter`, `perspective`, `contain`, or relevant `will-change`.
10. Put no CSS rules in the framework. Keep only `<link type="text/css" rel="stylesheet" href="/_st/my.css?v=1">`.
11. Build the document head from verified variables. Prefer `$SEO_TITLE$`, `$SEO_DESCRIPTION$`, and `$SEO_KEYWORDS$` only where `get_variables` and `skeleton_validate` confirm them; preserve `[TITLE]` as the framework fallback.
12. Design conditional rendering deliberately. Read the conditional-rendering rules in `FRAMEWORK.md`; cover both page/module-level layout branches and item/permission-level optional data. Preserve useful behavioral branches from the selected standard design instead of flattening every page into one unconditional shell.
13. Define one breadcrumb component for the design and reuse its exact structure, class contract, separator icon, typography, spacing, and responsive behavior in every archive, category, full material, Search, system, and custom Page template that renders breadcrumbs. Only the depth and verified labels/URLs may vary.

## Build and save the CSS

For a new site-wide design, generate the complete stylesheet as one coherent file with tokens, base rules, components, module/system markup, responsive rules, focus states, and reduced-motion behavior.

Before replacing CSS or publishing templates, call `templates_tool.create_backup`. Then publish the stylesheet with `templates_tool.update_template(module_id=3, template_id=3, content=<complete CSS>)`. This call replaces the entire existing CSS table; never send a fragment. Reading the old CSS is not required when the user approved a complete redesign. For later incremental style changes, switch to `read_template` plus `patch_template`.

Use `/_st/my.css?v=1` in the framework. uCoz rewrites the version for generated templates; manually increment it only in independent custom page templates.

## Add custom Pages in the same design

When the user asks for a personal, campaign, about, contact, portfolio, or other custom site page, read [references/CUSTOM-PAGES.md](references/CUSTOM-PAGES.md). Use `page_list` and `page_get`, then create or update only that page through the Pages API. Reuse the active framework shell, tokens, components, SVG vocabulary, and `/_st/my.css`; add page-scoped rules to `3/3` instead of starting a visually unrelated landing stylesheet. Set the page SEO fields. Do not republish the framework for a single custom page.

## Handle informers as a two-publication transaction

Read `INFORMERS.md` before adding an informer. Select a line, index, strip, related-reading, or product layout according to its location and module; do not clone the same card structure for every informer. Read `RATING.md` whenever the generated theme contains vote-capable material pages or custom rating sprites.

1. Add one or more `new_informer` blocks and validate.
2. Save a project, publish, and record every returned `created_informers` item: `title`, `id`, `created`, and `$MYINF_N$` code.
3. Remove every `new_informer` block from the framework.
4. Place the returned `$MYINF_N$` codes at their intended locations.
5. Validate, save a second project, and publish again.

Do not clean informer tails with template patches. `created=1` means created during that publication; `created=0` means an existing informer was reused.

## Validate before any publication

Run the bundled preflight first:

```text
python scripts/lint_skeleton.py <framework.html>
```

Then run `tmaker_tool(action="skeleton_validate", tmpl=<full framework>)`. Parse every item in `details[]`; do not stop at the first error. After a successful validation, run `project_save` as a source-level recovery point. A saved project is not visible on the live site. `project_save_active` only marks the final source project active; the design becomes visible only after `skeleton_publish` regenerates the site templates.

Before publishing, check backup capacity when practical. If the backup limit blocks a write, show the list and obtain permission before deleting a specific old backup.

Only after explicit approval call `skeleton_publish(confirm=true, pda=<0|1>, tmpl=<full framework>)`. The tool creates another automatic template backup. After the final successful pass, call `project_save_active` with the exact final source so the active project matches the live design. Do not stop at a non-active `project_save` when the user asked to install or show the design on the site.

## Migrate every active template after publication

Framework publication is not the end of a full redesign. Before the initial approval, explain that the migration includes targeted updates of active/system templates that tmaker leaves standard or stale. After every final framework publication:

1. Call `modules_list`, then `templates_tool.list_modules`; inventory every active module plus Pages, Users, Search, common system templates, globals, forms, comments, and shared partials.
2. Read every mapped template, not only the templates named in `affected_templates`. Always inspect Search `19/1` and `19/2`; current tmaker has no verified `search_entry_view` block.
3. Classify each template: current theme; standard inner markup that shared `3/3` CSS can safely style; or stale/structurally incompatible markup requiring a targeted template change.
4. For every stale template, call `get_variables`, preserve required platform placeholders and behavior, validate the candidate, then use `patch_template` for a narrow structural fragment or `update_template` for a complete one-template replacement. Use the same shell, CSS, SVG vocabulary, breadcrumbs, typography, spacing, and responsive rules as the theme.
5. Read every changed template back and verify UTF-8, current `/_st/my.css?v=...`, no old `/.s/t/<design-id>/` assets, no literal `CONTENT`/unknown variables, and exactly one visible `$POWERED_BY$` on full documents.
6. Browser-test representative URLs for every active family at desktop and mobile widths. A successful API response or CSS link alone does not complete the migration.

Do not republish the whole framework to repair one missed system template. Record targeted migration changes so the next theme publication can preserve or intentionally reapply them.

## QA the result

Use the QA section in [references/FRAMEWORK.md](references/FRAMEWORK.md). At minimum verify:

- live desktop and mobile pages for each enabled module;
- header, off-canvas menu, popup, archive/category, entry page, comments, forms, and footer;
- identical breadcrumb component and separator treatment across every breadcrumb-bearing module, Search, system template, and custom Page;
- SVG icon alignment and inherited colors;
- every enabled material type has the correct metadata/module icons in both list and full-page states, or a documented standard-markup fallback;
- full material pages render the verified interactive `<?$RSTARS$(...)?>` generator with exactly three sprite states and no duplicated rows; `$RATING$` is only the numeric value/availability condition and must not substitute for the generator;
- informer placement after the second publication;
- every important conditional branch with its value present/absent and, where relevant, logged-in/logged-out states;
- no literal unknown `$VARIABLE$`, no content overlap, no horizontal scrolling, and visible keyboard focus.

If publication was not explicitly approved, stop after local lint plus `skeleton_validate` and present the generated framework/CSS for review.

Finish only after the active-template migration above is complete or every remaining limitation is explicitly documented.

## Finish

Report the selected design direction, files produced, validation result, saved project ID, publication/PDA status, affected templates, informer codes, CSS replacement, backup status, and pages tested.

After successful completion, call `skills_tool(action="register_usage", skill_id="ucoz-template-creator-skill")` once. Usage accounting is secondary: do not retry or roll back work if it fails.