Repo-owned skills

Skills quickstart for coding-agent teams.

OpenVibeCoding is the command tower for AI engineering, and it already ships a public, repo-owned skills quickstart here. The truthful adoption path today is: reuse repo-owned playbooks for Codex / Claude Code workflows, and adapt the same playbooks for adjacent tools such as OpenClaw without pretending OpenVibeCoding is already a listed or shipped item inside those official plugin ecosystems.

Open the adoption path Open compatibility matrix Open agent starter kits See integration guide See builder quickstart See maintainer fast path

Need the fastest proof-first walkthrough before you adopt repo-owned skills? See the first proven workflow.

What an OpenVibeCoding skill is

Playbook

Repeatable behavior

A skill is a repo-owned playbook that tells an agent when to trigger, what to read first, what to avoid, and what “done” means.

Boundary

Truthful scope

Skills are not magic capability unlocks. They organize how agents work with the repo's real MCP, docs, contracts, and runbook boundaries.

Portability

Cross-agent reuse

The same playbook can guide Codex or Claude Code style workflows directly, and can also be adapted to adjacent coding-agent tools without inventing fake official support.

How to use skills today

Start from this public guide, then choose the closest adoption lane: protocol, skills, builder packages, or proof-first cases.
Read the tracked repo entrypoints before you start broad exploration or code changes.
Use the skill together with the repo's truthful entrypoints: read-only MCP, API/client packages, docs, and Task Board.
Keep the skill boundary honest: if a playbook says hosted or write-MCP is frozen, treat that as a real stop sign.

If your team already knows it wants the MCP side wired too, pair this page with the agent starter kits instead of reconstructing Codex / Claude Code / OpenClaw config files from scratch.

The current bundle now carries one registry-shaped skill artifact too: public-skills/openvibecoding-adoption-router/manifest.yaml. That makes the adoption-router skill package-ready across Codex / Claude Code / OpenClaw style installs without pretending the local bundle example is the canonical public root or that Codex / Claude Code / OpenClaw listings already exist.

Minimal vendored skill-pack layout

If you want a drop-in starting point instead of a vague “reuse the repo's skills,” keep the copied surface small and explicit.

vendor/OpenVibeCoding/
  README.md
  AGENTS.md
  .agents/skills/<chosen-skill>/
    SKILL.md
    manifest.yaml

Copy the two truth files first: README.md and AGENTS.md.
Copy only the skill folders you truly want the agent to reuse; do not mirror the whole repo just to say “skills exist.”
Keep the tracked manifest.yaml with the skill whenever the host tool or future registry expects machine-readable metadata.
Keep the skill paired with the same repo-owned read-only MCP command when the workflow needs machine-readable inspection.
Preserve the stop-signs inside the skill: hosted, write-MCP, and plugin/store claims stay frozen until the repo truth changes.

Best-fit usage by coding agent

Codex

Use repo-local skills as execution contracts around Command Tower, Workflow Cases, Proof & Replay, and repo-owned MCP/API surfaces.

Claude Code

Use the same skill pack when you want the repo's own safety rails, docs-first read order, and operator-facing truth layers.

OpenClaw

Use skills as an adaptation layer for repo truth. OpenClaw has real plugin and skills surfaces, and OpenVibeCoding now carries a ClawHub-shaped manifest.yaml for its shared adoption-router skill, but it still lands on the integration-and-skills side first rather than claiming an official shipped plugin.

Official ecosystem anchors

Codex

Native reference points: repo, docs, and IDE install.

OpenVibeCoding skills should act as repo-owned operating contracts around those workflows, not as a replacement for Codex's own native surfaces.

Claude Code

Native reference points: overview and MCP docs.

OpenVibeCoding skills should carry the repo's own read order, truth layers, and safety rails into Claude Code workflows without implying a marketplace listing.

OpenClaw

Native reference points: repo, skills docs, and ClawHub.

OpenClaw already has real skills, a workspace path, and a public registry/catalog, so OpenVibeCoding should fit as repo truth + proof + read-only MCP guidance rather than pretending to be the native OpenClaw plugin itself. The tracked manifest.yaml is there so the shared skill has registry-shaped metadata ready when later external submission actually happens.

Truthful adoption ladder

Start from the native ecosystem docs first, so you know what the host tool already provides.
Use OpenVibeCoding skills to carry the repo's own read order, safety rails, and done semantics into that workflow.
Pair the skill with the repo's truthful entrypoints: compatibility matrix, read-only MCP, builder packages, and proof-first use cases.
For OpenClaw specifically, treat the official skills workspace and ClawHub registry as the native host surface, then adapt OpenVibeCoding playbooks around it instead of relabeling OpenVibeCoding as the native plugin.

What this page is not claiming

not a published Codex listing or a Claude Code marketplace surface
not an official OpenClaw plugin package
not a hosted skill registry service

The truthful product story is smaller but stronger: the repository already gives teams reusable, inspectable skill playbooks that align with the real Command Tower / MCP / Proof & Replay contract, and the shared adoption-router skill now includes registry-shaped metadata without skipping ahead to a fake published-listing claim.

Fast path for maintainers

sed -n '1,220p' README.md
sed -n '1,220p' docs/README.md
sed -n '1,220p' AGENTS.md

Those three tracked files are enough to understand the public product spine, the docs inventory, and the repo-owned AI working contract without depending on local-only overlays.

FAQ

Are skills the same as a plugin marketplace?

No. OpenVibeCoding skills are repo-owned playbooks that guide agent behavior around the repo's real docs, MCP, contracts, and workflow boundaries.

Can Codex and Claude Code teams use these today?

Yes. The public skills quickstart is designed for Codex and Claude Code style workflows that need repeatable operating playbooks on top of the current Command Tower and proof surfaces.

How should OpenClaw teams interpret this page?

OpenClaw belongs in the adjacent coding-agent layer. Use this page as an adaptation guide for repo truth, not as a claim that OpenVibeCoding already ships an official OpenClaw plugin package.

Does this page imply a hosted skill registry or write-capable MCP?

No. The current public story is repo-owned skills plus read-only MCP and current builder entrypoints, not a hosted skill registry or public write-capable MCP.