intent-modelers-integration

Look up install identities and API references for Intent Architect's Domain, Services, Eventing, and UI designers.

23|10|Updated Aug 31, 2017
One-click install
npx skills add https://github.com/IntentArchitect/Intent.Modules --skill intent-modelers-integration-intentarchitect
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: intent-modelers-integration
Source: https://github.com/IntentArchitect/Intent.Modules/tree/main/Tests/ModuleBuilderSkills/.opencode/skills/intent-modelers-integration
Command: npx skills add https://github.com/IntentArchitect/Intent.Modules --skill intent-modelers-integration-intentarchitect

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When wiring an Intent Architect module against one of the built-in Domain, Services, Eventing, or User Interface designers, the NuGet PackageId, Intent module id, API namespace, and assembly name follow inconsistent conventions that cause confusing late failures if mixed up. This Skill provides the verified identities, entry points, element/association/stereotype references, and the exact three-file wiring recipe so the integration compiles and installs correctly. ## Core Features & Use Cases - Identity resolution: Maps each designer's four identities (NuGet PackageId, module id, API namespace, assembly) and flags the deliberate Modules. segment mismatches, including per-extension-module inconsistencies. - Three-file wiring recipe: Shows the verbatim .csproj PackageReference, .imodspec dependency, and metadata-only modules.config install pattern (Install Designer Metadata only). - Per-designer API references: Documents elements, associations, stereotypes, mappings, extension modules, and worked C# snippets for Domain, Services, Eventing, and User Interface designers. - Use Case: You are building a module that generates repositories from domain entities. Use this Skill to confirm the correct Intent.Modules.Modelers.Domain PackageReference, the Intent.Modelers.Domain imodspec dependency, and the metadataManager.Domain(app).GetClassModels() entry point before writing any code. ## Quick Start Ask the assistant to look up the install identity and entry points for the Domain designer so your module can reference ClassModel entities.

Frequently Asked Questions about intent-modelers-integration

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reference the Intent Domain designer from my module?▼

Add a PackageReference to Intent.Modules.Modelers.Domain in your .csproj, declare a dependency on Intent.Modelers.Domain in your .imodspec, and install the module metadata-only so modules.config records it. Access elements via metadataManager.Domain(application).GetClassModels().

What is the difference between Intent.Modules.Modelers.Domain and Intent.Modelers.Domain?▼

Intent.Modules.Modelers.Domain is the NuGet PackageId used in .csproj, while Intent.Modelers.Domain is the Intent module id used in .imodspec and modules.config. Mixing them up fails at install time rather than compile time, making the mistake surface late.

How do I install a designer module without pulling in its generated output?▼

In the Installation Settings dialog tick only Install Designer Metadata and leave factory extensions, application settings, and template outputs clear. This produces includeAssets="none" in modules.config, giving your Module Builder package design-time visibility of the element types only.

Does the Services designer define its own stereotypes like HttpSettings?▼

No, Services defines zero stereotypes of its own. Stereotypes such as HttpSettings and Secured come from separate Intent.Metadata.WebApi and Intent.Metadata.Security modules that must be installed and referenced independently with their own identities.

Why does my Eventing code not compile with MessagePublishAssociationModel?▼

The Eventing module's association classes are literally named MessagePublishAssocationModel and MessageSubscribeAssocationModel with the misspelling built in. The correctly spelled class does not exist, so code must use the misspelled names verbatim.

When should I not use this Skill?▼

Do not use it for reading stereotypes off a model you already hold, which belongs to metadata-consumer workflows, or for authoring the C# file-builder statements themselves. It only covers wiring a module against the four built-in designers.