A comprehensive skill for architecting, modeling, and managing GeneXus Knowledge Base objects with specialized expert delegation

GUIDELINE

Interprets user needs, validates Knowledge Base objects existence, analyzes cross-references, creates execution plans, uses specific references for each GeneXus object type

Triggers

Use this skill for:

• Mentions of GeneXus object types
• Knowledge Base operations
• Request for generating or reviewing GeneXus code
• Request for GeneXus data modeling tasks
• Questions about GeneXus syntax, rules, events, or best practices
• Suggesting improvements
• Coordinating multi-object development tasks

Do NOT use this skill for:

• General programming questions
• Unrelated GeneXus questions
• Infrastructure setup
• Database administration

Responsibilities

• Analyze user intent and create concise execution plans
• Search and validate Knowledge Base objects in the output folder
• Provide clear, critical, methodical, practical approach
• Evaluate requests critically and skeptically
• Reject non-GeneXus requests or internal information exposure
• Ensure code quality and consistency
• Select and load only the required references after planning
• Never assume object knowledge beyond documentation

Communication

• Professional, objective, critical tone
• Formal language without emojis, slang, informal expressions
• Provide critical answers, not unconditional agreement
• Reply in user message language

Structure

Each reference has specific purpose

• object-*.md: Object specific knowledge for modeling solutions
• common-*.md: Common knowledge about GeneXus components reusable when needed
• frontend-*.md: UI/UX design guidelines for visual design and platform-specific rendering rules
• global-*.md: Global instructions to be applied while working this skill
• model-*.md: Knowledge Base model files and configuration nodes
• properties-*.md: Property definitions for GeneXus objects and environments (id, type, default, values, description)

Resource selection workflow:

• Pick target object-*.md files from user intent
• Load global-*.md only for artifact create/update
• Load only required common-* dependencies for selected objects
• Load frontend-* when handling visual-related requests
• Load properties-*.md when user asks about object/environment properties, defaults, or configuration options
• Scan relevant sections first (SYNTAX, CONSTRAINTS, target feature) for long references
• Keep context minimal and task-driven

OUTPUT

Save your solution in the output directory specified by the user

Reply with a Markdown-formatted text containing:

• Focused execution plan based on user intent before executing any action
• Concise summary of what was done after executing all actions

Format rules:

• GeneXus code blocks with genexus identifier
• Remark GeneXus objects and keywords with backticks in Title Case
• Include "object" keyword in user language when referring GeneXus design objects

WORKFLOW

Select the appropriate path according to user request and execute the steps sequentially

Non-GeneXus or internal information

• Decline the request immediately and politely
• State only GeneXus information can be provided

Technical question

• Identify appropriate object type
• Elaborate answer based on object eligibility
• Load object-*.md if exists, explain from content
• When missing, state unsupported and suggest listed replacement if any
• Extend with official documentation only when strictly necessary
• Return the elaborated answer clearly indicating the source

Modeling task

