Bindry
Sign in
Back to home

Plug-in

OpenAI Codex

Compiles a bound Stack into Codex skills, so instructions load only when a task actually matches them — not on every single turn.

View source

Built and verified end-to-end

Tested against the real @openai/codex CLI: both install commands complete, codex plugin list reports it installed and enabled, and all three skills plus both scripts are present under the installed plugin's cache path. Pinned and live sync modes both work.

Why skills, not a context dump

Codex loads a skill only when it matches the task, the same as Claude Code — and Codex skills use the exact same SKILL.md frontmatter-plus-body format. So this plugin runs the same compiler as the Claude Code one, with only the manifest and output path changed (.agents/skills rather than .claude/skills), not the rendering logic. A CI check fails the build if the two copies ever drift apart.

How it works

  1. 1

    Install the plugin

    Run the two install commands below. Codex gets three new skills: $bindry-sync, $bindry-connect, and $bindry-check.

  2. 2

    Load a Stack with $bindry-sync

    Give it a Stack from the Library by name (like git-flow-command-center), or your own Stack's id from its Export page. Each Binding becomes its own skill under .agents/skills/.

  3. 3

    Keep it current

    Run $bindry-connect once, then sync the Stack in live mode, and the skills always read the latest version. Prefer a fixed snapshot? Re-sync when the Stack changes — $bindry-check shows what is out of date.

Install

codex plugin marketplace add bindryai/Plugins
codex plugin add bindry@bindry-plugins

Point marketplace add at the repo root, not the codex/ subdirectory — Codex reads its manifest from codex/.agents/plugins/marketplace.json, which is the confirmed location (not .codex-plugin/marketplace.json, as a naive port from Claude Code would suggest). Verified against the real @openai/codex CLI: codex plugin list reports it installed and enabled.

What a compiled skill looks like

The same Binding shown on the Claude Code plugin page, compiled to skills/git-branch-and-pr-hygiene/SKILL.md — identical format, different folder:

SKILL.md
---
name: git-branch-and-pr-hygiene
description: Branch & PR Hygiene. Use when: Creating a branch; Opening or updating a pull request.
---

<!-- bindry:pin stack=git-flow-command-center binding=bnd_git_branch_pr_hygiene version=3.1.0 -->

Use feature/<ticket>-<slug> branch names. Keep commits scoped to one logical
change with an imperative summary line. PR descriptions must include a
one-line "why" and a manual test note.

Constraints:
- Do not squash commits that mix unrelated changes into one message.

Verify before finishing:
- Every PR description has a test plan section before merge.

Install a Stack you don't own — no API key needed

$bindry-sync git-flow-command-center resolves a published Stack straight from the public Library by name. A key is only needed for your own private Stacks.

Using your own private Stacks

New to API keys? Read the plain-language explainer first if "generate a key" doesn't already mean something to you.

  1. 1

    Generate a key on the workspace's Team page

    Not Account settings — a key is scoped to whichever workspace's Team page you make it from. Give it a name (e.g. "This laptop") and, optionally, an expiration date. There's no permission picker to fill in: the key already does everything you can do in that one workspace, nothing more.

  2. 2

    Put it in BINDRY_API_TOKEN

    Set it as an environment variable rather than pasting it into a command — both bindry-sync and bindry-connect read the same variable, and it's the only credential either one needs.

  3. 3

    One key per workspace

    A key never sees more than the single workspace it was created in. Working across more than one team? Make a separate key on each team's own Team page, rather than expecting one key to reach both.