plugin-manifest-schema
npx machina-cli add skill a5c-ai/babysitter/plugin-manifest-schema --openclawPlugin Manifest Schema
Define plugin manifest schema.
Generated Patterns
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
Source
git clone https://github.com/a5c-ai/babysitter/blob/main/plugins/babysitter/skills/babysit/process/specializations/cli-mcp-development/skills/plugin-manifest-schema/SKILL.mdView on GitHub Overview
This skill defines a strict Plugin Manifest schema using zod to validate core metadata and enforce versioning. It covers name, version, description, main, author, license, engines, dependencies, hooks, and permissions, ensuring consistent packaging and dependency declarations across plugins.
How This Skill Works
Technically, it uses a zod object to enforce types and patterns for the manifest fields. The name field must match the lowercase-hyphen regex, the version must look like a semantic version, and main defaults to 'index.js' when omitted. Optional sections like author, license, engines, dependencies, hooks, and permissions are modeled to allow flexible but structured declarations, and the PluginManifest type is produced via z.infer<typeof pluginManifestSchema>.
When to Use It
- When starting a new plugin in the plugin-architecture-implementation workflow.
- When enforcing semantic versioning for plugin releases.
- When including optional metadata like author, license, or engines for compatibility.
- When declaring dependencies for a plugin's runtime or tooling.
- When generating a TypeScript type for downstream tooling via z.infer.
Quick Start
- Step 1: Create a manifest file with name, version, and description (and optional fields as needed).
- Step 2: Validate the manifest with pluginManifestSchema.parse(manifest) in your TypeScript code.
- Step 3: Export the generated type PluginManifest via z.infer<typeof pluginManifestSchema> for downstream tooling.
Best Practices
- Ensure the name field uses the regex /^[a-z0-9-]+$/ to keep naming consistent.
- Adopt semantic versioning and validate it with the version pattern ^\d+\.\d+\.\d+.
- Default main to 'index.js' to simplify manifests and avoid missing entry points.
- Model dependencies as a simple string-to-string map to keep compatibility.
- Document optional fields (author, license, engines, hooks, permissions) for clarity and tooling.
Example Use Cases
- Minimal manifest: { name: 'my-plugin', version: '1.0.0', description: 'A plugin' }
- Manifest with author: { name: 'my-plugin', version: '1.0.0', description: 'A plugin', author: 'Alice' }
- Manifest with engines: { name: 'my-plugin', version: '1.2.3', description: 'A plugin', engines: { app: '>=1.0.0', node: '>=14' } }
- Manifest with dependencies: { name: 'my-plugin', version: '2.0.0', description: 'A plugin', dependencies: { 'lodash': '^4.17.21' } }
- Manifest with hooks and permissions: { name: 'my-plugin', version: '1.0.0', description: 'A plugin', hooks: ['onLoad', 'onUnload'], permissions: ['read', 'write'] }
