# Create Plugin

> Create minimal, convention-matching plugins or extensions for an existing codebase. Use when the user asks for a plugin, extension, custom module, integration, or add-on for an open-source/project repository and wants the work to stay simple, readable, and aligned with the host project's structure and style.

- Skill: `luokai0/create-plugin` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add luokai0/create-plugin`
- Raw SKILL.md: https://api.skillmd.com/api/skills/luokai0/create-plugin/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: luokai0 (https://skillmd.com/u/luokai0)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/luokai0/create-plugin

---


# Create Plugin

Build the smallest plugin that solves the requested problem while fitting the host codebase.

## Workflow

1. Learn the codebase before designing anything.
	- Read the GitHub repository first.
	- Read official docs linked from the repository, especially installation, API, examples, and contribution/style guidance.
	- If the `deepwiki` skill is installed, use DeepWiki MCP for public-repo source-code queries before guessing.
	- Use DeepWiki MCP for three things in particular:
		- `structure` to map the documentation/wiki layout,
		- `contents` to read relevant topic pages,
		- `ask` to query extension points, module organization, APIs, naming patterns, and built-in examples to copy.
	- Ask questions that are concrete and code-oriented, for example:
		- "What are the main extension points for adding a new plugin/module?"
		- "Which built-in modules are the smallest and best examples to study first?"
		- "How is the package organized, and where should a minimal extension live?"

2. Learn the modular structure.
	- Identify the extension points, package layout, naming conventions, imports, base classes, and how existing modules are organized.
	- Use DeepWiki MCP source-code queries to accelerate this discovery when the repo is public.
	- Inspect one or two similar built-in modules or extensions and mirror their shape.

3. Make a short plan before coding.
	- State the minimal implementation approach.
	- Prefer the smallest API and fewest files that still feel native to the project.
	- Call out any deliberate simplifications.

4. Implement the plugin.
	- Match the host project's conventions first: formatting, file layout, typing style, docstrings, imports, naming, and dependency choices.
	- Prefer readability over novelty.
	- Avoid adding dependencies unless clearly justified.
	- Do not modify upstream/vendor code unless the user explicitly asks for an in-tree patch.

5. Check convention fit.
	- Verify that names, module boundaries, and public API feel consistent with the host codebase.
	- If the environment is difficult, it is acceptable to skip full runtime testing, but still do lightweight checks that are feasible, such as syntax checks, lint-style review, or import-path review.
	- Be explicit about what was and was not verified.

6. Document the plugin.
	- Add minimal usage documentation.
	- Explain the core API, state/inputs/outputs if relevant, and the main simplifying assumptions.
	- Keep documentation proportionate to the plugin size.

## Design Rules

- Start from existing examples in the host repo before inventing structure.
- Keep the extension minimal and easy to read.
- Prefer a narrow, obvious API.
- Follow the host project's patterns more than generic best practices when the two differ.
- When uncertain, choose the simpler design and note the limitation.
- Do not promise physical/functional fidelity beyond what the implementation actually does.

## Output Checklist

Before finishing, confirm all of the following:
- the repository and docs were reviewed first
- the modular structure was inspected
- a plan was made before implementation
- the plugin is minimal and readable
- the code follows host-project conventions as closely as practical
- documentation was added
- verification scope is stated honestly

## References

- For a worked example based on CAX, read `references/cax-recrystallization-example.md`.
- Only read the reference when the current task is similar or when you want an example of how to apply this workflow to a scientific/plugin-style extension.
- If the `deepwiki` skill is available, read its SKILL and use its `ask`, `structure`, and `contents` commands for public GitHub repositories during the repo-learning phase.