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.