UI Checkstyle / ESLint + Prettier + organize-imports
SkillFiles & storageui-checkstyle is a skill that runs the same ESLint, Prettier, organize-imports, licence header, i18n, and app-docs checks as the repository's UI Checkstyle CI workflow, but only on the files a pull request changed. It computes the changed files from git, applies the fixes in CI's exact order, and fails the task if any file still shows a diff.
Then ask your AI: use the UI Checkstyle / ESLint + Prettier + organize-imports skill
Details
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; Ahel provides instructions and does not run this skill.
No other account needed.
Have the repository checked out with git available and the UI dependencies installed so yarn commands can run.
What your AI can do with it
- Run ESLint, Prettier, and organize-imports on changed src files
- Check licence headers on changed files
- Verify i18n sync by running yarn i18n and checking for a diff
- Verify app-docs by running yarn generate:app-docs and checking for a diff
- Run ESLint, Prettier, and organize-imports on changed playwright files
- Run ESLint and Prettier on changed core-components files
Getting started
- Have the repository checked out with git available and the UI dependencies installed so yarn commands can run.
- Make sure the branch has a git remote reference to origin/main so the skill can compute changed files.
- Invoke the skill after editing UI files, optionally passing --src, --playwright, --core-components, or --all to choose areas.
- Run with --check first to see which files are still dirty without writing changes.
- Run without --check to apply the fixes in CI's order, then commit the result before pushing.
What this skill tells your AI
The instructions your AI receives, as published by open-metadata/openmetadata in skills/ui-checkstyle/SKILL.md and read by Ahel’s review.
The UI Checkstyle GitHub workflow (.github/workflows/ui-checkstyle.yml) runs
a single checkstyle job (after check-changes + authorize gates) whose
steps gate six checks, each on only the files the PR changed:
- ESLint + Prettier + organize-imports on src
(
openmetadata-ui/src/main/resources/ui/src/...) - Licence header check
- i18n sync (
yarn i18nproduces no diff) - app-docs (
yarn generate:app-docsproduces no diff) - ESLint + Prettier + organize-imports on playwright (
.../ui/playwright/...) - ESLint + Prettier on core-components
(
openmetadata-ui-core-components/src/main/resources/ui/src/...)
Any failing step fails the required ui-checkstyle status check. Each lint
step reformats the changed files and fails if the reformat produces a diff — i.e.
the committed tree must already be formatted. This skill runs the same sequence
locally so CI never has to ask.
Note: there is one
checkstylejob with the steps above, not three separatelint-src/lint-playwright/lint-core-componentsjobs — those names are the internal step ids, and the workflow also gates licence/i18n/app-docs.
When to activate
- The user asks to "fix UI checkstyle", "fix UI lint", "run prettier", "run eslint", "fix the UI format", "apply UI format", or similar.
- CI reports a
UI Checkstylefailure (the summary comment lists the failing check and the modified files). - After you have finished authoring or editing any
.ts/.tsx/.js/.jsx/.jsonunder the three UI trees — before opening a PR or pushing a commit that touches UI.
Arguments
--src(default for files underopenmetadata-ui/.../ui/src/)--playwright(files under.../ui/playwright/)--core-components(files underopenmetadata-ui-core-components/...)--all— run all three areas--check— verify only: run the sequence in a dry-run pass and report which files are still dirty, without writing. Useful before push.
If invoked with no flag, auto-detect the affected areas from
git diff --name-only origin/main...HEAD and run only those.
Process
Step 1: Compute the file list
For each area you are running against:
# from the repo root
git diff --name-only origin/main...HEAD -- \
'openmetadata-ui/src/main/resources/ui/src/**/*.{ts,tsx,js,jsx,json}' \
| sed 's|openmetadata-ui/src/main/resources/ui/||' > /tmp/src_files.txt
git diff --name-only origin/main...HEAD -- \
'openmetadata-ui/src/main/resources/ui/playwright/**/*.{ts,tsx,js,jsx}' \
| sed 's|openmetadata-ui/src/main/resources/ui/||' > /tmp/pw_files.txt
git diff --name-only origin/main...HEAD -- \
'openmetadata-ui-core-components/**/*.{ts,tsx,js,jsx,json}' \
| sed 's|openmetadata-ui-core-components/src/main/resources/ui/||' \
> /tmp/core_files.txt
Skip any list that is empty — that area has no changes so the CI check for it wouldn't run anyway.
Step 2: Run the CI sequence
From the corresponding working directory:
cd openmetadata-ui/src/main/resources/ui # or .../openmetadata-ui-core-components/src/main/resources/ui
# 1) imports first — organize-imports-cli only exists for the ui module
cat /tmp/src_files.txt | xargs ./node_modules/.bin/organize-imports-cli
# 2) eslint --fix (same flags CI uses)
NODE_OPTIONS='--max-old-space-size=8192' cat /tmp/src_files.txt \
| xargs ./node_modules/.bin/eslint --no-error-on-unmatched-pattern --fix
# 3) prettier --write — this MUST run after organize-imports because
# organize-imports uses 4-space indentation / drops trailing commas,
# and prettier then puts them back to the repo's 2-space + trailing-comma
# style. Running them in the other order leaves a dirty diff.
cat /tmp/src_files.txt \
| xargs ./node_modules/.bin/prettier \
--config './.prettierrc.yaml' --ignore-path './.prettierignore' \
--write
For playwright, use the same three commands on /tmp/pw_files.txt.
For core-components, the organize-imports step is skipped (no CLI there) —
just eslint + prettier.
Step 3: Report what changed
cd <repo root>
git status --short # should list only .ts/.tsx/.js/.jsx/.json files
git diff --stat
If git status --short is empty, the tree is already clean — tell the user and
stop.
Step 4: Commit
Do not fold the reformat into an unrelated commit. If the user asked you to
commit, follow their preference (fold into the in-progress commit, or make a
separate one). Otherwise, when you are confident the change is a purely
mechanical formatting reformat, you may commit it on its own as a
Fix UI checkstyle commit — this matches the repo's existing history for
bot-triggered formatting-only commits. If you are unsure whether the diff is
purely mechanical, do NOT auto-commit: surface the changed-file list and let the
user decide.
Notes
- The
--checkmode mirrors CI's behavior: run the commands and then verifygit status --shortis empty. Revert any writes before exiting so the user's working tree isn't touched. - If ESLint reports hard errors (not warnings, not auto-fixable), stop and
surface them — they need a real code change, not a format pass. Warnings
(e.g.
playwright/no-wait-for-selector) don't fail CI and can be left. - The analogous Java command is
mvn spotless:apply— see thejava-checkstyleskill. - TypeScript type-check errors (
tsc) are a separate concern and are not fixed by this skill — thetsc:check/tsc:playwrightscripts run in different jobs.
Out of scope
- TypeScript type-check errors (
tsc) — different jobs, different failure modes, not auto-fixable by this skill. - Java formatting — use the
java-checkstyleskill (mvn spotless:apply). - Python formatting — use
make py_format(ruff lint-fix + format; seeingestion/Makefile). (Note: this is ruff, not black/isort/pycln.)
Signals
- GitHub stars
- 15k
- Forks
- 2k
- Last commit
- Oct 2026
Questions
- Does it run on all UI files or only the ones the pull request changed?
- It runs only on the files the pull request changed, computed from git diff --name-only origin/main...HEAD, matching how the CI workflow scopes its checks.
- What happens if a file still shows a diff after the fixes?
- The task fails, because the committed tree must already be formatted. The skill applies the fixes in CI's exact order and fails if any file still shows a diff.
Advanced
- Item type
- skill
- Key
ui-checkstyle- Source
- github.com/open-metadata/openmetadata
github.com/open-metadata/openmetadata
Related picks
Skill · a5c-ai
The pick for Java110-java-maven-best-practices
Skill · jabrena
The pick for Javaduplicate-js
Skill · thedaviddias
The pick for JavaScriptmodern-javascript-patterns
Skill · sickn33
The pick for JavaScriptdbos-python
Skill · sickn33
The pick for Pythonpython-design-patterns
Skill · wshobson
The pick for Python