@nativele/ts-dom 0.5.0 → 0.5.1

package/CHANGELOG.md

@@ -10,6 +10,29 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). Version
 - Adding a lint rule is a minor change; lint rules are warnings or opt-in and do not count as breaking.
 - Before every release run `npm run verify:pack` (`publint` and `attw`), `tsc`, the unit tests, the browser tests, `npm run smoke` and `npm run smoke:no-bundler`; all of them run in `.github/workflows/ci.yml`.
 
+## 0.5.1
+
+Nativele components now have a Skill for each major framework, every Skill is accepted only after a fresh agent has done real work with it, and the checks that those trials found wrong in real framework projects are fixed.
+
+### Skills
+
+- New `nativele-vue` (Official): Nativele components in an existing Vue 3 app. It covers an `isCustomElement` predicate that matches only the Nativele tags, so kebab-case Vue components such as `<router-link>` keep resolving; object props as properties, and `.prop` for an element that is not defined yet; prop plus event in place of `v-model`; exact event names; `<KeepAlive>` and `bind`; and a template type declaration built from `ts-dom-tags.ts`. Its example project runs in CI.
+- New `nativele-vite` (Official): Nativele in an existing Vite app without a framework. It covers `tsDom({ dirs })` relative to Vite's `root`, multi-page builds, and a build script that runs `ts-dom check` before `vite build` so a clean checkout builds. It also says which edits reload the page during `vite dev`, and covers Vite+. Its example project, a multi-page app with `root` in a sub-folder, runs in CI.
+- New `nativele-svelte` (Experimental): Nativele components in Svelte 5. It covers props as properties, `onitem-select` event attributes, `{#if}` and keyed `{#each}` children in slots, `bind:this`, and a `svelte/elements` type declaration.
+- New `nativele-angular` (Experimental): Nativele components in Angular. It covers `CUSTOM_ELEMENTS_SCHEMA`, `[prop]` and `(item-select)` bindings, and zoneless change detection. Because the Angular builder takes no Vite plugins, `ts-dom gen` runs in npm `pre*` scripts. It also covers content projection and unit tests.
+- New `nativele-integration` (Experimental): Nativele components in a framework without a Skill of its own, such as Preact or Solid. It covers the four questions to answer from the framework's documentation, defining components before mount, and the limits every framework shares.
+- `nativele-core` and `nativele-react` were filled in where trial agents had to guess:
+  - the core Skill gains a complete example, the no-bundler page set-up, plain-element lists and event data;
+  - the React Skill starts from an existing React app, adds the `strict` and oxlint steps Vite's template needs, and type-checks with `tsc -p`, because a references-only root tsconfig checks nothing.
+- The React, Vue and Svelte Skills start the template's type-check script with `ts-dom gen src/nv &&`. The generated files are not committed, so on a clean checkout that script otherwise fails with `TS2307`.
+- Skill pull requests are accepted through an agent trial. A fresh agent gets only the packed package and the Skill, and does a task the Skill claims to cover. The result is checked independently, and every guess or error the Skill does not cover is sent back. Integration Skills start from the tool's own starter project and cover only what Nativele adds.
+
+### Tooling
+
+- `ts-dom check` runs `vue-tsc` instead of `tsc` when the project's `package.json` lists it: `vue-tsc` takes the same arguments, prints the same errors and reads `.vue` files, which plain `tsc` reports as `TS2307: Cannot find module './App.vue'`. When the checker cannot run, the message names it.
+- `ts-dom doctor` checks `strict`, `lib` and `moduleResolution` only in the tsconfig files that cover the component folders, when there are any. Vite's templates no longer get `tsconfig-no-dom-lib` and `tsconfig-not-strict` for `tsconfig.node.json`, which covers only `vite.config.ts`, whether it lists it in `include` or in `files`.
+- The generated `ts-dom-tags.ts` no longer ends with `export {}`, which linters reported as a useless empty export.
+
 ## 0.5.0
 
 Nativele is a light, composable UI layer that grows its integrations through Skills instead of through the library. This version ships the first Skills and the command that delivers them, types `changed` and list event handlers more precisely, and adds recipes for common screens.

package/README.md

