"Pack Manifests: The Schema That Makes AI Skills Portable"

Your agent has a killer email workflow. Mine needs one. There's no way to get yours into mine.

We can share npm packages. Docker images. Terraform modules. Helm charts. But AI agent capabilities? Those live in scattered prompt files, undocumented tool configs, and "just paste this into your system prompt" blog posts.

The AI ecosystem has a packaging problem. Not a model problem, not a prompt engineering problem — a packaging problem. Agent skills aren't portable because there's no standard way to describe what a skill is, what it needs, and how to install it.

Pack manifests are how we're fixing that on PackDrop.

The Packaging Gap

Every mature software ecosystem has a manifest format. npm has package.json. Python has pyproject.toml. Docker has Dockerfile. Kubernetes has pod specs. These formats exist because you can't distribute software at scale without a machine-readable description of what you're distributing.

AI agent skills have no equivalent.

Right now, sharing an agent capability looks like this:

Someone builds a useful workflow — say, a lead qualification pipeline
They write it up in a README (maybe)
Another developer reads the README, figures out the dependencies
They manually configure their agent runtime to support it
They copy-paste the relevant prompt and tool config
They debug for hours because the README was wrong about one dependency

That's not a distribution model. That's a folk tradition.

The core issue: there's no structured way to declare what an AI skill contains, what it requires, and how a consuming agent should install it. Without that, skills can't be discovered programmatically, can't be validated before installation, and can't move between different agent frameworks.

The Manifest Schema

A pack manifest is a JSON object that fully describes an AI capability pack. Here's the complete schema:

json

{
  "name": "Smart Email Responder",
  "slug": "smart-email-responder",
  "version": "2.1.0",
  "type": "skill",
  "category": "communication",

  "description": "AI-powered email triage and response drafting",
  "tagline": "Reduce response time by 80%",
  "tags": ["email", "automation", "customer-support", "nlp"],

  "manifest": {
    "entry": "main.js",
    "capabilities": ["email.read", "email.send", "template.render"],
    "requirements": ["gmail_oauth"],
    "compatibility": ["claude-code", "cli-agents", "api-agents"],
    "permissions": ["network", "email.read", "email.send"],
    "assets": [
      { "path": "prompts/triage.md", "type": "prompt" },
      { "path": "templates/responses.json", "type": "config" }
    ],
    "install": {
      "method": "copy",
      "target": ".packdrop/packs/smart-email-responder"
    },
    "checksum": "sha256:a1b2c3d4e5f6..."
  },

  "price": 0,
  "icon_url": "/icons/email-responder.png",
  "repo_url": "https://github.com/example/smart-email-responder"
}

Let me walk through every section.

Identity Fields

json

{
  "name": "Smart Email Responder",
  "slug": "smart-email-responder",
  "version": "2.1.0",
  "type": "skill"
}

slug is the unique identifier across the entire marketplace. It's what agents use in every command: packdrop install smart-email-responder. Slugs are auto-generated from the name if you don't provide one, but once set, they're immutable. Changing a slug would break every agent that references it.

version follows semver. Pack versions are tracked in a separate pack_versions table with changelogs, so agents can pin to specific versions or check what changed before upgrading.

type is one of five values: skill, workflow, tool, knowledge, or system. This isn't cosmetic — it tells consuming agents what kind of capability they're getting:

| Type | What It Contains | Example | |------|-----------------|---------| | skill | Prompt + tool configuration for a specific task | Code review, email triage | | workflow | Multi-step orchestration with branching logic | Lead qualification pipeline | | tool | A single tool or API connector | Stripe connector, GitHub PR creator | | knowledge | Reference data, templates, or knowledge bases | Industry compliance rules | | system | Agent runtime configuration or infrastructure | Logging setup, error handling |

An agent searching for "something that handles email" can filter by type: skill to get task-specific packs, or type: workflow to get full pipelines. Machine-readable type declarations make that possible.

The Manifest Object

The manifest field is where it gets interesting. This is a JSONB column in PostgreSQL — no fixed schema, deliberately flexible — but we've converged on a set of fields that make packs genuinely portable:

entry — The primary entrypoint file. For skill packs, this is typically the main prompt or configuration file. For tool packs, it's the executable script.

capabilities — What this pack can do, expressed as dot-notation strings. email.read, email.send, template.render. These are the pack's declared outputs — the things a consuming agent gains by installing it. Think of them like exported functions in a module.

requirements — What the pack needs from the host environment. gmail_oauth means the consuming agent must have Gmail OAuth configured. If requirements aren't met, installation should warn (or fail) rather than install something that will break at runtime.

compatibility — Which agent runtimes this pack works with. We currently define three targets:

claude-code — Packs designed for Claude Code / Claude Agent SDK environments
cli-agents — Packs that work in any CLI-based agent runtime
api-agents — Packs consumable via API calls

This is critical for portability. A pack tagged claude-code tells you it uses MCP server conventions. A pack tagged cli-agents works with any framework that can execute shell commands. Agents filter by compatibility before installation, which prevents the "installed it, doesn't work" failure mode.

permissions — What system-level access the pack requires. network means it makes external HTTP requests. email.read and email.send mean it touches email infrastructure. Permissions let agents (and their operators) make informed decisions before granting access.

assets — The files included in the pack, with type annotations. Agents can inspect the asset list before downloading anything. A pack with "type": "prompt" assets is lightweight text. A pack with "type": "binary" assets is heavier. This matters for agents running in constrained environments.

install.method — How the pack gets installed. copy means copy files to a local directory. Future methods could include link (symlink), register (add to a tool registry), or remote (keep the pack server-side and call via API).

checksum — SHA-256 hash of the pack contents. Agents can verify integrity after download. This exists because agents operating autonomously shouldn't blindly trust downloaded code. If the checksum doesn't match, the pack was tampered with or corrupted in transit.

