home / skills / a5c-ai / babysitter / plugin-manifest-schema

plugin-manifest-schema skill

safe

/plugins/babysitter/skills/babysit/process/specializations/cli-mcp-development/skills/plugin-manifest-schema

This skill validates and enforces a plugin manifest schema with versioning and dependencies to ensure consistent, reliable plugin packaging.

npx playbooks add skill a5c-ai/babysitter --skill plugin-manifest-schema

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

944 B

---
name: plugin-manifest-schema
description: Define plugin manifest schema with versioning and dependency declarations.
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
---

# Plugin Manifest Schema

Define plugin manifest schema.

## Generated Patterns

```typescript
import { z } from 'zod';

export const pluginManifestSchema = z.object({
  name: z.string().regex(/^[a-z0-9-]+$/),
  version: z.string().regex(/^\d+\.\d+\.\d+/),
  description: z.string(),
  main: z.string().default('index.js'),
  author: z.string().optional(),
  license: z.string().optional(),
  engines: z.object({
    app: z.string().optional(),
    node: z.string().optional(),
  }).optional(),
  dependencies: z.record(z.string()).optional(),
  hooks: z.array(z.string()).optional(),
  permissions: z.array(z.string()).optional(),
});

export type PluginManifest = z.infer<typeof pluginManifestSchema>;
```

## Target Processes

- plugin-architecture-implementation

Overview

This skill defines a strict plugin manifest schema for JavaScript projects, including versioning, dependency declarations, and runtime engine hints. It provides a validated shape to declare names, semantic versions, entry points, hooks, permissions, and optional metadata. The schema is implemented with Zod and exports a typed manifest type for safe consumption in orchestration systems.

How this skill works

The skill exposes a Zod object schema that enforces name and version formats, default values, and optional sections for engines, dependencies, hooks, and permissions. When applied, manifests are validated at runtime or build time to ensure consistency and predictable behavior across plugins. The exported TypeScript type lets the orchestrator and developer tools consume manifests with full static typing.

When to use it

Creating or validating plugin manifests for an agentic orchestration system.
Enforcing consistent naming and semantic versioning for plugins.
Declaring runtime expectations like Node or host app versions before deployment.
Listing plugin dependencies, hooks, and permissions for automated installers.
Integrating manifest checks into CI/CD pipelines to prevent invalid releases.

Best practices

Use lowercase dash-separated names matching the name regex to avoid rejection.
Follow semantic versioning and ensure the version string conforms to the regex.
Provide a main entry file or rely on the default 'index.js' for clarity.
Declare engine ranges and dependencies to make installations deterministic.
Enumerate hooks and permissions explicitly to improve security audits.

Example use cases

A CI job validates plugin manifests using the schema before publishing to a registry.
An orchestration layer reads manifests to determine which hooks to call during workflow execution.
A dependency installer reads the dependencies record to fetch precise package versions.
A security scanner uses permissions and hooks fields to flag potentially risky plugins.

FAQ

What name format is allowed?

Names must be lowercase, containing only letters, digits, and dashes, matching the /^[a-z0-9-]+$/ pattern.

How strict is the version field?

The version requires a numeric semantic-style string starting with major.minor.patch as enforced by the /^ ?\d+\.\d+\.\d+/ regex.