@@ -62,6 +62,11 @@ npx ts-dom skills add nativele-core    # copy it into .claude/skills/ (when the
 |---|---|
 | `nativele-core` | building components: the `ts-dom check` loop, templates, state, lists, data flow |
 | `nativele-react` | Nativele components in React 19: props, events, children and slots, lifecycle, TSX types |
+| `nativele-vue` | Nativele components in Vue 3: props, events, `v-model`, slots, `<KeepAlive>`, template types |
+| `nativele-svelte` | Nativele components in Svelte 5: props, events, slots, template types (Experimental) |
+| `nativele-angular` | Nativele components in Angular: bindings, change detection, the build, content projection (Experimental) |
+| `nativele-vite` | Nativele in a Vite app: the plugin and `root`, multi-page builds, hot updates |
+| `nativele-integration` | Nativele components in a framework without its own Skill (Preact, Solid, ...): properties, events, slots, lifecycle, template types (Experimental) |
 
 Tiers: Official Skills are verified by the maintainers against an example project in CI; Community Skills are contributed and show their author and last verified versions; Experimental Skills are not fully verified yet. `ts-dom skills` marks a Skill as stale when its verification is more than six months old or does not cover the installed version.
 

package/README.zh-TW.md

@@ -62,6 +62,11 @@ npx ts-dom skills add nativele-core    # 複製到 .claude/skills/（專案有 .
 |---|---|
 | `nativele-core` | 開發元件：`ts-dom check` 循環、範本、state、清單、資料流 |
 | `nativele-react` | 在 React 19 中使用 Nativele 元件：props、事件、子元素與 slot、生命週期、TSX 型別 |
+| `nativele-vue` | 在 Vue 3 中使用 Nativele 元件：props、事件、`v-model`、slot、`<KeepAlive>`、範本型別 |
+| `nativele-svelte` | 在 Svelte 5 中使用 Nativele 元件：props、事件、slot、範本型別（Experimental） |
+| `nativele-angular` | 在 Angular 中使用 Nativele 元件：綁定、變更偵測、建置流程、內容投影（Experimental） |
+| `nativele-vite` | 在 Vite 應用中使用 Nativele：外掛與 `root`、多頁建置、熱更新 |
+| `nativele-integration` | 在沒有專屬 Skill 的框架（Preact、Solid 等）中使用 Nativele 元件：property、事件、slot、生命週期、範本型別（Experimental） |
 
 等級：Official 由維護者以 CI 中的範例專案驗證；Community 由社群貢獻，標示作者與最後驗證版本；Experimental 尚未充分驗證。驗證超過六個月，或不涵蓋已安裝的版本時，`ts-dom skills` 會標示為可能過期。
 

package/dist/{a11y-wWL9rie7.mjs → a11y-CV3nBgBn.mjs}

