agent-skillsvibe-agent-toolkitai-agentsworkflowopenclaw

Validate Agent Skills with Vibe Agent Toolkit Before You Share Them

A first-run guide for @vibe-agent-toolkit/agent-skills: inspect the package, create a small SKILL.md, run validateSkill, and turn validation into a team review habit.

Reader persona: a founder, AI operations lead, or developer-operator who is creating reusable agent skills and wants a quick quality gate before sharing them with a team.

Job to be done: validate a SKILL.md file in a clean folder, understand the common failure modes, and decide how to add skill validation to a lightweight review process.

Agent skills are easy to write.

That is the good news.

It is also the risk.

A skill can look like a markdown note, but it can change how an agent searches, edits files, runs commands, uses a browser, or talks to customers. If you are going to reuse skills across agents, you need a quality gate before “copy this into production.”

For today’s validation pass, the strongest public package signal was:

@vibe-agent-toolkit/[email protected]

Package metadata:

name: @vibe-agent-toolkit/agent-skills
description: Build, validate, and package agent skills in the Agent Skills format
repository: https://github.com/jdutton/vibe-agent-toolkit.git

The package provides TypeScript APIs for validating, importing, exporting, and building agent skills. This guide focuses on the most operator-friendly first step: validation.

What the validator checks

The README describes validation coverage for:

  • required YAML frontmatter;
  • valid skill name format;
  • missing or empty descriptions;
  • overly long descriptions;
  • broken markdown links;
  • Windows-style paths;
  • very long skill files;
  • tool or capability signals such as local shell usage, browser authentication, and external CLI use.

That is a useful first pass.

It will not prove your skill is good, safe, or strategically useful.

But it can catch common structural issues before a human review.

Install in a throwaway folder

Start clean:

mkdir vibe-skill-validate
cd vibe-skill-validate
npm init -y
npm install @vibe-agent-toolkit/[email protected]

This installs the package as a library. It is not primarily a one-command CLI flow. You call the validation API from a small script.

Create a small test skill

Create a realistic skill folder:

mkdir -p skills/customer-proof/references
cat > skills/customer-proof/SKILL.md <<'SKILL'
---
name: customer-proof
description: Turn customer quotes and call notes into a source-linked proof library for marketing and sales.
---

# customer-proof

Use this skill when you need to extract customer proof from notes, transcripts, or support messages.

## Inputs

- Customer call notes
- Support tickets
- Sales discovery notes

## Workflow

1. Read the provided source material.
2. Extract direct quotes only when the source text supports them.
3. Group proof by pain point, buyer type, and product capability.
4. Write a summary table with source links.

## Output

Return a table with quote, source, theme, and recommended use.
SKILL

This is intentionally mundane.

Good validation starts with normal workflow skills, not clever demos.

Run validateSkill

Create a script:

cat > validate.mjs <<'JS'
import { validateSkill } from '@vibe-agent-toolkit/agent-skills';

const result = await validateSkill({
  skillPath: './skills/customer-proof/SKILL.md',
  rootDir: './skills/customer-proof',
});

console.log(JSON.stringify(result, null, 2));

if (result.status === 'error') {
  process.exit(1);
}
JS

Run it:

node validate.mjs

Local validation returned:

{
  "path": "./skills/customer-proof/SKILL.md",
  "type": "agent-skill",
  "status": "success",
  "summary": "0 errors, 0 warnings, 0 info",
  "issues": [],
  "metadata": {
    "lineCount": 26,
    "name": "customer-proof",
    "description": "Turn customer quotes and call notes into a source-linked proof library for marketing and sales."
  }
}

That is the result you want before sharing a skill.

Test a bad skill on purpose

Before trusting a validator, make it fail.

Create a deliberately broken skill:

mkdir -p skills/bad-skill
cat > skills/bad-skill/SKILL.md <<'SKILL'
# Missing frontmatter

Do some stuff.
SKILL

Then change the script path:

skillPath: './skills/bad-skill/SKILL.md',
rootDir: './skills/bad-skill',

Run:

node validate.mjs

You should expect an error status and issues pointing to missing frontmatter or missing required metadata.

This failure test matters. It confirms the validation gate is actually doing work.

Add an operator review layer

A clean validation result is not the same as approval.

After validation passes, ask an agent or reviewer to answer these questions:

Review this skill for operational risk.
Classify it as:
- read-only
- file write
- browser action
- command execution
- external API write
- publishing or messaging
- billing/account impact

Quote the exact lines that support the classification.
Then recommend whether it is safe to install, needs approval boundaries, or should not be installed yet.

For the customer-proof skill above, the likely result is low risk because it reads notes and returns a table. If a skill mentions posting, deleting, buying, messaging, browser clicks, or shell commands, treat it differently.

What to put in CI

If your team keeps skills in Git, add a tiny validation script.

Example structure:

skills/
  customer-proof/
    SKILL.md
  sales-brief/
    SKILL.md
scripts/
  validate-skills.mjs

The script can loop through every SKILL.md and fail the build if any status is error.

The point is not to slow the team down.

The point is to stop broken skills from becoming invisible agent behavior.

Where this fits with ClawMama

ClawMama is the next step after local skill quality control.

A practical rollout looks like this:

  1. write the skill locally;
  2. validate the SKILL.md structure;
  3. review operational risk and approval boundaries;
  4. install the skill into an OpenClaw or Hermes agent;
  5. run that agent as a managed Telegram bot for the team.

New ClawMama users get $2 in credits, and the hosted path gives you the latest ChatGPT model without asking every teammate to manage Node, Docker, a VPS, model keys, and runtime upgrades.

That makes validation more valuable, not less. Once a skill is inside an always-on agent, more people can use it. More usage means more reason to review the skill before rollout.

Bottom line

Use @vibe-agent-toolkit/agent-skills as a structural validation gate.

It will not replace human judgment.

It will catch issues early enough that human judgment has something clean to review.