Frequently asked questions
Bindry packages agent instructions — Claude Code skills, Codex skills, GitHub Copilot instructions, AGENTS.md, and MCP tools — into reusable, versioned skills and Binders.
What is Bindry?
Bindry is a package manager for AI agent skills — version controlled, CLI accessible, and loaded just in time. Write your team's instructions once — brand voice, sales playbooks, email tone, writing style or coding standards — as reusable skills, group them into Binders, and your agent takes out only the ones a task calls for: in Claude Code, Codex and GitHub Copilot through plugins, or in any other AI tool through AGENTS.md, Markdown or MCP.
How do I reuse agent instructions across repos?
Write the instruction once as a skill in Bindry, then either export it as a file (AGENTS.md, or a Claude Code/Codex/GitHub Copilot bundle) into each repo, or install the Claude Code, Codex, or GitHub Copilot plugin so /bindry-sync pulls the Binder into any repo on demand. Either way there is one source, not a copy that can drift.
What's a package manager for SKILL.md?
That's what Bindry is. It versions each skill, compiles it into a SKILL.md file (Claude Code's on-demand skill format) or the Codex/Copilot equivalent, and re-syncs every consuming repo when the skill changes — the same job npm or pip do for code dependencies, applied to agent instructions instead.
How do I keep Claude Code and Codex instructions in sync?
Write the instruction once as a skill in Bindry, then run /bindry-sync from both the Claude Code plugin and the Codex plugin. Each compiles the exact same source content into its own tool's skill format (.claude/skills/ vs .agents/skills/), so there is only one place to edit when the rule changes.
What happens if I install more than one Binder in the same repo?
They coexist. Skills land in their own directories, and each Binder’s always-on instructions are written as a separate marked block in the same file (CLAUDE.md, AGENTS.md or .github/copilot-instructions.md), in the order you installed them. Re-syncing one Binder replaces only its own block and leaves the others — and anything you wrote by hand — exactly as they were. This is a convention rather than a feature: nothing in Bindry marks one Binder as more important than another, and nothing orders or filters them by level.
What if two Binders’ always-on instructions disagree?
Both are present, and the model reconciles them — there is no precedence rule, in Bindry or in any of the agent tools. Rather than invent one you could not predict without reading our source, the blocks stay in install order so the Binder you added last reads last. The practical fix is narrow layers: instructions that state only what is genuinely universal leave room for a more specific Binder to be specific without contradicting them. A direct contradiction between two Binders is an authoring problem, not something tooling should paper over.
What is AGENTS.md?
A plain-text file listing the instructions an AI coding agent should follow in a repo. It's one of the export targets a Bindry Binder can compile to directly, alongside Claude Code skills, Codex skills, and GitHub Copilot instructions, for tools that read a single instructions file rather than a plugin or skill directory.