$ ~/registry/skill/facebook-claude-skills-openzl-codec-design

SKILL

openzl-codec-design

Name: openzl-codec-design
Author: facebook

Design, modify, and review OpenZL codecs with consistent patterns and requirements.

Source

GitHub

Updated

2026-06-17

// securityCaution

Prompt only, no code
Open source

Summary

This skill appears to be prompt-only, open-source, and declares no keys or remote endpoints, so the overall risk is low. Its content mainly provides workflow and security guidance for OpenZL codec design, with no concrete red flags indicating data exfiltration, execution privileges, or excessive access.

CredentialsLow risk

The material declares no required keys or environment variables, and shows no path for token collection, storage, or misuse. As a prompt-only skill, credential exposure is minimal.

Network egressLow risk

No remote endpoints are declared, and the content does not describe sending user data to external services or making network calls. No network egress is indicated.

Code executionLow risk

This is a design/review-oriented skill description and does not describe spawning local processes, executing scripts, installing dependencies, or invoking system commands. The phrase 'USE AUTOMATICALLY' is workflow guidance, not execution capability by itself.

Data accessLow risk

The material only references project file paths such as `spec.md`, `src/openzl/codecs/`, and `fbcode/...` for repository work, and does not declare access to arbitrary local sensitive data, system resources, or excessive cross-directory access.

Supply chainCaution

The source is an open-source GitHub repository, and the code is auditable, which clearly lowers risk. However, the license is undeclared, community adoption is 0 stars, and maintenance status is unknown, so supply-chain quality still warrants caution.

Recommendations

Before use, verify repository ownership, commit history, and recent maintenance to confirm it is the intended OpenZL-related source.
If using this skill for code generation or modification, confine it to a controlled repository scope and manually review generated codec code for security.
Also review the repository license and dependency list to avoid introducing poorly maintained or unclearly licensed components.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "openzl-codec-design" skill from askskill:
1. Download https://raw.githubusercontent.com/facebook/openzl/dev/.claude/skills/openzl-codec-design/SKILL.md
2. Save it as ~/.claude/skills/openzl-codec-design/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Design a new codec

Prompt

Based on the existing style in OpenZL `src/openzl/codecs/`, design a new binary message codec. Describe the interface structure, error handling, extensibility requirements, and coding patterns that should be followed.

Expected

A clear codec design spec with pattern constraints, interface recommendations, and implementation requirements.

Review codec changes

Prompt

Review these OpenZL codec changes and check whether they follow the design patterns in `src/openzl/codecs/`. Identify issues in interface consistency, error propagation, edge-case handling, and maintainability, then suggest fixes.

Expected

A code review checklist outlining issues, reasons, and actionable improvement suggestions.

Define codec requirements

Prompt

I am preparing to refactor an OpenZL codec module. Help me create a requirements list covering functional goals, compatibility requirements, performance considerations, test coverage points, and constraints for staying consistent with the existing `src/openzl/codecs/` architecture.

Expected

A requirements document for refactoring planning with clear goals, constraints, and validation criteria.

// docs

Creating or Modifying an OpenZL Codec

Workflow for Creating a New Codec

If the user provides an input to this skill, interpret it as an informal specification of the codec they want to create. Before writing any code:

Ask clarifying questions about the format. Resolve ambiguities around input/output types, element widths, codec header layout, edge cases, error conditions, and whether the codec is public or private.
Write spec.md first. ALWAYS generate the decoder wire format specification (spec.md) before any other file. Follow the conventions of existing specs in src/openzl/codecs/ (inputs, codec header, decoding algorithm, outputs).
Ask the user to verify the spec. Do NOT proceed with implementation until the user has reviewed and approved the spec.md. The spec is the contract — all code flows from it.

Security

Decoder MUST Be Safe to Malicious Inputs

The decoder processes untrusted data from compressed frames. All assumptions MUST be validated, especially:

Bounds on sizes, counts, and offsets read from the frame header
Element widths and stream types
Buffer sizes before writing

Never trust values from the compressed stream without verification. A malicious frame must not cause crashes, out-of-bounds access, or undefined behavior.

Encoder MUST Be Safe to Malicious Inputs

The encoder is processing data that the user provides. Unless explicitly stated otherwise all assumptions MUST be validated. Typcially, this is less of an issue on the encoder side, but any assumptions the encoder makes about the input data (e.g. it doesn't contain the value 0) must be validated, otherwise the data could be corrupted.

Requirements

General

Codecs must work on big & little endian machines, and must not depend on endian-ness.
Prefer to use helpers that already exist in src/openzl/shared/, rather than re-implementing them.
- Especially openzl/shared/mem.h, openzl/shared/bits.h, and openzl/shared/utils.h.
All code MUST be portable across platforms. E.g. both ARM and x86-64, 32- and 64-bit systems, and both little- and big-endian.

Bumping ZL_MAX_FORMAT_VERSION

When adding a new codec, or making a breaking change to a codec that requires bumping the format version, we need to make sure the development branch bumps the format version. If not adding a codec or making a format breaking change to a codec, then you can skip this section.

Determine the production max format version from the ZL_MAX_FORMAT_VERSION macro in fbcode/openzl/prod/include/openzl/zl_version.h, call it $prod_max_format_version. Determine the development max format version from the ZL_MAX_FORMAT_VERSION macro in fbcode/openzl/dev/include/openzl/zl_version.h, call it $dev_max_format_version. If $dev_max_format_version == $prod_max_format_version, then the development ZL_MAX_FORMAT_VERSION in fbcode/openzl/dev/include/openzl/zl_version.h must be bumped. This needs to be done before hooking up the encoder and decoder registry so that the new max format version is used during registration.

Format Versioning

Codecs MUST preserve forward and backward compatibility with all supported format versions from ZL_MIN_FORMAT_VERSION to ZL_MAX_FORMAT_VERSION. Codecs MAY change their format, with very careful consideration, but they MUST do it in way that preserves compatibility:

ZL_MAX_FORMAT_VERSION must be bumped in the dev branch (see above)
The spec.md file MUST be updated to reflect the variation based on the format version
The encoder MUST check the format version with ZL_Encoder_getCParam(eictx, ZL_CParam_formatVersion) and only emit the new format for the latest format version
The encoder MUST maintain the ability to emit the older format versions down to the minimum format version the codec supports
The decoder MUST check the format version with DI_getFrameFormatVersion(dictx) and correctly interpret the encoded data based on the format version

…

View full docs ↗