grasshopper-plugin-development

name

grasshopper-plugin-development

description

Design, implement, refactor, package, and release compiled Rhino 8 and Grasshopper plugins in C# for Codex. Use when the user asks for a Grasshopper plugin, `.gha` component development, RhinoCommon plugin architecture, Yak or Package Manager packaging, `manifest.yml`, Rhino 8 `.NET` plugin migration, component/service layering, build and release workflow, or maintaining a shared Grasshopper plugin repository.

Grasshopper Plugin Development

This skill is for compiled Rhino and Grasshopper plugin development, not for copy-paste script components inside Grasshopper nodes.

If the task is about C# Script, Python Script, RunScript(...), or code pasted into a node, use grasshopper-script-nodes instead.

Core workflow

1. Determine whether the task is:
   • compiled plugin architecture
   • component implementation
   • build/debug setup
   • Yak or Package Manager packaging
   • release preparation
   • repo review or refactor
2. Read references/architecture-and-coding.md for architecture and code rules.
3. Read references/build-release-and-yak.md for build, deployment, and Package Manager workflow.
4. Read references/official-rhino-yak-notes.md when the task touches Rhino runtime compatibility, Yak package layout, manifest.yml, distribution tags, or package restore behavior.
5. If the repository resembles INDToolsUpdate, preserve the layered structure and workflow discipline unless the user explicitly wants a different architecture.
6. Before release or packaging work, verify the task targets compiled .gha plugin distribution rather than script-node code generation.

Trigger rules

Use this skill when the user asks for ideas like:

• create a Grasshopper plugin
• build a Rhino 8 Grasshopper component in C#
• refactor a .gha plugin
• design plugin architecture for RhinoCommon and Grasshopper
• package a plugin for Rhino Package Manager
• create or review manifest.yml
• run yak build or yak push
• set up release workflow for a Grasshopper plugin
• migrate a Rhino or Grasshopper plugin to Rhino 8 / .NET Core

Strong markers include:

• .gha
• GH_AssemblyInfo
• GH_Component
• RhinoCommon
• Yak
• Package Manager
• manifest.yml
• RHINO_PACKAGE_DIRS
• Rhino 8
• GrasshopperComponents

Architecture defaults

• Separate responsibilities clearly: UI-facing components, domain services, reusable helpers and calculators, and cross-domain core utilities.
• Keep business logic out of GH_Component-style UI classes.
• Prefer moving reusable logic downward in the dependency graph instead of upward into component classes.
• Preserve developer-only functionality behind explicit runtime flags or controlled build paths when the product needs that distinction.
• Keep public plugin behavior stable and end-user-oriented; internal tools and debug affordances should not leak accidentally into release builds.

Repo handling rules

• When working in a shared repository, read the repo's own team docs before proposing architecture changes.
• If the repository is an IND shared repo, treat it as read-only unless the user explicitly gives the branch and file or exact edit scope.
• For personal repositories, edits are allowed by default, but publishing to GitHub should still follow the user's explicit instruction.

Build and debug defaults

• Prefer dotnet build for deterministic CLI verification.
• For Rhino 8 development on Windows, prefer a debug workflow that loads output through RHINO_PACKAGE_DIRS instead of copying files into user folders during normal development.
• Expect Rhino 8 plugin work to care about .NET Core compatibility and, in some cases, multi-targeting.
• Treat file-lock issues from a running Rhino session as a likely cause of failed builds before diagnosing deeper MSBuild problems.

Packaging and release defaults

• Treat Yak packaging and Rhino Package Manager support as first-class release concerns for public plugins.
• Keep manifest.yml in the package root.
• Ensure plug-in files such as .gha, .ghpy, or .rhp sit in the package top level or in the framework-specific directories required by multi-targeted packages.
• Prefer versions that are consistent across assembly metadata, GH_AssemblyInfo, project files, and Yak packaging inputs.
• Remember that package names are strict and package restore in Grasshopper benefits from package names matching plug-in names when possible.

Clarification policy

Ask only when the answer changes the architecture or packaging materially:

• compiled plugin vs script-node request
• single-target vs multi-target release expectations
• internal-only plugin vs public Yak or Package Manager distribution
• Rhino 7 compatibility vs Rhino 8-only

Otherwise make the safest compiled-plugin assumption and proceed.

Output policy

• Default to actionable implementation or review output, not abstract theory.
• When asked to create code, produce code in the repository's architectural style.
• When asked to review, prioritize bugs, regressions, packaging risks, architecture violations, and missing release requirements.
• When packaging or release is involved, call out the exact files, version sources, and commands that matter.

Reference guide

• Use references/architecture-and-coding.md for layering, component boundaries, naming, and code hygiene.
• Use references/build-release-and-yak.md for debug and release workflow patterns inspired by INDToolsUpdate.
• Use references/official-rhino-yak-notes.md for official Rhino and Yak facts that should override memory.