Plone Frontend Developer

Overview

Diagnose and fix Plone/Volto frontend issues in any EEA frontend, whether it is a full Volto project or a reusable add-on. EEA frontends come from more than one template generation, so their layout and commands differ. Discover the project first instead of assuming paths or targets.

For Cypress-specific work, use the volto-cypress-writer skill.

Discover the project first

Before editing, read:

• the project AGENTS.md for project-specific conventions and dev environment
• Makefile — run make help to see the real targets
• package.json — addons, resolutions, the volto dependency, test scripts
• volto.config.js — the registered add-ons
• mrs.developer.json — add-ons mounted in development mode

Use references/volto-project-layouts.md to map what you find to one of the known EEA generations (legacy add-on, Cookieplone add-on, Cookieplone project).

Core workflow

1. Clarify the symptom, the affected URL, and the expected behavior. Note the language/locale if the site is multilingual.
2. Locate the code path: src/, packages/<addon>/src/, or src/addons/<addon>/src/, depending on the generation.
3. Reproduce and isolate: make minimal changes, add short-lived logs if needed, and confirm the exact component/block responsible.
4. Implement the fix in the most appropriate layer (project or add-on). Favor design tokens and shared helpers over hard-coded values.
5. Verify with the smallest relevant check (unit test, lint, typecheck, or a targeted runtime check) and report what you ran.

Common tasks

• Add-on debugging: find the add-on in the project's add-on registry (volto.config.js, package.json addons, or mrs.developer.json), then trace the component to its package.
• Blocks/components: check both the edit and the view components; cover the edit-time behavior and the saved output.
• Theme/tokens: replace hard-coded values with design tokens and update shared theme/config entries to keep consistency. See the eea-design-system skill.
• i18n: define messages in the add-on/project, then run the project's i18n target (make i18n).
• Routing/multilingual links: check locale-aware routing and URL generation before hardcoding language paths.

Good practices

• Prefer readable, minimal diffs; avoid refactors unless they are required for the fix.
• Keep temporary logs out of the final patch.
• For new features, add or update Jest/Vitest coverage.
• For Cypress, follow volto-cypress-writer — UI-first, no API-seeded setup.
• Run the project's or add-on's lint/check target before declaring done.
• Restart the frontend server after adding new shadow customizations if the project requires it.

Repo context

Use references/volto-project-layouts.md for the known EEA layouts, commands, test runners, and Cypress specPattern differences.

Verification

Run the smallest relevant command from the project/add-on Makefile, for example make check, make lint, make test, or the add-on's own targets. Report the exact command and result.

EEA-Specific Overrides

EEA-wide frontend policy

Supported Volto versions

EEA frontends run Volto 17, 18, or 19 depending on the project. Do not assume a version: read it from the project (package.json, .nvmrc, or the template generation) and match the commands and test runner to it. New projects default to the latest Volto supported by the EEA Cookieplone templates.

Add-on registry

Reusable EEA frontend behavior lives in @eeacms/* add-ons. Prefer extending an existing add-on over copying code into a project. Register project-local add-ons through the project's add-on configuration (volto.config.js, package.json addons, or mrs.developer.json).

Release and CI

EEA frontend releases go through Jenkins and release-it from the develop branch. Do not create release tags or Docker images manually; the pipeline derives them from git tags. See the jenkins-pipeline skill for the CI contract.

Handoff to other EEA skills

• Cypress/E2E work → volto-cypress-writer
• Design tokens and visual language → eea-design-system
• Build and quality gates → jenkins-pipeline, code-quality, testing