mcpField
J
jigx

jigx

github.com/jigx-comDevelopment049 installsUpdated 6w ago
Repository

About jigx

A coding skill for developers changing Jigx apps with the Core SDK. It maps app tasks to focused reference files and emphasizes local-first data handling, generated-code inspection, and runtime verification.

Key features

  1. 01Find task-specific SDK references
  2. 02Preserve local-first save behavior
  3. 03Keep YAML and TypeScript aligned
  4. 04Verify app journeys before publishing
  5. 05Avoid hardcoded credentials

Use cases

  1. 01Implement a datasource or form change
  2. 02Build parent-child screen flows
  3. 03Check generated YAML when behavior is unclear
  4. 04Verify a changed submit or sync journey

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jigx-com/skills --skill jigx

After installing, type/jigxin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
app-architecture.md
datasources.md
forms-state-navigation.md
jsonata-validation-formatting.md
media-pdf-javascript.md
recipe-index.md
runtime-verification.md
tabs-sections-lists.md
scripts/
check-runtime.mjs
check-runtime.test.mjs

Details

From the project README

Jigx Core SDK

Use this skill before writing or changing Jigx app code. Read only the reference files needed for the task.

Workflow

  1. Identify the app area being changed: datasource, form, navigation, tab, media, PDF, JavaScript function, validation, or build/deploy.

  2. Read references/recipe-index.md, then the specific reference file for that area.

  3. Preserve local-first behavior: save user work locally first, then trigger remote or generated work from explicit actions.

  4. Use stable local IDs for parent-child flows. Generate the parent ID before opening child screens and pass it through inputs.

  5. Keep generated YAML and TypeScript aligned. If the SDK output is ambiguous, inspect the generated YAML before assuming runtime behavior.

  6. When a new pattern is learned, update the relevant reference before or with the implementation.

  7. For a new solution or changed form/sync/submit journey, read references/runtime-verification.md before implementation. Run its generated checker before publishing and verify the affected target-app journey. Compilation alone does not establish working behavior.

Reference Map

  • references/recipe-index.md - when to read each reference.

  • references/app-architecture.md - project layout, constants, build/deploy order.

  • references/datasources.md - local tables, SQL, JSON extraction, search, refresh.

  • references/forms-state-navigation.md - forms, save actions, dirty state, inputs, parent-child IDs, copy flows.

  • references/tabs-sections-lists.md - tabbed workspaces, sections, list items, swipe actions, header actions, bottom actions.

  • references/media-pdf-javascript.md - media fields, file paths, HTML/PDF generation, scripts, share/regenerate flows.

  • references/jsonata-validation-formatting.md - JSONata, validation, formatting, dropdowns, icons, and field conventions.

  • references/runtime-verification.md - generated checks, device journeys, debug evidence and verification claims.

Guardrails

  • Do not hardcode secrets, tokens, org IDs, or customer-specific credentials.
  • Do not make external API calls from a primary save action unless the app explicitly uses a direct submit flow.
  • Do not blur read refresh and writeback boundaries; offline-capable writes should drain from a visible user action.
  • Do not store device-local file paths as if they are portable across devices.
  • Do not use jig state as a substitute for stable screen inputs when saving parent or child records.
  • Do not assume generated YAML matches intent. Inspect it when behavior is unclear.

Comments

Markdown supported