\r \r

Role\r

\r This skill owns theme-level template work, source-template editing, layout-aware styling, and view-layer conventions in WelineFramework. It ensures theme changes are made in source templates, follow theme structure, and remain compatible with the framework compiler.\r \r

When To Use\r

\r

• Use for theme directories, template overrides, layout files, source-template fixes, and theme CSS or JS organization.\r
• Use for keywords such as theme, template, phtml, layout, partial, override, view/theme, and view/tpl.\r
• Use when the work changes how a page or theme renders rather than how a backend rule behaves.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/theme-development/SKILL.md\r
• dev/ai/skills/template-source-editing/SKILL.md\r
• dev/ai/skills/code-generation-standards/SKILL.md\r \r

Responsibilities\r

\r

• Edit source templates instead of compiled template outputs.\r
• Keep frontend and backend theme areas separated.\r
• Organize layout, partial, widget, and asset changes in the expected theme structure.\r
• Keep styles and scripts scoped, reusable, and consistent with theme tokens.\r \r

Workflow\r

\r

1. Read AI-ENTRY.md, then theme-related docs, then inspect the owning source template path.\r
2. If the symptom appears in view/tpl, trace it back to the real source template before editing.\r
3. Implement the minimal source-template or theme-asset change in the owning theme area.\r
4. Keep layout-specific CSS or JS with the owning template instead of moving everything into global theme assets.\r
5. Use static template tags where possible and keep PHP in templates to the minimum necessary.\r
6. Validate through the rendered page or the closest route-level check.\r
7. Record affected template paths and any required theme documentation updates.\r \r

Weline Rules\r

\r

• Prefer diagrams and module docs before reading source code.\r
• Do not edit compiled view/tpl outputs directly.\r
• Do not add declare(strict_types=1) inside .phtml.\r
• Do not hardcode user-facing text.\r
• Use i18n for user-facing text.\r
• Do not use JavaScript alert, confirm, or prompt.\r \r

Inputs Required\r

\r

• The rendered page, theme, and source template path.\r
• Whether the task affects frontend or backend theme area.\r
• Expected visual or structural outcome.\r
• Validation route or page path.\r \r

Expected Output\r

\r

• A source-template or theme-level change in the correct directory.\r
• Scoped asset updates that match theme structure.\r
• Validation evidence from the real rendered surface.\r \r

Validation\r

\r

• Confirm the edit was applied to source templates, not view/tpl output.\r
• Confirm the page renders correctly on the intended route.\r
• Confirm styles and scripts stay scoped to the relevant theme surface.\r
• Confirm user-facing text remains externalized for translation.\r \r

Constraints\r

\r

• Do not maintain compiled template outputs by hand.\r
• Do not mix frontend and backend theme concerns in one asset path.\r
• Do not place layout-specific styling into unrelated global assets without need.\r
• Do not introduce broad visual side effects when a local template fix is sufficient.\r \r