# Add Fe Op

> Adds a new operation to OpenVINO Frontend pipelines with translator updates, registration, and tests.

- Skill: `openvinotoolkit/add-fe-op` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add openvinotoolkit/add-fe-op`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openvinotoolkit/add-fe-op/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: openvinotoolkit (https://skillmd.com/u/openvinotoolkit)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openvinotoolkit/add-fe-op

---


# Agent Skill: Add New Operation to OpenVINO Frontend

## Goal
Enable a new operation in an OpenVINO Frontend (FE) pipeline — translator creation, registration, conversion validation, and tests.

## Framework-Specific Workflows

Each frontend has its own detailed workflow. Read the one matching the target framework:

| Frontend | Skill file | What it covers |
|---|---|---|
| **PyTorch** | [pytorch.md](pytorch.md) | NodeContext API, `op_table.cpp` registration (TorchScript + FX/Export), `translate_1to1_match_*` wrappers, Python layer tests, Mark operations |
| **ONNX** | [onnx.md](onnx.md) | `ov::frontend::onnx::Node` API, `ONNX_OP` macro registration with `OPSET_SINCE`/`OPSET_RANGE`, `.prototxt` test models, C++ GTest cases, normalize-step transformations |

## Related Skills (investigation & debugging)

| Frontend | Skill file | When to use |
|---|---|---|
| ONNX | [conversion-issues/onnx.md](../conversion-issues/onnx.md) | Conversion failures, accuracy bugs, shape/type mismatches, opset version gaps |
| PyTorch | [conversion-issues/pytorch.md](../conversion-issues/pytorch.md) | Conversion failures, accuracy bugs, tracing mode issues, normalize-step failures |

## Notes

- Keep this skill instruction-only in markdown.

---

## Instruction Workflow (TensorFlow and generic fallback)

The following sections apply to frontends **not** covered by the framework-specific files above (e.g., TensorFlow), or as a general reference when no framework-specific skill is available.

### 1) Check current support state
- Verify whether translator file already exists.
- Verify whether op is already registered in frontend mapping table.
- If both exist and conversion is known to pass, skip scaffolding.
- If only partial state exists, repair only missing parts.

### 2) Add translator logic
- Preferred path: emit real OV conversion logic when the operation maps to an OpenVINO op or a set of operations that will provide reasonable performance.
- If the same operation already exists in another frontend, extract/reuse common translation logic instead of duplicating it.
- For simple 1:1 ops, prefer existing helper translation patterns/utilities already used in FE codebase.
- Fallback path: emit safe placeholder translator only when real mapping is unavailable.
- Never claim full support when fallback translator is used.

### 3) Register operation in frontend tables
- PyTorch:
    - Add converter declaration in op table.
    - Add TorchScript key registration (for example `aten::op`).
    - Add FX key registration (for example `aten.op.default`).
- TensorFlow:
    - For supported unary ops, prefer generic unary registration path.
    - For unsupported cases, register dedicated translator function.
- ONNX:
    - Ensure `ONNX_OP` macro registration exists in translator file.

### 4) Add tests
- Add frontend smoke test file under `tests/frontend` (not available for PyTorch). 
- Add framework layer test under `tests/layer_tests` where supported.
- Ensure test naming follows existing suite conventions.

### 5) Build prerequisites for validation
- Ensure frontend changes are available to runtime before conversion checks.
- Build frontend targets from source or use an existing OpenVINO build/package that already includes your FE changes.
- If neither is true, do not report conversion status as passed; mark validation as blocked.

### 6) Validate conversion and finalize
- run conversion check from generated <frontend> model.
- if automated validation is unavailable, mark as skipped with explicit reason.
- Confirm no duplicate registrations are introduced.
- Confirm rerun is idempotent.
- Report one of three states: fully enabled, partially repaired, or scaffolded with fallback.

## Translation Recommendations

- Prefer runtime shape computation over conversion-time shape extraction.
    - Use `ShapeOf`-based graph logic for shape-dependent behavior.
    - Avoid relying on `get_shape()` / fully static shape reads during FE conversion.
    - `get_partial_shape()` is acceptable for compile-time rank-only decisions.

- Handle data types according to framework semantics.
    - If PyTorch op behavior allows mixed input types, preserve this in translation.
    - Do not over-constrain translators to a single dtype when mixed-type execution is valid.

- Avoid constants tied to compile-time element type queries.
    - Do not create `Constant` values from `get_element_type()` when type can be dynamic at conversion time.
    - Prefer runtime type-safe construction paths that remain valid for dynamic element types.

## Notes

- Keep this skill instruction-only in markdown.
- Prefer minimal, root-cause updates over broad refactors.
- Do not mark operation as supported unless FE conversion produces OV graph nodes (not framework fallback nodes).