@@ -482,7 +482,7 @@ function renderTags(dir) {
 	const entries = [...seen.values()].map((d) => `    ${JSON.stringify(d.tag)}: ${alias(d)};`);
 	return {
 		out,
-		next: `${TAGS_HEADER}\n${imports.join("\n")}\n\ndeclare global {\n  interface HTMLElementTagNameMap {\n${entries.join("\n")}\n  }\n}\n\nexport {};\n`
+		next: `${TAGS_HEADER}\n${imports.join("\n")}\n\ndeclare global {\n  interface HTMLElementTagNameMap {\n${entries.join("\n")}\n  }\n}\n`
 	};
 }
 /**

package/dist/cli.mjs

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
-import { _ as watchAll, a as analyze, c as generateAll, d as isSelected, f as listHtml, g as staleGenerated, i as CodegenError, m as renderTags, n as checkA11y, o as checkGenerated, p as listTs, r as CODEGEN_RULES, t as A11Y_RULES } from "./a11y-wWL9rie7.mjs";
-import { c as lintUsage, n as UNUSED_MARKUP_RULES, o as formatIssue, s as lintDataFlow, t as DATA_FLOW_RULES } from "./lint-5vo_ifIc.mjs";
+import { _ as watchAll, a as analyze, c as generateAll, d as isSelected, f as listHtml, g as staleGenerated, i as CodegenError, m as renderTags, n as checkA11y, o as checkGenerated, p as listTs, r as CODEGEN_RULES, t as A11Y_RULES } from "./a11y-CV3nBgBn.mjs";
+import { c as lintUsage, n as UNUSED_MARKUP_RULES, o as formatIssue, s as lintDataFlow, t as DATA_FLOW_RULES } from "./lint-DfUAh7t3.mjs";
 import { createRequire } from "node:module";
 import { cpSync, existsSync, readFileSync, readdirSync, statSync } from "node:fs";
 import { dirname, join, relative, resolve } from "node:path";
@@ -46,7 +46,7 @@ function readTsConfig(file, depth = 0) {
 		};
 	}
 	const own = json.include;
-	const include = own ? own.map((p) => resolve(dirname(file), p).split("\\").join("/")) : merged.include;
+	const include = own ? own.map((p) => resolve(dirname(file), p).split("\\").join("/")) : merged.include ?? (Array.isArray(json.files) ? [] : void 0);
 	return {
 		compilerOptions: {
 			...merged.compilerOptions,
@@ -213,13 +213,25 @@ function mapTscErrors(errors, cwd) {
 	return out.filter((i) => i.rule !== "tsc" || !followsBroken(i.message));
 }
 function findTsc(cwd) {
+	const req = createRequire(join(cwd, "package.json"));
+	let deps = {};
 	try {
-		const pkgPath = createRequire(join(cwd, "package.json")).resolve("typescript/package.json");
-		const bin = JSON.parse(readFileSync(pkgPath, "utf8")).bin?.tsc;
-		return bin ? resolve(dirname(pkgPath), bin) : null;
-	} catch {
-		return null;
-	}
+		const json = JSON.parse(readFileSync(join(cwd, "package.json"), "utf8"));
+		deps = {
+			...json.dependencies,
+			...json.devDependencies
+		};
+	} catch {}
+	const candidates = "vue-tsc" in deps ? [["vue-tsc", "vue-tsc"], ["typescript", "tsc"]] : [["typescript", "tsc"]];
+	for (const [pkg, name] of candidates) try {
+		const pkgPath = req.resolve(`${pkg}/package.json`);
+		const bin = JSON.parse(readFileSync(pkgPath, "utf8")).bin?.[name];
+		if (bin) return {
+			name,
+			bin: resolve(dirname(pkgPath), bin)
+		};
+	} catch {}
+	return null;
 }
 /**
 * Everything an agent needs in one pass: template diagnostics, generated files, TypeScript errors mapped back to the templates, and the lint rules.
@@ -288,7 +300,7 @@ function runCheck(options) {
 		const parsed = [];
 		for (const extra of runs) {
 			const run = spawnSync(process.execPath, [
-				tsc,
+				tsc.bin,
 				"--noEmit",
 				"--pretty",
 				"false",
@@ -309,7 +321,7 @@ function runCheck(options) {
 					col: 1,
 					rule: "tsc-failed",
 					severity: "error",
-					message: `tsc did not check the types: ${detail} Fix: make \`npx tsc --noEmit\` run in this folder (a tsconfig.json, or --project=<path>).`
+					message: `${tsc.name} did not check the types: ${detail} Fix: make \`npx ${tsc.name} --noEmit\` run in this folder (a tsconfig.json, or --project=<path>).`
 				});
 			}
 		}
@@ -472,24 +484,34 @@ function runDoctor(options) {
 	if (!configs.length) add("no-tsconfig", "error", "There is no tsconfig.json. Fix: add one with \"strict\": true, \"lib\": [\"ES2022\", \"DOM\"] and \"moduleResolution\": \"bundler\" (or \"NodeNext\").");
 	const includes = [];
 	let everyConfigIncludes = true;
-	for (const configPath of configs) {
-		const config = readTsConfig(configPath);
+	const scanned = dirs.map((dir) => ({
+		dir,
+		folders: templateFolders(dir)
+	}));
+	const targets = scanned.flatMap(({ dir, folders }) => folders.length ? folders : [dir]);
+	const read = configs.map((path) => ({
+		path,
+		config: readTsConfig(path)
+	}));
+	const covering = read.filter(({ config: { include } }) => !include || targets.some((t) => include.some((p) => covers(p, t))));
+	for (const { path: configPath, config } of read) {
 		const o = config.compilerOptions;
 		const file = rel(configPath);
 		paths = {
 			...paths,
 			...o.paths
 		};
+		if (config.include) includes.push(...config.include);
+		else everyConfigIncludes = false;
+		if (covering.length && !covering.some((r) => r.path === configPath)) continue;
 		if (o.strict !== true) add("tsconfig-not-strict", "warning", "compilerOptions.strict is not true, so tsc lets wrong names and null values through. Fix: set \"strict\": true.", { file });
 		const lib = o.lib;
 		if (lib && !lib.some((l) => l.toLowerCase() === "dom")) add("tsconfig-no-dom-lib", "error", "compilerOptions.lib leaves out DOM, so element types such as HTMLButtonElement are missing. Fix: add \"DOM\" to lib.", { file });
 		if (String(o.moduleResolution ?? "").toLowerCase() === "classic") add("tsconfig-classic-resolution", "error", "moduleResolution \"classic\" cannot resolve ./x.html.js to the generated x.html.ts. Fix: use \"bundler\" or \"NodeNext\".", { file });
-		if (config.include) includes.push(...config.include);
-		else everyConfigIncludes = false;
 	}
 	if (configs.length && everyConfigIncludes) {
 		const missed = /* @__PURE__ */ new Set();
