Creating plugins: manifest, components and publishing

You will create a manifest, keep components in the right directories and separate structural validation from behavioral testing. Outputs are illustrations.

Official creation, manifest and eval sources checked September 30, 2026 describe session-only loading as a way to develop without a marketplace. Publishing and sharing are separate steps; this lesson does neither.

Keep a standalone Skill for a single project if it works. A Plugin becomes useful for a versioned collection reused across projects. Do not add hooks or servers just to make the package look substantial.

Plan a local plugin containing only the tested course-update-check Skill.
Return the directory tree and minimum manifest.
No hooks, MCP, installation, marketplace publication or account connection.

Use a separate practice folder:

course-tools/
  .claude-plugin/
    plugin.json
  skills/
    course-update-check/
      SKILL.md

Only the manifest belongs inside .claude-plugin/. The skills/ directory is beside it at the Plugin root, not inside it. Copy the tested Skill and inspect its actual contents before loading.

Example plugin.json:

{
  "name": "course-tools",
  "version": "0.1.0",
  "description": "Source-grounded course draft checks"
}

This is a local example, not an installed or endorsed package. Do not put keys, raw customer drafts or personal paths in the manifest.

Run the documented validator against your folder:

claude plugin validate ./course-tools

Read the actual result. Validation checks package structure; it does not prove the Skill follows evidence, produces useful writing or avoids unintended effects. If it fails, fix the named field/path before attempting a session.

When ready for a model session, from the directory containing the package:

claude --plugin-dir ./course-tools

This loads the package for that session without an installation entry. The session still uses the applicable Claude plan or billing. Inspect the namespaced Skill, such as /course-tools:course-update-check, in the menu. Use /reload-plugins after changes where needed and verify the loaded version.

Run course-tools:course-update-check on this pair only.
Source: one chapter ready; date unset.
Draft: all chapters ready; launch tomorrow.
Return unsupported claims and a corrected draft. Do not edit or publish.

Illustrative result:

Unsupported: all chapters ready; launch tomorrow.
Correction: One chapter is ready. The launch date is not set.

Retest an accurate draft, an unsupported date and a missing source. Record the expected behavior before the run and the actual result after it. A package that only passes its greeting or happy path is not ready for work.

The official eval system can run model-backed evaluations. Check account, model, number of runs and pricing before any such execution. A written test matrix is enough for this lesson; there is no need to run a paid eval or publish a marketplace entry.

Easy: layout

Build manifest plus one Skill. Success: root placement is correct and validator result is read.

Intermediate: namespacing

Load locally and find the correct command. Success: you know which package/version supplied it.

Challenging: regression

Change one instruction and rerun three cases. Success: no unsupported claim becomes accepted.

Skill missing: verify it is outside .claude-plugin/ and inside its own Skill directory.

Old instructions: reload and verify behavior, not file timestamp alone.

Validation passed but output wrong: repair instructions and acceptance cases.

Public release requested: review package contents, license and audience separately.

Unexpected dependency: stop and inspect before loading work data.