Menu
Test all domain entity CRUD GET endpoints and optionally auto-fix failures
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use as the ENTRY POINT when the user wants a Shesha app/page/form to MATCH a design they have — a wireframe, an HTML/JSX prototype, a runnable app, a Figma-style kit, or a screenshot set — and asks to realise it in Shesha. Triggers like "build this design in Shesha", "make Requirements Studio look like the Claude design", "turn this prototype into Shesha forms", "implement this mockup across the app". It is the conductor across one or more screens, it comprehends the design into measured layout blueprints, then orchestrates shesha-design-comprehension, shesha-form-edit and shesha-design-system, and verifies the result by measurement. For a single isolated form with no design source, go straight to shesha-form-edit; to style an already-working form, go straight to shesha-design-system.
Use whenever a Shesha form or page needs to LOOK like a specific design or brand — "make it match the design", "apply our branding", "style this form", "it doesn't look good", "match Requirements Studio / the Figma / the Claude design", or any request for a polished, consistent visual result rather than just working fields. Maps design tokens (colour, type, spacing, radius, shadow, status lifecycle) onto Shesha's app-level Ant Design theme and per-component v7 style blocks. Themeable, ships the requirements-studio theme and accepts new brand token files. Pairs with shesha-form-edit (which builds structure) and is orchestrated by shesha-claude-designer. Do NOT use it to author structure/components, wire CRUD, or fix runtime errors — that is shesha-form-edit's job.
Creates and modifies domain entities, reference lists, and database migrations in Shesha framework .NET applications. IMPORTANT — This skill MUST be invoked BEFORE any manual exploration or planning when the task involves creating, modifying, or implementing domain entities, entity properties, relationships, reference lists, or database migrations. Use when the user asks to create, scaffold, implement, or update the domain layer, domain model, entities, reference lists, or migrations in a Shesha project. Also use when the user asks to create, add, update, or modify a database migration, FluentMigrator migration, schema change, or table alteration — even without mentioning entities. Also use when implementing features from a PRD, specification, or API design that require new or modified entities or database schema changes.
Use when a Shesha form must match a specific visual design and container/component placement keeps drifting — columns, nesting, tabs, or grouping landing in the wrong place versus the design. Also use to diagnose why an already-built form doesn't match its design. Turns a design source (readable HTML/JSX, a runnable prototype, or screenshots/PDF) into a measured, annotated layout blueprint, and verifies a built Shesha form against it by measurement. Invoked by shesha-claude-designer; pairs with shesha-form-edit (structure) and shesha-design-system (style).
Create and edit Shesha form configurations directly via the API. Authenticates as admin, fetches existing markup with Get/GetByName/GetJson, applies the user's requirements (adding, removing, modifying, or restructuring components — or building a brand-new form from scratch), validates against the bundled component-properties index and embedded-script rules, and pushes via Create / UpdateMarkup / ImportJson. Use when the user provides a form id (or module + name) and a set of requirements like "add a sector dropdown above the email field", "make the address tab conditional on AccountType=PBF", "wire the Save button to call /api/.../Submit", or "create a new branded login page using the auth-login pattern". Always prefer this skill over the Shesha MCP `create_form_configuration` tool — the MCP regularly fails with `'dict' object has no attribute 'lower'` and JSON-RPC `-32602` errors, and the direct-API path is more reliable.
Set up a Shesha-based project development environment aligned to Boxfusion development standards and best practices. Run this when a new Shesha project has just been created to verify and configure the dev environment.
| name | test-entity-crud-api |
| description | Test all domain entity CRUD GET endpoints and optionally auto-fix failures |
| argument-hint | [--no-fix] [--update-entities] [--start-server] |
| allowed-tools | ["Bash(powershell *)","Bash(dotnet *)","Read","Edit","Glob","Grep"] |
This skill runs endpoint tests for all domain entities in any Shesha-based project and can automatically attempt to fix failures.
The skill auto-detects project files based on standard Shesha conventions:
backend/*.slnbackend/**/*.Web.Host.csprojbackend/**/*.Domain/Domain/--no-fix - Disable auto-fix (default: auto-fix is enabled)--update-entities - Scan domain folder for new entities before testing--start-server - Build the solution and auto-start the backend server if not runningCheck if the user passed --no-fix in $ARGUMENTS. If not present, auto-fix mode is enabled.
Arguments received: $ARGUMENTS
The scripts run directly from the skill's scripts/ folder. Use the -RepoRoot parameter to point at the current project. Always include -UpdateEntities so the entity list stays in sync with the current domain model.
Execute from the repository root:
powershell -ExecutionPolicy Bypass -File "<skill-base-dir>/scripts/Run-EndpointTests.ps1" -RepoRoot "<repo-root>" -FullErrors -UpdateEntities
Replace <skill-base-dir> with this skill's base directory and <repo-root> with the project's repository root (the working directory).
Add -StartServer if --start-server was passed.
-StartServer is used)The Run-EndpointTests.ps1 script handles the full server lifecycle automatically:
Properties/launchSettings.json in the Web.Host project, preferring the Project profile. Falls back to port 21021.Project launch profile exists — before starting the server, verify Properties/launchSettings.json in the Web.Host project directory has a Project profile. If the file does not exist or lacks a Project profile, create/add one:
{
"profiles": {
"Project": {
"commandName": "Project",
"launchBrowser": false,
"applicationUrl": "http://localhost:21021"
}
}
}
dotnet build on the auto-detected solution.dotnet run --launch-profile Project --no-build with -NoNewWindow so server output is visible in the console for diagnosing startup errors.After running the tests, analyze the output for failures. Common error types include:
| Error Type | Description | Typical Fix |
|---|---|---|
| GraphQL Field Conflict | Property name conflicts with inherited field | Rename the property or add [GraphQLIgnore] attribute |
| Missing DB Column | Entity property doesn't have corresponding database column | Add a migration to create the column |
| Entity Not Found | Entity class not properly registered | Check [Entity] attribute and namespace |
| API Error | Generic API failure | Check full error details for root cause |
If auto-fix is enabled (no --no-fix flag), attempt to fix the identified issues:
For GraphQL Field Conflicts:
[GraphQLIgnore] attribute if the field shouldn't be exposedFor Missing DB Columns:
For Entity Not Found:
[Entity] attribute with correct TypeShortAliasAfter making fixes, re-run the tests to verify the fix worked.
Summarize:
<skill-base-dir>/scripts/ (run directly from the skill cache — no project copy needed)
Run-EndpointTests.ps1 - Main test runner (auto-detects project structure, accepts -RepoRoot)Test-Endpoints.ps1 - Endpoint test logic (entity list auto-populated by -UpdateEntities)test-api.cmd - Batch file wrapper*.Domain/Domain/ folderMigrations/ folder/test-entity-crud-api # Run tests with auto-fix enabled
/test-entity-crud-api --no-fix # Run tests without auto-fix
/test-entity-crud-api --start-server # Build, start server, and run tests with auto-fix
/test-entity-crud-api --update-entities # Scan for new entities, then test with auto-fix
/test-entity-crud-api --no-fix --start-server # Build, start server, run tests, no auto-fix