-		for (const d of dirs) for (const folder of templateFolders(d)) if (!includes.some((p) => covers(p, folder))) missed.add(rel(folder));
+		for (const folder of scanned.flatMap((s) => s.folders)) if (!includes.some((p) => covers(p, folder))) missed.add(rel(folder));
 		for (const folder of missed) add("tsconfig-misses-templates", "error", `No tsconfig include covers ${folder}, which has templates, so their generated types are never checked. Fix: add "${folder === "." ? "**/*" : `${folder}/**/*`}" to include.`, { file: rel(configs[0]) });
 	}
 	let resolvable = Object.keys(paths).includes(runtime);

package/dist/{lint-5vo_ifIc.mjs → lint-DfUAh7t3.mjs}

@@ -1,4 +1,4 @@
-import { a as analyze, f as listHtml, h as scanDefines } from "./a11y-wWL9rie7.mjs";
+import { a as analyze, f as listHtml, h as scanDefines } from "./a11y-CV3nBgBn.mjs";
 import { readFileSync } from "node:fs";
 import { basename, dirname, relative } from "node:path";
 // src/lib/lint.ts

package/dist/oxlint-plugin.mjs

@@ -1,5 +1,5 @@
-import { n as checkA11y, t as A11Y_RULES } from "./a11y-wWL9rie7.mjs";
-import { a as dataFlow, i as contractsFor, l as templateCode, n as UNUSED_MARKUP_RULES, r as componentClasses, t as DATA_FLOW_RULES, u as unusedMarkup } from "./lint-5vo_ifIc.mjs";
+import { n as checkA11y, t as A11Y_RULES } from "./a11y-CV3nBgBn.mjs";
+import { a as dataFlow, i as contractsFor, l as templateCode, n as UNUSED_MARKUP_RULES, r as componentClasses, t as DATA_FLOW_RULES, u as unusedMarkup } from "./lint-DfUAh7t3.mjs";
 import { readFileSync } from "node:fs";
 import { dirname, resolve } from "node:path";
 // src/lib/oxlint-plugin.ts

package/dist/vite-plugin.mjs

@@ -1,4 +1,4 @@
-import { c as generateAll, d as isSelected, f as listHtml, h as scanDefines, i as CodegenError, l as generateFile, n as checkA11y, s as formatDiagnostics, u as isFullPage } from "./a11y-wWL9rie7.mjs";
+import { c as generateAll, d as isSelected, f as listHtml, h as scanDefines, i as CodegenError, l as generateFile, n as checkA11y, s as formatDiagnostics, u as isFullPage } from "./a11y-CV3nBgBn.mjs";
 import { existsSync, readFileSync, unlinkSync } from "node:fs";
 import { resolve, sep } from "node:path";
 // src/lib/vite-plugin.ts

