Automated summary
Runs the technical gate (TypeScript, Vite build, Vitest, ESLint, with Prettier as advisory) on a migrated page and advances its status to "verified" in tracker.json.
Strengths
- Chains the checks in an explicit order (composite-aware tsc or --noEmit, build, Vitest, ESLint) and records the tool summary in tracker.json.
- Cleanly separates hard failures (tsc, build, Vitest, ESLint) from Prettier advisories, which never block verification.
- Checks that the i18n key-coverage spec exists and surfaces the count of uncheckable dynamic keys as a signal.
- Takes a 30-minute expiring lock before mutating the tracker, preventing concurrent updates.
Limitations
- Assumes an fm-init configuration (appDir, monorepoRoot, tracker.json) and stops if it is missing.
- Covers neither E2E tests nor legacy parity, which are delegated to fm-e2e and fm-parity.
- Tied to the prescribed tooling (Vite, Vitest, ESLint/Prettier) and the project's monorepo layout.
Use it right after fm-gen, when a migrated page must clear the technical gate before E2E or parity work.
Don't use it on a page that hasn't been generated yet, or to validate end-to-end functional behavior.
Security analysis
CautionThe skill legitimately uses Bash, npx tooling, file writes, and an Agent to run a migration verification gate. It does not contain destructive commands, credential/token exfiltration, obfuscated payloads, or safety-disabling instructions, but its broad tool use warrants a caution rating rather than safe.
- •Uses Bash to run npx tsc, vite build, vitest, eslint, and prettier --check from the app directory.
- •Writes to tracker.json and manages a local migration lock file.
- •Spawns a codex-auditor Agent for advisory audit output.
Examples
/fm-verify checkout --app pc/fm-verify settings --app mobileRun the technical gate on the generated checkout page for the pc app, and if tsc, build, vitest and eslint all pass, set its status to verified in tracker.json.name: fm-verify description: "Use after fm-gen to run the technical gate on a migrated page — build, TypeScript (composite-aware), Vitest, and ESLint (hard); Prettier --check is advisory — from the app's appDir, and advance the page to verified." argument-hint: "<page> [--app pc|mobile|hana]" user-invocable: true allowed-tools: Read, Write, Glob, Grep, Bash, Agent
Verify a Migrated Page (Technical Gate)
The first hard gate after generation: build + types + unit/component tests. (E2E is fm-e2e,
legacy parity is fm-parity.) All user-facing output in workingLanguage.
Instructions
Step 0: Config
Read config (absent → run fm-init; stop). Resolve app, its appDir, monorepoRoot,
workingLanguage. Confirm the page is at least generated in tracker.json.
Step 1: Lock
This skill mutates tracker.json, so acquire docs/migration/{app}/{page}/.lock (stale after
30 min) before running the gate. If held and fresh, report who holds it and stop.
Step 2: Resolve the run directory
All commands run from {monorepoRoot}/{appDir}. If appDir is ".", run from root.
Step 3: TypeScript (composite-aware)
Read tsconfig.json in {appDir}:
- has a
referencesarray →npx tsc -b 2>&1 - otherwise →
npx tsc --noEmit 2>&1
Step 4: Build & tests
npx vite build 2>&1(or the app's build script).npx vitest run 2>&1.
Step 4a: i18n key coverage (presence check — the run itself is Step 4)
The key-coverage spec foundation-generator scaffolds (templates/i18n-copy-parity.md) runs inside
Step 4's npx vitest run, so a missing/locale-gapped key already fails the gate there — there is
no separate command here. What this step adds is that the spec exists, so the check cannot be
silently removed:
- Config has an
i18nblock and the app has the spec → note it aspresentand surface itsuncheckable(dynamic-key) count from the vitest output. A rising count is a signal, not a pass. - Config has an
i18nblock but the spec is absent → gate failure; point atfoundation-generator(re-runfm-gen's foundation phase). - No
i18nblock in config → recordskipped(never a silent pass); note thatfm-initcan add it.
Step 4b: Lint (hard) & format (advisory)
Follow CLAUDE.md → "Lint & Format Gate" (detection / scaffold-if-flag-on / skip-if-deps-missing).
- ESLint — hard.
npx eslint . 2>&1. Exit ≠ 0 is a gate failure.skipped(config absent &eslintTemplate: false, or deps missing) does not fail the gate. - Prettier — advisory.
npx prettier --check . 2>&1. Exit ≠ 0 is recorded as a warning only; it never blocksverified. Surface the unformatted file list and suggestnpx prettier --write ..
Step 5: Read and judge (evidence before claims)
Apply the 5-step gate: RUN → READ the full output (exit codes, error/test counts) → VERIFY → CLAIM. Do not report a pass you did not observe. Capture the failing output verbatim if any step fails.
Step 6: Record
Update tracker.json (Read-Modify-Write):
- tsc + build + vitest + eslint all pass (or eslint
skipped) and the i18n key-coverage spec ispresentorskipped→apps[app].pages[page].status = "verified", withverifiedAt, the tool summary, the spec'suncheckablecount underi18nCoverage, and any Prettier advisory underformatWarnings. - any hard tool fails (tsc / build / vitest / eslint), or the spec is absent while
i18nis configured →verify-failed, with the failing summary. A Prettier advisory alone never setsverify-failed.
Release the lock.
Step 6b: Codex audit (advisory) — see CLAUDE.md → "Codex Independent Audit"
If codexAudit is enabled and Codex is available, after the lock is released spawn codex-auditor
(Agent) for the verify stage (params: app, page, stage="verify", appDir, legacyDir,
generated code + test paths + the verify summary, outPath = docs/migration/{app}/{page}/codex-audit.json,
workingLanguage) — an independent second opinion to Claude's own reviewers. Advisory — never
changes the page status. Surface its verdict below.
Step 7: Report
In workingLanguage: per-tool result (tsc / build / vitest / eslint) with the evidence (exit code,
counts), the i18n key-coverage result (present + uncheckable count / absent / skipped), the
Prettier advisory if any, and the Codex audit verdict (advisory). Next step: on pass →
/frontend-migration-plugin:fm-e2e {page}; on fail → /frontend-migration-plugin:fm-fix {page}.
</content>
</invoke>
From the file to a first result
The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.
View the source and supporting filesThis download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.
1. Download the file
Download SKILL.mdFrom the root of a test project, save the file as .skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.
Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.
mkdir -p '.skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/verify-a-migrated-page-technical-gate-ms2s7cxo/download' --output '.skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo/SKILL.md.part' && mv '.skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo/SKILL.md.part' '.skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo/SKILL.md'2. Check prerequisites
Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.
Tools declared by the author (check availability in your agent): Read, Write, Glob, Grep, Bash, Agent
No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.
The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.
3. Load the skill
After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.
Claude Code
test -f '.skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo/SKILL.md' && test -s '.skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/fm-verify' && cp -R '.skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo' '.claude/skills/fm-verify'OpenSkills
OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.
Official OpenSkills installationopenskills install './.skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo'openskills read 'verify-a-migrated-page-technical-gate-ms2s7cxo'Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.
For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.
openskills syncManual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.
4. Try a first task
Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:
Read .skill-downloads/verify-a-migrated-page-technical-gate-ms2s7cxo/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.
ClickHouse Performance Comparison
Testing
Evaluate ClickHouse performance test results, check PR performance changes, compare with history, and assess whether a result is actionable.
Analyze CI Performance Reports
Testing
Analyze CI performance comparison reports for a ClickHouse PR. Cross-references master history to distinguish real regressions from flaky tests.
Santa Method
Testing
Multi-agent adversarial verification with two independent reviewers. Output is checked twice and iteratively fixed until both pass before shipping.