Run any Skill in Manus with one click

shesha-design-system

Stars3

Forks17

UpdatedJuly 1, 2026 at 09:17

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.

Installation

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.

Run Skill in Manus

Source

shesha-io

shesha-io/shesha-plugins

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Web and Digital Interface DesignersComputer and Mathematical Occupations·SOC 15-1255

File Explorer

21 files

SKILL.md

readonly

name

shesha-design-system

description

Shesha Design System

Overview

Turn an abstract "make it look good / match the design" into concrete Shesha style values. This skill owns how forms look, never what they contain. It reads a brand theme token file and emits the exact props Shesha components expect, in two layers that must BOTH be applied:

App-level Ant Design theme (set once): brand primary, base font family, base radius, semantic colours, neutrals — so the whole portal inherits them. Mechanism: references/app-theme.md. Don't repaint every button per form.
Per-component v7 style blocks (per form): surfaces, cards, section headers, density, status chips, header bands, rails — the structural/visual treatment the global theme can't express. Recipes: references/component-recipes.md.

A form looks "cheap" when only one layer is done (AntD still default-blue, or no surface treatment). Apply both.

When to use / not

Use for visual goals: match a design, apply branding, raise polish, fix "doesn't look good", restyle a working form.
Don't use to add fields, wire buttons/CRUD, resolve modelType, or debug runtime errors (→ shesha-form-edit); or to choose the layout (→ shesha-design-comprehension).

Steps