package/llms.txt

@@ -2,7 +2,7 @@
 
 > Designed for AI agents. Driven by TypeScript. Defined in vanilla HTML. A lightweight library for building web components: bind HTML templates to TypeScript custom elements. HTML describes structure and where data goes; TypeScript owns state and behavior; the DOM is the only view. Fully typed by tsc, no virtual DOM, no bundler required.
 
-Workflow: write `x.html` + `x.ts`, run `npx ts-dom check` (regenerates `x.html.ts`, runs tsc and lint, points errors at the template). Import a template as `import tpl from "./x.html.js"` (note the `.js`). Lint with `npx ts-dom lint` (add `--a11y`). `npx ts-dom rules` lists every rule id. Every diagnostic is `file:line:col severity [rule-id] message` and ends with a `Fix:` hint: read the hint and apply it.
+Workflow: write `x.html` + `x.ts`, run `npx ts-dom check` (regenerates `x.html.ts`, runs tsc, or vue-tsc when the project has it, and lint, points errors at the template). Import a template as `import tpl from "./x.html.js"` (note the `.js`). Lint with `npx ts-dom lint` (add `--a11y`). `npx ts-dom rules` lists every rule id. Every diagnostic is `file:line:col severity [rule-id] message` and ends with a `Fix:` hint: read the hint and apply it.
 
 ## Template syntax (HTML only names things; no expressions)
 - `{{ name }}`: text hole, a single identifier only. NOT `{{ a.b }}` / `{{ a + 1 }}`. Not allowed in attributes.
@@ -79,7 +79,7 @@ define("my-counter", MyCounter);
 - `data-each` is never nested: a list inside an item is the item component's own `data-each`.
 
 ## Rules for agents
-- Skills: `npx ts-dom skills` lists the task procedures shipped with the package (`nativele-core` for building components, `nativele-react` for React 19, ...), each with verified versions; `npx ts-dom skills <name>` prints one, `npx ts-dom skills add <name>` copies it into `.claude/skills/` or `.agents/skills/`, and `npx ts-dom doctor` suggests the ones that match the project's dependencies.
+- Skills: `npx ts-dom skills` lists the task procedures shipped with the package (`nativele-core` for building components, `nativele-react`, `nativele-vue`, `nativele-svelte` and `nativele-angular` for those frameworks, `nativele-vite` for Vite, `nativele-integration` for other frameworks, ...), each with verified versions; `npx ts-dom skills <name>` prints one, `npx ts-dom skills add <name>` copies it into `.claude/skills/` or `.agents/skills/`, and `npx ts-dom doctor` suggests the ones that match the project's dependencies.
 - `npx ts-dom rules --explain=<id>` (or `rules --json`) explains any rule id from a diagnostic: why it exists, a wrong example and the fix.
 - Markup well-formedness is a formatter's job: `oxfmt --check` reports misnested tags that the library's parser would silently repair. Generate with `--whitespace=collapse` when a formatter is used.
 - If checks behave oddly (no types, a template not found), run `npx ts-dom doctor --json` first: it reports tsconfig, import path, runtime, generated file and plugin problems with a `Fix:` each.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nativele/ts-dom",