Building with AI agents? Get weekly insights on agentic tooling.

You're in ✓

Why Declarative, Not Executable

The biggest design decision: manifests are declarative JSON, not executable packages.

We considered the npm model — packs as installable modules with postinstall scripts that configure themselves. We rejected it for one reason: security in an agent context is fundamentally different from security in a human context.

When a developer runs npm install, they implicitly trust the install scripts (or at least accept the risk). When an autonomous agent installs a pack, there's no human reviewing the install script. A malicious postinstall in an agent-consumed package could exfiltrate API keys, modify other packs, or install backdoors — all without anyone noticing until the damage is done.

Declarative manifests eliminate this attack surface. A manifest describes what a pack contains. It doesn't execute anything. The consuming agent's runtime decides how to process the manifest — which files to copy, which permissions to grant, which capabilities to register. The pack author declares intent. The runtime enforces policy.

This is the same principle behind Kubernetes pod specs. A pod spec doesn't run arbitrary shell commands during scheduling. It declares what the pod needs, and the scheduler decides whether and how to provision it. The separation between declaration and execution is what makes the system auditable and secure.

A Real Example

Here's the actual manifest shape from the seed data for the Pipeline Automator pack — one of the most complex packs in the marketplace:

json

{
  "name": "Pipeline Automator",
  "slug": "pipeline-automator",
  "version": "3.0.1",
  "type": "workflow",
  "category": "automation",
  "tagline": "Build and execute multi-step data pipelines with automatic error recovery",
  "tags": ["automation", "data-pipeline", "etl", "orchestration"],
  "price": 19.99,

  "manifest": {
    "entry": "pipeline.js",
    "capabilities": [
      "pipeline.create",
      "pipeline.execute",
      "pipeline.checkpoint",
      "pipeline.retry"
    ],
    "requirements": [],
    "compatibility": ["claude-code", "cli-agents", "api-agents"],
    "permissions": ["network", "filesystem.read", "filesystem.write"],
    "assets": [
      { "path": "pipeline.js", "type": "tool" },
      { "path": "connectors/", "type": "config" },
      { "path": "prompts/orchestration.md", "type": "prompt" }
    ],
    "install": {
      "method": "copy",
      "target": ".packdrop/packs/pipeline-automator"
    }
  }
}

An agent evaluating this pack can determine programmatically:

What it gets: Four pipeline capabilities (create, execute, checkpoint, retry)
What it needs: Network access and filesystem read/write — no OAuth dependencies
Where it works: All three agent runtime targets
What it costs: $19.99 one-time purchase
What's inside: A JavaScript tool, a connectors config directory, and an orchestration prompt

No README parsing. No guesswork. The manifest is the contract.

What This Enables

The manifest isn't just documentation — it's an API contract between pack authors and consuming agents. With a standardized manifest, agents can:

Discover skills programmatically. An agent that needs email capabilities can query the marketplace for packs where manifest.capabilities includes email.*. No keyword guessing, no full-text search heuristics — structured capability matching.

bash

packdrop search "email" --category communication --json

The search results include manifest data, so the agent can filter by compatibility and requirements before even viewing the full pack details.

Evaluate before installing. The manifest tells you everything about what a pack will do to your environment before you install it. Requirements not met? Skip it. Permissions too broad? Skip it. Wrong compatibility target? Skip it. Agents make these decisions in milliseconds, without human review.

Install without human intervention. Because the install method and target directory are declared, a consuming agent can install a pack end-to-end:

bash

# Agent discovers, evaluates, and installs — no human needed
export PACKDROP_TOKEN="pk_live_..."

packdrop search "data pipeline" --json \
  | jq '.[0].slug' -r \
  | xargs packdrop install

Compose capabilities. When two packs declare compatible capabilities, agents can chain them. A pack that outputs data.structured can feed into a pack that requires data.structured as input. Manifest-level capability declarations make this composability discoverable.

Audit what's running. Every installed pack has a manifest. An agent's operator can inspect exactly which capabilities are active, what permissions they hold, and what versions are running. Compare that to the current state of "which prompts did we paste into the system message last week?"

The Road Ahead

The manifest schema is deliberately versioned and extensible. JSONB storage means new fields don't require schema migrations — a pack published tomorrow can include fields that don't exist today, and older consumers just ignore what they don't understand.

Fields we're considering for future manifest versions:

dependencies — Packs that depend on other packs (like npm package dependencies)
triggers — Events that activate the pack (cron schedule, webhook, specific agent state)
outputs — Structured declaration of what the pack produces (reports, data, messages)
resource_limits — CPU, memory, and API call budgets the pack should operate within

Each addition makes packs more self-describing and agent runtimes more capable of managing them autonomously.

Try It

Create a pack with a manifest in under two minutes:

bash

# Install the CLI
npm install -g packdrop

# Log in
packdrop login

# Create a pack (interactive prompts guide you)
packdrop pack create --name "My Custom Skill" --type skill --category automation

# Publish when ready
packdrop pack publish <pack-id>

Browse existing pack manifests at packdrop.polsia.app — every pack's manifest is visible on its detail page. The full CLI reference and API documentation live at packdrop.polsia.app/docs.

If you're building an agent framework and want to support pack manifests as a skill format, we'd love to talk.

PackDrop is the agent-first marketplace for AI capability packs. The manifest schema is open — adopt it, extend it, build on it. packdrop.polsia.app

"Pack Manifests: The Schema That Makes AI Skills Portable"

The Packaging Gap

The Manifest Schema

Identity Fields

The Manifest Object

Why Declarative, Not Executable

A Real Example

What This Enables

The Road Ahead

Try It

Get notified when new packs drop