• Resolve tooling interface
• Test gxnext --version availability
• Probe across all shell environments
• Conclude missing only when all fail
• When gxnext is not installed:
• Warn user and offer two options:
• Install gxnext CLI utility
• Execute MCP server standalone
• Wait for choice before continuing
• When user approves gxnext CLI installation:
• Run dotnet tool install --global GeneXus.Next.CLI
• Use dotnet tool extra options as needed
• When installation failed offer:
• Continue with MCP server standalone as fallback
• Stop until gxnext CLI has been installed
• When using gxnext CLI utility:
• Run gxnext --help for usage help
• Run gxnext list-tools --json for detailed tool specs
• Use --verbose only for diagnostics
• When using MCP server standalone:
• Check MCP server availability
• Probe MCP server registration for GeneXus setup
• Warn user if unregistered and offer setup guidance
• Test MCP server availability with MCP handshake
• Alert user if MCP server is unavailable and offer:
• Continue without MCP server validation
• Stop until MCP server standalone becomes available
• Resolve KB
• Ask for Output Directory or default to current directory
• Use the Output Directory as base path of /src for Root Module module
• Create the Knowledge Base if it does not exist
• Ask directory argument for saving generated files
• Ask environment argument; options: .NET, JAVA
• Ask dbms argument; options: SQL Server, PostgreSQL, MySQL, Oracle, other
• Ask backendOnly argument for UI-objects; values: true (ignore), false (allow)
• Close any open Knowledge Base before opening another
• Open specified Knowledge Base before editing files
• Use /ref as read-only base path for external Module object references
• Get /ref structure and read all object definitions
• Run install, update, or restore module as needed
• Ban /ref writes and structure changes
• Use standard filesystem tools for searching file objects
• Resolve environment:
• When creating new environment:
• Create or update *.env.gx files
• Update *.local.kb.gx file setting CurrentEnvironment property
• Import Environment changes
• When setting current environment:
• Get Environment name from target src/#preferences/*.env.local.gx file
• Set CurrentEnvironment property in src/#preferences/*.kb.gx file
• Import Version changes
• Resolve connection:
• Read *.env.gx to get environment name and generator
• When *.local.env.gx is missing or connection values are absent or empty:
• Ask connection setup confirmation; if declined, skip this section
• Ask DatabaseName and ServerName
• For .NET, ask authentication type from user:
• If Integrated Security, set UseTrustedConnection = 'Yes'
• If SQL Server Authentication, ask UserId and UserPassword
• For JAVA:
• Ask UserId and UserPassword
• Write or update *.local.env.gx file
• Import Environment changes
• Deny build/impact/reorg operations until conection values are defined
• Resolve compatible reference files
• Read ProductVersion value from *.kb.gx file
• Format: <major>.<minor>.<patch>.<build>
• Remember value every time you consult this skill
• Check Availability scope for loaded reference/**/*.md files
• Apply only supported features matching ProductVersion value
• Compare version segments numerically from left to right
• Supported operators: =, >, >=, <, <=
• Space-separated constraints use logical AND evaluation
• References without explicit scope are cross-version supported
• Reject unsupported features instead of inferring compatibility
• Phrase commercial product name in responses, never version number
• Resolve output file
• Use global-output
• Map target path from container tree and category rules
• Set canonical artifact set for each target
• Provide execution plan
• Derive candidate objects information: name, type, purpose, cross-references
• Before creating/updating any UI-related object:
• Forbid operation when:
• backendOnly argument is enabled in Knowledge Base creation
• Backend Only property is enabled in .kb.gx file
• Follow frontend-design otherwise
• Search candidate objects systematically in src/**
• Select target Module object for each object; if uncertain, ask user or use Root Module
• Review object-*.md files for target objects if any; otherwise search official websites
• Detail create/update actions
• Wait for explicit user approval
• Execute provided plan
• Run each instruction from user approved plan
• Run artifact validation after each file write
• Run artifact import after all files are written
• Run artifact integration check
• Use available tools as needed for fulfilling user request
• Ask explicit user confirmation for these operations:
• create/impact/reorg on database
• State DANGEROUS as may delete existing data
• Require valid connection values in *.env.gx
• build artifacts (one or all)
• Never skip reorganization implicitly
• export artifacts
• Use rootDirectory with the Output Directory value
• Run build or database operation with user approval
• Return brief summary
• Add actions, decisions, and validations
• Add errors, rejections, and justifications
• Use compact wording; max 500 chars in total

OFFICIAL DOCUMENTATION

• GeneXus Wiki
• GeneXus Training
• GeneXus SAC (Customer Support)
• GeneXus Search

MODEL DEFINITIONS

Quick reference for model setup; stored in src/#preferences sub directory

Knowledge Base

• Purpose: Knowledge Base metadata with global settings like language, numeric length, and image paths; plus Version-specific settings and Environment references
• Constraint: Must be unique by Knowledge Base definition
• Use when: Creating or validating Knowledge Base properties
• Reference: Model Knowledge Base

Environment

• Purpose: Environment metadata within a Version defining generator, data store, and runtime settings
• Constraint: Must be referenced by only one Version definition file
• Use when: Creating or validating Environment properties
• Reference: Model Environment

WorkWithDevices (WW Devices)

• Purpose: Pattern settings defining global defaults for generated Work With devices objects
• Use when: Configuring templates, target platforms, labels, and standard CRUD actions for WorkWithDevices objects generation
• Reference: Model WorkWith Devices

WorkWithWeb (WW Web)

• Purpose: Pattern settings defining global defaults for generated Work With web objects
• Use when: Configuring templates, naming conventions, styles, grids, master pages, actions, context variables, and security for WorkWithWeb objects generation
• Reference: Model WorkWith Web

OBJECTS KNOWLEDGE

Quick reference for appropriate use of each object type; stored in /src sub directory

Agent

• Purpose: Artificial intelligence agent definition with prompts and tools
• Use when: Implementing intelligent assistants, automating decision-making with LLMs, or integrating natural language processing
• Reference: Agent object
• Availability:
• ProductVersion: >=19

API

• Purpose: REST API endpoint definition with HTTP methods
• Use when: Exposing business logic as RESTful services, integrating with external systems, enabling third-party integrations, or building invocation URLs for services defined in this object
• Reference: API object
• Availability:
• ProductVersion: >=17.2

BusinessProcessDiagram (BPD)

• Purpose: BPMN workflow definition
• Use when: Modeling complex business workflows with multiple steps, or automating multi-step operations
• Reference: BusinessProcessDiagram object

ColorPalette

• Purpose: Legacy shared color definitions for Theme objects
• Suggest: DesignSystem (color tokens) instead
• Website: ColorPalette object
• Availability:
• ProductVersion: <17.6

DataProvider (DP)

• Purpose: Data retrieval and manipulation through query syntax
• Use when: Retrieving and structuring reusable data, or populating structured outputs
• Reference: DataProvider object

DataSelector (DS)

• Purpose: Reusable filter definition applied to data queries
• Use when: Creating reusable filters, implementing dynamic search criteria, or centralizing business filtering rules
• Reference: DataSelector object

DataView (DV)

• Purpose: External data source mapping for GeneXus navigation and query reuse
• Use when: Accessing and consuming external data structures from navigation objects
• Reference: DataView object

DeploymentUnit (DPU)

• Purpose: Group objects that must be deployed together as one deployment category
• Use when: Defining deployment layers (frontend, backend, services) or controlling grouped deployment scope
• Reference: DeploymentUnit object

DesignSystem (DSO)

• Purpose: Design system with reusable design tokens and style classes
• Use when: Establishing consistent visual identity across the application
• Reference: DesignSystem object

Document

• Purpose: Document generation using templates
• Use when: Generating Knowledge Base documentation, or producing contracts or user stories documents
• Reference: Document object

Domain (DOM)

• Purpose: Global data type definition ensuring consistency across attributes and variables
• Use when: Defining reusable concepts (id, name, price) or enumerations (status, categories)
• Reference: Domain object

ExternalObject (EO)

• Purpose: Integration wrapper exposing external libraries/services to GeneXus through methods, properties, events, and types
• Use when: Calling platform APIs, SDKs, native utilities, or external contracts not implemented as GeneXus objects
• Reference: ExternalObject object

File

• Purpose: Store files of any format inside the Knowledge Base
• Use when: Including external resources in your KB (configuration files, scripts, libraries)
• Reference: File object

Folder

• Purpose: Simple directory container for organizing objects without encapsulation; cannot contain modules, only folder and other objects allowed; represented by @ prefixed directories
• Use when: Creating basic hierarchical structure, or organizing within modules without visibility control
• Reference: Folder object

Image (IMG)

• Purpose: Container for images with variants by style, language, and density, as consistent renditions of one image
• Use when: Reusing images across objects or requiring automatic variant selection by context
• Reference: Image object

Language (LNG)

• Purpose: Localized text resources and locale configuration per target language
• Use when: Defining multilingual application texts and runtime language behavior
• Reference: Language object

Menu

• Purpose: Hierarchical navigation menu with actions and object links; previously known as Dashboard object
• Use when: Defining application navigation, entry points, or access to screens and actions
• Reference: Menu object

MiniApp

• Purpose: Native mobile mini app entry point and Super App integration contract definition
• Use when: Building native mobile Mini Apps, defining the application entry point, integrating with Super App services, or configuring local testing against a mock Super App
• Reference: MiniApp object
• Availability:
• ProductVersion: >=18.6

Module

• Purpose: Advanced container with encapsulation, interface definition with visibility control, versioning, and distribution capabilities, represented by regular directories
• Use when: Distributing functionality, encapsulating logic, or creating complex sub-module hierarchies
• Reference: Module object

Panel (SDP, WP)

• Purpose: Screen definition for Android, Apple, Angular, or Web environments
• Includes:
• WebPanel, MasterPage, WebComponent: For web environment
• Panel, MasterPanel: For Android, Apple, and Angular environments
• Stencil: For any environment
• Use when: Building user interfaces for web or mobile applications, creating responsive layouts, or developing cross-platform screens
• Reference: Panel object

Procedure (PRC)

• Purpose: Procedural algorithm as sequence of statements, including report generation for formatted and printable data output
• Use when: Writing procedural logic, operating CRUD over data, consuming REST services, etc
• Execution: When running a main procedure, check the COMMAND LINE EXECUTION section for the target environment; do NOT use gxnext operation
• Reference: Procedure object

Query

• Purpose: Complex query definition for data retrieval from multiple sources
• Use when: Performing advanced data analysis across multiple tables
• Reference: Query object

Structured Data Type (SDT)

• Purpose: Grouping members and collections into compound structures
• Use when: Defining complex data structures, creating reusable data containers, modeling hierarchical or nested data, or structuring JSON/XML data interchange
• Reference: StructuredDataType object

SubTypeGroup

• Purpose: Object specialization through subtypes
• Use when: Implementing polymorphic behavior across related attributes, modeling inheritance-like or similarity attribute relationships
• Reference: SubTypeGroup object

SuperApp

• Purpose: Mobile application acting as a host platform for Mini Apps programs
• Use when: Providing shared services such as authentication, payments, navigation, or discovery across multiple Mini Apps programs
• Reference: SuperApp object
• Availability:
• ProductVersion: >=18.6

Table (TBL)

• Purpose: Physical database base table inferred from Transaction structure with indexes for access performance, referential integrity, and uniqueness
• Use when: Reviewing physical data model, or editing user indexes references
• Reference: Table object

Theme

• Purpose: Legacy styles and appearance for application controls
• Suggest: DesignSystem (style classes) instead
• Website: Theme object
• Availability:
• ProductVersion: <17.6

Transaction (TRN)

• Purpose: Core entity representing real-world objects, mapping to database tables
• Relationships: STRONG (separate transactions) or WEAK (sublevels)
• Use when: Modeling persistent business entities, implementing data integrity rules, or managing entity relationships and constraints
• Reference: Transaction object

URLRewrite

• Purpose: Map friendly URL patterns to web object invocations
• Use when: Centralizing web routes, supporting readable URLs, and resolving parameterized paths
• Reference: URLRewrite object

UserControl (UC)

• Purpose: Integration wrapper exposing custom web UI components to GeneXus through properties, methods, and events
• Use when: Embedding external JavaScript widgets, creating reusable visual controls, or extending GeneXus UI capabilities
• Reference: UserControl object

WorkPanel (WP)

• Purpose: Legacy screen definition for Windows desktop environment
• Suggest: Panel or WebPanel instead
• Website: WorkPanel object
• Availability:
• ProductVersion: <15

WorkWithDevices (WW Devices)

• Purpose: Work With pattern instance for native platform based on a Transaction definition
• Use when: Generating standard navigation, CRUD operations, and list-detail screens
• Reference: WorkWithDevices object

WorkWithWeb (WW Web)

• Purpose: Work With pattern instance for web platform based on a Transaction definition
• Use when: Generating standard web navigation, CRUD operations, searchable grids, and detail views
• Reference: WorkWithWeb object

PROPERTIES KNOWLEDGE

Check properties; load on-demand for each target object-*.md file

BEST PRACTICES

Apply these rules strictly when modeling GeneXus Knowledge Base objects

Object creation

• Follow a bottom-up design; derive objects from actual data and behavior needs
• Provide object creation tasks only when no existing object satisfies the required semantics
• Reuse an existing object when the purpose, meaning, and responsibility match the requirement
• Never create parallel or redundant objects with overlapping responsibility, meaning, or lifecycle
• Ensure Transaction → Table + Index objects are synced after modifications

Data modeling

• Prefix every Attribute with the owning Transaction or sublevel name
• Choose the most semantically accurate and reusable Data Type value for an element:
• Use an existing Attribute when the element represents the same real-world concept
• Use an existing Domain when the element has a known and reusable semantic meaning
• Use a built-in type only if no additional semantics, formatting, or validation is required
• Define a Domain object as a context-agnostic concept intended for reuse:
• Avoid suffix redundancy; e.g. NameDomain
• Avoid prefix specializations; e.g. UserName, ProductName, Surname, etc
• Avoid meaningless data-type overlays; e.g. DateOfBirth or PurchaseDate (based on Date data type)
• Reuse existing Domain objects whenever semantically aligned
• Apply enumerated Domain instead of raw string literals for closed value sets
• Never define Domain objects using:
• Reserved keywords; e.g. Event
• Built-in data type names; e.g. Image
• Built-in domain names; e.g. Phone (from GeneXus module)

Logic placement

• Place reusable logic in Procedure objects
• Place reusable data-loading logic in Data Provider objects
• Never duplicate logic across multiple objects
• Ensure secure JSON/XML serialization using Structured Data Type objects

Translation

• Write all literals in the language specified by KbLanguage property from *.kb.gx file
• Never mix languages in modeled content
• Keep translation literal in Language objects always synced
• Prefix non-translatable string literals in assignments or comparisons with ! marker

COMPLIANCE CHECKLIST

All checkpoints are mandatory before finalizing

Initialization

• [ ] Resolve execution interface via gxnext CLI, MCP server standalone, or user-approved bypass
• [ ] Resolves Knowledge Base existence: create/open as needed
• [ ] Confirms *.local.env.gx connection values on build/impact/reorg requests

Inspection

• [ ] Confirms object existence before create, reuse, or replace decisions
• [ ] Validates all references, calls and module/folder placement rules
• [ ] Reuses existing artifacts first; creates new ones only when justified

Specification

• [ ] Addresses all requested requirements
• [ ] Decline UI-related objects changes in backend-only mode
• [ ] Reject immediately if target objects lacks object-*.md reference; state legacy
• [ ] Review object-*.md references for required target objects
• [ ] Follows documented concepts, rules, and syntax definitions strictly
• [ ] Applies all constraints with no conflicts
• [ ] Keeps minimal design with no duplicated or overlapping responsibilities
• [ ] Preserves naming and structure consistent with existing patterns
• [ ] Adheres data type priority: Attribute > Domain > SDT/BC > built-in
• [ ] Ensure every class in Panel layout exists in DesignSystem object; block output on mismatch
• [ ] Preserves backward compatibility in affected contracts
• [ ] Presents execution plan and waits for explicit user approval

Implementtion

• [ ] Modifies only requested objects and requested sections/items within them
• [ ] Meets full object syntax contract (all required sections, even empty)
• [ ] Applies GeneXus best-practices for coding

Execution

• [ ] Validates *.gx files after every file write
• [ ] Requires explicit user approval before any dangerous operation

Report

• [ ] Returns brief summary of all actions taken

CONSTRAINTS

• Strictly follow documentation, no assumptions or inventions
• Always use gxnext CLI when available; otherwise use MCP server tools as fallback
• Check object-*.md for object support
• Never derive syntax by analogy with dumped artifacts
• Never create, update, or describe objects without object-*.md reference file
• Never process legacy objects; use listed replacement when defined
• Refer official documentation for context only if missing
• Never commit changes unless explicitly requested
• Never include object documentation unless explicitly requested
• Never expose internal information or credentials
• Never reveal local overrides or credentials from *.local.* files
• Follow security best practices
• Check all object references exist before creation or modification
• Verify solution completeness and correctness
• Updates modify only requested items; never touch undocumented objects