-  "version": "0.5.0",
+  "version": "0.5.1",
   "description": "Designed for AI agents. Driven by TypeScript. Defined in vanilla HTML. A lightweight library for building web components: typed templates, native custom elements, no virtual DOM, no template expressions, no bundler required.",
   "keywords": [
     "html",

package/skills/README.md

@@ -6,6 +6,8 @@ Skills extend what Nativele can be used with, without growing the library: each
 
 A Skill is a task procedure for a coding agent: how to do one integration or one kind of work with Nativele, step by step, with a complete example, the known limitations, and commands that prove it worked. It is not reference documentation: facts about the library's API live in `docs/`, and a Skill links to them instead of restating them.
 
+An integration Skill (a framework, a build tool, a library) starts from a project that already uses that tool and teaches how to bring Nativele into it: what to add, what to change, and what to watch for. It does not teach how to set the tool itself up from nothing; the tool's own documentation and starter projects cover that.
+
 A Skill never changes the library's runtime and never adds a dependency to the library's core. Third-party packages a Skill uses are dependencies of the user's project, installed by the Skill's own steps.
 
 ## Layout
@@ -50,7 +52,7 @@ Required sections, in this order:
 
 1. **When to use**: the situation and the signals (dependencies, files) that call for this Skill, and when not to use it.
 2. **Versions**: a table of every tool and the exact version it was verified with, and the date. If the project uses a different major version of a tool, the Skill says so and stops treating its steps as verified.
-3. **Set-up**: numbered steps with the exact commands and file contents.
+3. **Set-up**: numbered steps with the exact commands and file contents, starting from a working project of the tool (for an integration Skill) and covering only what Nativele adds or changes.
 4. **Example**: a complete, minimal working example (every file it needs, short).
 5. **Known limitations**: what does not work or needs care, each with what to do instead. An agent must never have to guess these.
 6. **Verify**: the commands that prove the integration works in the user's project (for example `npx ts-dom check`, `npx tsc --noEmit`, the project's build, a test), with the output to expect.
@@ -68,11 +70,11 @@ Rules for the content:
 
 | Tier | Who maintains it | Requirements | Shown by `ts-dom skills` |
 |---|---|---|---|
-| Official | the Nativele maintainers | an `example/` project that `npm run verify` checks in CI; verified within the last 6 months | as official |
-| Community | its author | the full SKILL.md format, `author` and `verified` filled in, the verification commands run by the author | as community, with the author |
+| Official | the Nativele maintainers | accepted through an agent trial, and an `example/` project that `npm run verify` checks in CI; verified within the last 6 months | as official |
+| Community | its author | the full SKILL.md format, `author` and `verified` filled in, accepted through a maintainer's agent trial | as community, with the author |
 | Experimental | its author | the SKILL.md format; verification not complete | as experimental, with a warning |
 
-- A new contribution starts as Experimental. It becomes Community when a reviewer has run its verification commands with the stated versions, and Official when the maintainers adopt it with an `example/` project in CI.
+- A new contribution starts as Experimental. It becomes Community when it passes a maintainer's agent trial (see "How a Skill pull request is accepted"), and Official when the maintainers adopt it with an `example/` project in CI.
 - A Skill whose `verified` date is older than 6 months, or whose `nativele` range does not include the installed version, is shown as stale. A stale Official Skill whose CI check fails is moved to Experimental until fixed.
 
 ## Delivering Skills to projects
@@ -90,7 +92,7 @@ None of this adds a runtime dependency: listing and copying read the Markdown fi
 
 - `skills/<name>/example/package.json` pins every tool version the Skill names, depends on the library through `file:../../..` (the library in the same repository), and has `npm run verify`, which runs `ts-dom check`, `ts-dom doctor`, `tsc`, the build, and a short real-browser test of what the Skill promises.
 - `nativele-core` has no example of its own: the library's CI, which checks every example in the repository, verifies it.
-- The workflow `.github/workflows/skills.yml` runs `npm run verify` for each Official Skill when anything under that Skill changes, when the library's runtime changes, and once a month, so a third-party release that breaks a Skill is found. It is not a required check for `main`.
+- The workflow `.github/workflows/skills.yml` runs `npm run verify` for each Official Skill when an `example/` changes, when the library's runtime changes, and once a month, so a third-party release that breaks a Skill is found. A change to `SKILL.md` runs only `.github/workflows/skills-format.yml`, which checks every `SKILL.md` against this specification. Neither is a required check for `main`.
 - The monthly run opens nothing by itself; a failure is reported in the workflow run, and the Skill is fixed or moved to Experimental.
 
 ## Contributing a Skill
@@ -98,7 +100,24 @@ None of this adds a runtime dependency: listing and copying read the Markdown fi
 - Copy `skills/_template/SKILL.md`, fill in every section, set `tier: experimental`.
 - Run the Skill's verification commands in a fresh project with the versions you list, and paste their output in the PR description.
 - The PR touches only `skills/<name>/`; a PR that changes the library and adds a Skill is split. Community and Experimental Skills live in this repository, in the same `skills/` folder, so they ship with the package and `ts-dom skills` lists them with their tier.