Pick the theme — default vs custom brand. Theme token files live in one folder: plugins/shesha-developer/skills/shesha-design-system/assets/themes/<brand>.tokens.json. Choose which brand applies:
- No brand named, or a generic Shesha app → use the shipped default shesha (shesha.tokens.json): Cobalt #003BB2 interactive anchor, Navy #000E8E sidebar/header chrome, system-ui type, Nero #181818 ink, white cards on Athens Grey #F8F8F9 canvas, radii 2/4/6/8, borders-not-shadows, five operational status tones, and a ready-to-apply $antdTheme ConfigProvider block. This is the fallback whenever the user does not specify a brand.
- User names a brand / hands you brand tokens / an app-specific <brand>.tokens.json already exists → use that brand. The shipped example of a custom brand is requirements-studio (LandBank green #0d685a, Inter, white cards on #f0f2f5 canvas, radii 4/6/12, RsStatus lifecycle Draft→Confirmed→InBuild→Delivered→Rejected→OnHold).
- A design introduces a genuinely new brand → author it in that same assets/themes/ folder: copy the default shesha.tokens.json → <brand>.tokens.json, swap the values (palette / type / spacing / radius / shadow / statusLifecycle / roles, and the $antdTheme block), but keep every key name identical so all recipes, block-overlays and roles.* resolve unchanged. Then treat the new file as the active brand.
Load the chosen file with Read; resolve roles.* (role → token path) before authoring.
Apply the app-level theme (once per project). Set brand primary, font, base radius so the portal inherits them. app-theme.md. Skip only for a one-off tweak where the app theme is already correct; never skip when the complaint is "buttons/links are the wrong colour".
Apply per-component v7 blocks. For each component the design touches, copy the matching recipe from component-recipes.md and fill it with the theme's resolved values; map token→exact prop via token-to-prop-mapping.md. Mirror the block across desktop/tablet/mobile unless the design is genuinely responsive.
Audit (optional). Given a screenshot + the theme, return prop-level fixes (component, prop path, current vs target, one-line reason), ordered by impact. Suggestions, not blockers. Grading rubric: references/appearance-quality.md (the appearance companion to shesha-form-edit's construction form-quality.md — never override a construction guardrail).

General Shesha conventions every recipe respects (light-mode; scale-by-surface type with a 14px dense default; weight-by-role 400/500/600; surface elevation = hairline + subtle card shadow; splits are flex rows sized via dimensions.width, never columns; sentence-case labels; semantic-colour-for-status-only): references/shesha-design-standards.md.

Shesha-specific gotchas

stylingBox is a JSON string (padding/margin keys only). Text components take fontSize (Tailwind class) + fontWeight as direct props. Per-side borders need borderType: "custom". A card surface is a white container with a white background. Brand primary on buttons comes from the app theme — don't override per-button. Code-carrying props are objects { "_mode": "code", "_code": "…" }.

Mechanics & capability (this skill owns the v7 style system)

v7 style-block shapes (border / background / font / dimensions / shadow / stylingBox, per desktop/tablet/mobile), the 5-channel precedence (including the legacy style JS-string footgun that overrides everything), and where each channel lands in the DOM: styling-v7-mechanics.md + style-channels.md. (These moved here from shesha-form-edit — appearance is this skill's job.)
Capability matrix — which channel actually RENDERS per component, measured live and version-stamped: capability-matrix.md. Never author a style on a channel the matrix marks no-op.
Sizing flex-split children: use desktop.dimensions.width (calc / % / px) — it reaches the container's OUTER div. Per-child customStyle:{flex:…} is inert for outer sizing (it lands on the inner div). A flex container MUST set display:"flex" or flexDirection is ignored. Splits are flex container rows, never the columns component (firm project rule).

Non-negotiables

No custom CSS/React/HTML — everything is component props on Shesha JSON.
Tokens live in theme files, never inline hexes.
Style, don't restructure — if the structure is wrong, route back to shesha-form-edit (and the layout is owned by shesha-design-comprehension); never move containers here.
Mirror style blocks across breakpoints; verify against the running app (mechanics are version-dependent).
This skill produces styled JSON/edits; it does not own auth/push/publish — shesha-form-edit does.

Relationship to the other skills

Concern	Skill
Ingest design, plan, orchestrate, verify	`shesha-developer:shesha-claude-designer`
Comprehend design → measured layout blueprint + placement verification	`shesha-developer:shesha-design-comprehension`
Build structure, CRUD, validate, push	`shesha-developer:shesha-form-edit`
Map tokens → app theme + per-component v7 style blocks	this skill

More from this repository

same repository

shesha-claude-designer

shesha-io/shesha-plugins

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.

2026-07-013

domain-model

shesha-io/shesha-plugins

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.

2026-06-303

shesha-design-comprehension

shesha-io/shesha-plugins

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).

2026-06-303

shesha-form-edit

shesha-io/shesha-plugins

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.

2026-06-303

shesha-project-setup

shesha-io/shesha-plugins

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.

2026-06-223

clean-form-config

shesha-io/shesha-plugins

Analyzes a Shesha form configuration JSON and removes dead/obsolete component properties, strips console.log calls from JS code strings, validates property value types, validates the shape of dropdown values items, detects scripts referencing component labels instead of propertyNames, runs layout validations (container dimension overflow, labelCol+wrapperCol span checks, device-specific style path conflicts), validates JavaScript syntax of embedded code strings, auto-fixes API calls missing try-catch by wrapping the function body in try/catch, and auto-fixes API calls in async-context properties that are missing async/await by adding the async keyword and awaiting calls. Falls back to manual review when function structure is ambiguous. Also detects API calls using .then() chaining and flags them for conversion to async/await + try-catch. Use when a form has been migrated, components have been refactored, or you want to clean up stale properties and debug statements.

2026-06-183

name

shesha-design-system

description

Shesha Design System

Overview

App-level Ant Design theme (set once): brand primary, base font family, base radius, semantic colours, neutrals — so the whole portal inherits them. Mechanism: references/app-theme.md. Don't repaint every button per form.
Per-component v7 style blocks (per form): surfaces, cards, section headers, density, status chips, header bands, rails — the structural/visual treatment the global theme can't express. Recipes: references/component-recipes.md.

A form looks "cheap" when only one layer is done (AntD still default-blue, or no surface treatment). Apply both.

When to use / not

Use for visual goals: match a design, apply branding, raise polish, fix "doesn't look good", restyle a working form.
Don't use to add fields, wire buttons/CRUD, resolve modelType, or debug runtime errors (→ shesha-form-edit); or to choose the layout (→ shesha-design-comprehension).

Steps

Pick the theme — default vs custom brand. Theme token files live in one folder: plugins/shesha-developer/skills/shesha-design-system/assets/themes/<brand>.tokens.json. Choose which brand applies:
- No brand named, or a generic Shesha app → use the shipped default shesha (shesha.tokens.json): Cobalt #003BB2 interactive anchor, Navy #000E8E sidebar/header chrome, system-ui type, Nero #181818 ink, white cards on Athens Grey #F8F8F9 canvas, radii 2/4/6/8, borders-not-shadows, five operational status tones, and a ready-to-apply $antdTheme ConfigProvider block. This is the fallback whenever the user does not specify a brand.
- User names a brand / hands you brand tokens / an app-specific <brand>.tokens.json already exists → use that brand. The shipped example of a custom brand is requirements-studio (LandBank green #0d685a, Inter, white cards on #f0f2f5 canvas, radii 4/6/12, RsStatus lifecycle Draft→Confirmed→InBuild→Delivered→Rejected→OnHold).
- A design introduces a genuinely new brand → author it in that same assets/themes/ folder: copy the default shesha.tokens.json → <brand>.tokens.json, swap the values (palette / type / spacing / radius / shadow / statusLifecycle / roles, and the $antdTheme block), but keep every key name identical so all recipes, block-overlays and roles.* resolve unchanged. Then treat the new file as the active brand.
Load the chosen file with Read; resolve roles.* (role → token path) before authoring.
Apply the app-level theme (once per project). Set brand primary, font, base radius so the portal inherits them. app-theme.md. Skip only for a one-off tweak where the app theme is already correct; never skip when the complaint is "buttons/links are the wrong colour".
Apply per-component v7 blocks. For each component the design touches, copy the matching recipe from component-recipes.md and fill it with the theme's resolved values; map token→exact prop via token-to-prop-mapping.md. Mirror the block across desktop/tablet/mobile unless the design is genuinely responsive.
Audit (optional). Given a screenshot + the theme, return prop-level fixes (component, prop path, current vs target, one-line reason), ordered by impact. Suggestions, not blockers. Grading rubric: references/appearance-quality.md (the appearance companion to shesha-form-edit's construction form-quality.md — never override a construction guardrail).

Shesha-specific gotchas

stylingBox is a JSON string (padding/margin keys only). Text components take fontSize (Tailwind class) + fontWeight as direct props. Per-side borders need borderType: "custom". A card surface is a white container with a white background. Brand primary on buttons comes from the app theme — don't override per-button. Code-carrying props are objects { "_mode": "code", "_code": "…" }.

Mechanics & capability (this skill owns the v7 style system)

v7 style-block shapes (border / background / font / dimensions / shadow / stylingBox, per desktop/tablet/mobile), the 5-channel precedence (including the legacy style JS-string footgun that overrides everything), and where each channel lands in the DOM: styling-v7-mechanics.md + style-channels.md. (These moved here from shesha-form-edit — appearance is this skill's job.)
Capability matrix — which channel actually RENDERS per component, measured live and version-stamped: capability-matrix.md. Never author a style on a channel the matrix marks no-op.
Sizing flex-split children: use desktop.dimensions.width (calc / % / px) — it reaches the container's OUTER div. Per-child customStyle:{flex:…} is inert for outer sizing (it lands on the inner div). A flex container MUST set display:"flex" or flexDirection is ignored. Splits are flex container rows, never the columns component (firm project rule).

Non-negotiables

No custom CSS/React/HTML — everything is component props on Shesha JSON.
Tokens live in theme files, never inline hexes.
Style, don't restructure — if the structure is wrong, route back to shesha-form-edit (and the layout is owned by shesha-design-comprehension); never move containers here.
Mirror style blocks across breakpoints; verify against the running app (mechanics are version-dependent).
This skill produces styled JSON/edits; it does not own auth/push/publish — shesha-form-edit does.

Relationship to the other skills

Concern	Skill
Ingest design, plan, orchestrate, verify	`shesha-developer:shesha-claude-designer`
Comprehend design → measured layout blueprint + placement verification	`shesha-developer:shesha-design-comprehension`
Build structure, CRUD, validate, push	`shesha-developer:shesha-form-edit`
Map tokens → app theme + per-component v7 style blocks	this skill