Agent Skill

An agent skill is a set of instructions your coding assistant loads when it recognises the task. The ng-forge skill teaches an assistant how to write FormConfig objects, and tells it to check its own work with a real validator.

It is plain markdown. No process runs, no port opens, and nothing needs approval beyond letting files into the repository. That makes it the route for teams who cannot run an MCP server, whether because security review has not cleared it, the IDE is locked down, or the policy is simply no.

Install

Two skills: the core one, and one for the UI adapter your project uses.

npx skills add ng-forge/ng-forge --skill ng-forge-dynamic-forms
npx skills add ng-forge/ng-forge --skill ng-forge-dynamic-forms-material

Swap material for bootstrap, primeng or ionic. The split follows the packages you already depend on: field types, validation and the authoring rules are identical across adapters and live in the core skill, while each adapter skill carries only the props that adapter adds. Installing all four would describe three sets of properties your project does not have.

The installer supports Claude Code, Cursor, Codex, OpenCode and others, and can install per project or globally. There is no registry involved: it reads this repository directly over git.

If you would rather not use the installer, copy skills/dynamic-forms/ and skills/dynamic-forms-<adapter>/ out of the repository by hand.

What it contains

SKILL.md is deliberately short. The detail sits in reference files the assistant reads only when it needs them.

All of it is generated from the same registries that back the MCP server, so the two cannot drift apart. Every configuration in patterns.md is checked against the real schema by the test suite.

The validation loop

An assistant's confidence in its own output is not evidence. The skill's central instruction is to run a validator, which ships as a command:

npx --yes @ng-forge/dynamic-forms-cli@next "src/**/*.form.ts" --ui material

Requires Node 24 or newer. --yes keeps npx from pausing on its first-install prompt, which matters when an agent runs the command. @next is where the executable is published; latest still points at a placeholder release that ships no binary.

It finds every FormConfig in the matched files, validates it against the schema for your adapter, and reports the exact property that is wrong along with the fix. This is the same validation the MCP server performs, because both call the same package.

# Validation Report

**File:** src/app/checkout/checkout.form.ts
**UI Integration:** material

## Found 1 FormConfig(s)

### 2 Error(s) Found

#### checkoutForm (line 8): Invalid

- **fields[3].props.options:** "options" MUST be at FIELD level, NOT inside props!
  - **Fix:** Move `options` from `props: { options: [...] }` to field level: `{ key, type, options: [...] }`
- **fields[7].value:** Hidden field "token" is MISSING REQUIRED "value" property.
  - **Fix:** Hidden fields REQUIRE a `value` property. Add: `value: "your-value-here"`

Options

Exit codes

Code 2 is separate from 1 so a typo in a glob does not read as a passing run.

One case to know about before relying on this as a gate: if files match but none of them contains a FormConfig the extractor recognises, the command reports that on stderr and still exits 0. Pass --require-config to make that a failure, which is what the CI snippet below does. Without it, a refactor that moves configs somewhere the extractor cannot see them turns the gate quiet rather than red.

- name: Validate form configs
  run: npx --yes @ng-forge/dynamic-forms-cli@next "src/**/*.form.ts" --ui material --quiet --require-config

What the compiler already covers

For configs written in TypeScript, as const satisfies FormConfig plus a typecheck catches a large share of mistakes before any of this runs. Use both.

The CLI exists for what the compiler cannot see: structural rules such as containers accepting only hidden logic, hidden fields requiring a value, and configs that are not TypeScript at all.

What it does not currently catch is a property nobody declared. The schemas pass unknown keys through, so an invented field option, or a validator whose value is the wrong type, is reported as valid. That matters most for AI-generated configs, where inventing a plausible-looking property is a common failure. Treat a clean run as "the structure is right", not as "every key here exists".

Configs that arrive at runtime

If your forms come from an API or a CMS, neither the compiler nor the CLI can reach them. Validate them where they land:

import { validateFormConfig } from '@ng-forge/dynamic-forms-cli/validate';

const result = validateFormConfig('material', configFromApi);

if (!result.valid) {
  console.error(result.errorSummary);
}

The same package generates JSON Schema, which is useful for constraining an LLM's structured output to configs that will actually render:

import { getFormConfigJsonSchema } from '@ng-forge/dynamic-forms-cli/validate';

const schema = getFormConfigJsonSchema('material');

Reading the docs directly

The whole documentation site is published in a form assistants can read without any integration:

Compared to the MCP server

The skill loses interactive lookup: the assistant reads whole reference files rather than querying for one topic. In exchange it needs no server, works across assistants, and its validation runs in CI.

Versioning

npx skills add installs a snapshot, and nothing links it to the version of ng-forge you have installed. The skill states which version it documents and tells the assistant to check the installed version first, so a mismatch surfaces as a warning rather than as confidently wrong output. Re-run the install command after upgrading.