-- Review checklist: frontmatter complete; every step reproducible; limitations listed; verification commands and their output present; no restating of `docs/`; nothing that would add a dependency to the core.
+
+## How a Skill pull request is accepted
+
+A Skill is written for agents, so the maintainers accept it by having an agent use it: a fresh agent that knows nothing about the Skill does real work with nothing but the Skill, and the result is checked. Reading the Skill or rerunning its verification commands is not enough, because neither shows what the Skill leaves out.
+
+1. **Check the format**: the frontmatter is complete, every required section is there, the facts link to `docs/` instead of restating them, and nothing would add a dependency to the library's core.
+2. **Build the package from the PR branch** (`npm run build:lib && npm pack`), so the trial uses the real delivery path.
+3. **Start a fresh project** in an empty folder outside the repository: for an integration Skill, the tool's own starter project at the versions the Skill lists (for example `create-vite` with the `react-ts` template), built once to confirm it works before Nativele is added. Install the packed library and the exact tool versions the Skill lists, and install the Skill the way users do: `npx ts-dom skills add <name>`.
+4. **Give a fresh agent a task** that the Skill says it covers, written from its "When to use" and "Example": a small but real piece of work that goes through every set-up step and touches every known limitation. The agent may use the Skill, `npx ts-dom` and the public guides in `docs/`, but not the Nativele source, this repository or the Skill's `example/`. It reports the files it wrote, the output of every Verify command, every point where it had to guess or look elsewhere, and every error it hit and how it fixed it.
+5. **Check the result independently**, without relying on the agent's report: run the Verify commands again and check the behavior in a real browser or with a test.
+
+The Skill is accepted when:
+
+- every Verify command gives the expected output, and the work does what the task asked;
+- the agent followed the Skill's steps as written, and no step was wrong for the stated versions;
+- every guess, outside search or unexplained error in the report is already covered by the Skill; a guess about the tool itself (how to configure the framework, the build tool or the test runner beyond what Nativele needs) is not a gap in the Skill.
+
+Otherwise the maintainers send the gaps back to the contributor as review comments (a missing step, a limitation to list, a Troubleshooting row to add), and the trial runs again, with a new agent, on the updated Skill. The record of the passing trial (agent and model, date, versions, Verify output) is added to the PR as a review comment.
 
 ## Skills
 
@@ -106,9 +125,11 @@ None of this adds a runtime dependency: listing and copying read the Markdown fi
 |---|---|---|---|
 | `nativele-core` | Official | available | building with Nativele itself: the `ts-dom check` loop, components, lists, data flow |
 | `nativele-react` | Official | available | Nativele components in React 19: props, events, children and slots, lifecycle, TSX types |
-| `nativele-integration` | Official | planned | what every framework integration shares: properties and attributes, events, slots, lifecycle, types |
-| `nativele-vite` | Official | planned | the Vite plugin, `root`, hot updates |
-| `nativele-vue` | Official | planned | Nativele components in Vue |
+| `nativele-integration` | Experimental | available | Nativele components in a framework without its own Skill: defining before render, properties and attributes, events, slots, lifecycle, types |
+| `nativele-vite` | Official | available | Nativele in a Vite app: the plugin and `root`, multi-page builds, the build script, hot updates, Vite+ |
+| `nativele-vue` | Official | available | Nativele components in Vue 3: `isCustomElement`, props, events, `v-model`, slots, `<KeepAlive>`, template types |
+| `nativele-svelte` | Experimental | available | Nativele components in Svelte 5: props, event attributes, slots, `bind:this`, template types |
+| `nativele-angular` | Experimental | available | Nativele components in Angular: `CUSTOM_ELEMENTS_SCHEMA`, bindings, zoneless change detection, `ts-dom gen` in the build, content projection |
 | `nativele-state-management` | Official | planned | `createStore`, and Zustand or Redux through `bind` |
 | `nativele-testing` | Official | planned | Vitest and Playwright |
-| Svelte, Angular, Tailwind CSS, TanStack Query, Zod | Experimental or Community | open for contributions | |
+| Tailwind CSS, TanStack Query, Zod | Experimental or Community | open for contributions | |