\r \r

Role\r

\r This skill builds frontend components and page assembly units such as blocks, taglibs, widgets, PageBuilder templates, and reusable page sections. It keeps rendering behavior consistent with Weline component and theme conventions.\r \r

When To Use\r

\r

• Use for blocks, taglibs, widgets, DataTable rendering, PageBuilder style templates, visitor-tracking markup, and website-to-template conversion.\r
• Use for keywords such as component, widget, taglib, PageBuilder, block, w:widget, w:d-table, website clone, and page section.\r
• Use when the task is to build or refactor reusable page pieces rather than only restyle existing templates.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/frontend-components/SKILL.md\r
• dev/ai/skills/pagebuilder-style-templates/SKILL.md\r
• dev/ai/skills/website-to-template/SKILL.md\r
• dev/ai/skills/visitor-pixel/SKILL.md\r
• dev/ai/skills/weline-sticker/SKILL.md\r \r

Responsibilities\r

\r

• Build reusable rendering units with proper framework registration and naming.\r
• Keep component CSS and JS self-contained and scoped.\r
• Follow PageBuilder structure for themes, components, colors, and layout assets.\r
• Integrate tracking or download interaction patterns without duplicating page-level behavior.\r \r

Workflow\r

\r

1. Identify whether the task is a block, taglib, widget, PageBuilder component, or page-conversion request.\r
2. Read the matching source skill material and confirm the expected directory layout.\r
3. Implement the component with the correct registration path, template path, and metadata.\r
4. Scope CSS and JS to the component root and prefer local project assets or inline extraction-friendly assets.\r
5. For PageBuilder, keep theme prefixes, component metadata, color schemes, and shared partials aligned.\r
6. For tracking-related UI, use the approved pixel-marking pattern instead of custom duplicate tracking code.\r
7. Validate on the rendered page, including interactions if the component is stateful.\r \r

Weline Rules\r

\r

• Do not use JavaScript alert, confirm, or prompt.\r
• Do not hardcode user-facing text.\r
• Use i18n for user-facing text.\r
• Do not add declare(strict_types=1) inside .phtml.\r
• Keep component CSS and JS scoped and avoid polluting global state.\r
• Prefer small, isolated, testable UI changes.\r \r

Inputs Required\r

\r

• The component type, owning module or theme, and target page region.\r
• Expected rendering, interaction, and configuration behavior.\r
• Any related PageBuilder or tracking constraints.\r
• Validation route or page.\r \r

Expected Output\r

\r

• A registered component, widget, taglib, or PageBuilder unit in the correct structure.\r
• Scoped styles and scripts that support the component safely.\r
• Validation evidence showing the rendered or interactive result.\r \r

Validation\r

\r

• Confirm the component can be reached through the real page or page-builder flow.\r
• Confirm JS and CSS are locally scoped and do not require forbidden browser dialogs.\r
• Confirm tracking markup or download hooks do not double-report events.\r
• Confirm component metadata and paths match the framework loader expectations.\r \r

Constraints\r

\r

• Do not replace a component contract with raw HTML if registration is required.\r
• Do not load third-party CDN assets casually for self-contained components.\r
• Do not duplicate page-level pixel dispatch logic inside business templates.\r
• Do not edit generated outputs instead of source component files.\r \r