Ucoz Template Creator Skill

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:

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
• Informer creation, placement, and varied layouts: references/INFORMERS.md
• Native rating generator and custom state sprite: references/RATING.md
• Visual directions and semantic SVG system: references/DESIGN-DIRECTIONS.md
• Reusable but stylistically varied patterns: references/EXAMPLES.md
• Custom Pages and SEO: 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. 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. 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:

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. 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.