Workflow

Review a change

Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or "check my changes before I push".

fe-reviewevery web project5 rules80 tokens always loaded, 787 tokens when used, 789 tokens in references on demand.

Install

init installs this skill when the project uses every web project. Pick your agent to see where its files land.

npx github:dawidolko/frontend-skills init

Not tested yet with this runner. npx and pnpm dlx are tested; if this one fails, use one of them.

Without --agents, init finds the agents from what the project already has, and asks when it finds none:

How init finds each of the 17 agents

Agent	Found by
Claude Code	`CLAUDE.md` `.claude` `CLAUDE.local.md`
OpenAI Codex	`.codex` `AGENTS.override.md`
Cursor	`.cursor` `.cursorrules`
GitHub Copilot	`.github/copilot-instructions.md` `.github/instructions` `.github/skills` `.github/prompts`
Gemini CLI	`GEMINI.md` `.gemini`
Antigravity CLI	`.agents/rules` `.agent/rules`
Devin / Windsurf	`.devin` `.windsurf` `.windsurfrules`
OpenCode	`opencode.json` `opencode.jsonc` `.opencode`
Cline	`.clinerules` `.cline`
Zed	`.rules` `.zed`
JetBrains Junie	`.junie`
Kiro	`.kiro`
Augment	`.augment` `.augment-guidelines`
Trae	`.trae`
Continue	`.continue`
Amazon Q Developer	`.amazonq`
Aider	`.aider.conf.yml` `CONVENTIONS.md`

Where fe-review lands for Claude Code

.claude/skills/fe-review/SKILL.mdskill
.claude/skills/fe-review/references/review.mdskill
.claude/rules/fe-review.mdrule file
CLAUDE.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.claude/rules/fe-review.md

---
paths:
  - "**/*.html"
  - "**/*.jsx"
  - "**/*.tsx"
  - "**/*.js"
  - "**/*.vue"
  - "**/*.svelte"
  - "**/*.astro"
  - "**/*.css"
  - "**/*.scss"
---

# Review a change (frontend-skills)

Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or "check my changes before I push".

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.claude/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for OpenAI Codex

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

OpenAI Codex has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

AGENTS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-review lands for Cursor

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
.cursor/rules/fe-review.mdcrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.cursor/rules/fe-review.mdc

---
description: Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or "check my changes before I push".
globs: **/*.html, **/*.jsx, **/*.tsx, **/*.js, **/*.vue, **/*.svelte, **/*.astro, **/*.css, **/*.scss
alwaysApply: false
---

# Review a change (frontend-skills)

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.agents/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for GitHub Copilot

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
.github/instructions/fe-review.instructions.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.github/instructions/fe-review.instructions.md

---
applyTo: "**/*.html,**/*.jsx,**/*.tsx,**/*.js,**/*.vue,**/*.svelte,**/*.astro,**/*.css,**/*.scss"
description: "Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or \"check my changes before I push\"."
---

# Review a change (frontend-skills)

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.agents/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for Gemini CLI

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
GEMINI.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Gemini CLI: Gemini CLI was replaced by Antigravity CLI for unpaid tiers on 2026-06-18; choose "antigravity" too if you use it.

Gemini CLI has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

GEMINI.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-review lands for Antigravity CLI

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
.agents/rules/fe-review.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.agents/rules/fe-review.md

---
trigger: glob
globs: "**/*.html, **/*.jsx, **/*.tsx, **/*.js, **/*.vue, **/*.svelte, **/*.astro, **/*.css, **/*.scss"
description: "Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or \"check my changes before I push\"."
---

# Review a change (frontend-skills)

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.agents/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for Devin / Windsurf

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
.devin/rules/fe-review.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Devin / Windsurf: Devin CLI also reads .cursor/rules; with Cursor chosen too, the CLI sees both rule files of a skill.

Planned by the installer itself for the example React project in the repository.

.devin/rules/fe-review.md

---
trigger: glob
globs: "**/*.html,**/*.jsx,**/*.tsx,**/*.js,**/*.vue,**/*.svelte,**/*.astro,**/*.css,**/*.scss"
---

# Review a change (frontend-skills)

Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or "check my changes before I push".

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.agents/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for OpenCode

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

OpenCode has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

AGENTS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-review lands for Cline

.claude/skills/fe-review/SKILL.mdskill
.claude/skills/fe-review/references/review.mdskill
.clinerules/fe-review.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Cline: If .clinerules is a single file rather than a folder, Cline rule files are not written; skills still are.

Planned by the installer itself for the example React project in the repository.

.clinerules/fe-review.md

---
paths:
  - "**/*.html"
  - "**/*.jsx"
  - "**/*.tsx"
  - "**/*.js"
  - "**/*.vue"
  - "**/*.svelte"
  - "**/*.astro"
  - "**/*.css"
  - "**/*.scss"
---

# Review a change (frontend-skills)

Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or "check my changes before I push".

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.claude/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for Zed

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
CLAUDE.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Zed: Zed reads only the first instruction file of its list; the block is placed in that file.

Zed has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

CLAUDE.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-review lands for JetBrains Junie

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

JetBrains Junie: Junie reads .agents/skills only in a trusted project.

JetBrains Junie has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

AGENTS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-review lands for Kiro

.kiro/skills/fe-review/SKILL.mdskill
.kiro/skills/fe-review/references/review.mdskill
.kiro/steering/fe-review.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.kiro/steering/fe-review.md

---
inclusion: fileMatch
fileMatchPattern: ["**/*.html", "**/*.jsx", "**/*.tsx", "**/*.js", "**/*.vue", "**/*.svelte", "**/*.astro", "**/*.css", "**/*.scss"]
---

# Review a change (frontend-skills)

Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or "check my changes before I push".

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.kiro/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for Augment

.agents/skills/fe-review/SKILL.mdskill
.agents/skills/fe-review/references/review.mdskill
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Augment has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

AGENTS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-review lands for Trae

.trae/skills/fe-review/SKILL.mdskill
.trae/skills/fe-review/references/review.mdskill
.trae/rules/fe-review.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Trae: Trae reads AGENTS.md only after it is enabled in its settings.

Planned by the installer itself for the example React project in the repository.

.trae/rules/fe-review.md

---
description: "Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or \"check my changes before I push\"."
globs: **/*.html,**/*.jsx,**/*.tsx,**/*.js,**/*.vue,**/*.svelte,**/*.astro,**/*.css,**/*.scss
alwaysApply: false
---

# Review a change (frontend-skills)

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.trae/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for Continue

.frontend-skills/skills/fe-review/SKILL.mdskill
.frontend-skills/skills/fe-review/references/review.mdskill
.continue/rules/fe-review.mdrule file

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.continue/rules/fe-review.md

---
name: "Review a change"
description: "Reviews a diff or pull request of front-end code - runs audit --changed, maps the touched files to their skills, walks the manual rules of those skills (keyboard, screen reader, motion, content), and reports findings by rule id with file, line and fix. Use when asked to review a pull request, a branch, staged changes or a component, or \"check my changes before I push\"."
globs: ["**/*.html", "**/*.jsx", "**/*.tsx", "**/*.js", "**/*.vue", "**/*.svelte", "**/*.astro", "**/*.css", "**/*.scss"]
alwaysApply: false
---

# Review a change (frontend-skills)

- Start with the tool: `npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json`.
- Review only what the change touches; mention older problems once, separately, without blocking on them.
- Map each touched file to its skills (by file type and framework) and walk their manual rules too.
- Report every finding as rule id, `file:line`, one sentence why, and the fix; link `explain <id>` instead of pasting rule text.
- New `fs-ignore` comments need a rule id and a reason (tooling/ignore-with-reason).
- Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
- Test changes: no `.only`, no fixed waits, assertions that users would notice (test/no-focused-tests).
- Separate blocking findings (at or above `failOn`) from suggestions; never block on taste.
- Never approve on the audit alone; say what was checked automatically and what still needs a person.

Before larger changes, read the full skill: `.frontend-skills/skills/fe-review/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-review lands for Amazon Q Developer

.frontend-skills/skills/fe-review/SKILL.mdskill
.frontend-skills/skills/fe-review/references/review.mdskill
.amazonq/rules/frontend-skills.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Amazon Q Developer: Amazon Q Developer IDE plugins reach end of support on 2027-04-30; AWS points to Kiro.

Amazon Q Developer has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

.amazonq/rules/frontend-skills.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

### Skills

- `fe-review` (Review a change): when editing `**/*.html`, `**/*.jsx`, `**/*.tsx`, `**/*.js`, `**/*.vue`, `**/*.svelte`, `**/*.astro`, `**/*.css`, `**/*.scss`, first read `.frontend-skills/skills/fe-review/SKILL.md`.

The real file

Where fe-review lands for Aider

.frontend-skills/skills/fe-review/SKILL.mdskill
.frontend-skills/skills/fe-review/references/review.mdskill
CONVENTIONS.mdinstruction block
.aider.conf.ymlconfig

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Aider has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

CONVENTIONS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

### Skills

- `fe-review` (Review a change): when editing `**/*.html`, `**/*.jsx`, `**/*.tsx`, `**/*.js`, `**/*.vue`, `**/*.svelte`, `**/*.astro`, `**/*.css`, `**/*.scss`, first read `.frontend-skills/skills/fe-review/SKILL.md`.

The real file

How to use it

Once installed, the agent loads the skill by itself when a task matches its description. You can also ask for it in your own words, for example:

Phrases from the skill description that make the agent pick it:

check my changes before I push

And to check and fix the work:

Use the fe-review skill on this file.
Run the front-end audit on what I changed and fix everything serious.
Explain tooling/ignore-with-reason and fix it here.

Rules it teaches

tooling/ignore-with-reason
Every fs-ignore comment names the rule id it silences and says why; a bare fs-ignore silences every rule on the line.
moderatemanual
a11y/no-keyboard-trap
Keyboard focus can always leave a component with Tab, Shift+Tab or Escape; only an open modal keeps focus inside.
criticalmanualWCAG 2.1.2
a11y/status-message-live
Messages that appear without moving focus (saved, results, errors, progress) are announced through a live region.
seriousmanualWCAG 4.1.3
a11y/focus-not-obscured
Sticky headers, footers, cookie banners and chat widgets never fully cover the element that has keyboard focus.
seriousmanualWCAG 2.4.11
test/no-focused-tests
No focused tests (.only, fit, fdescribe) are committed; they silently skip the rest of the suite.
seriousstatic

The rule digest

This part is copied into each agent's scoped rule file, so it stands on its own:

Start with the tool: npx github:dawidolko/frontend-skills audit --changed --base <target branch> --json.
Review only what the change touches; mention older problems once, separately, without blocking on them.
Map each touched file to its skills (by file type and framework) and walk their manual rules too.
Report every finding as rule id, file:line, one sentence why, and the fix; link explain <id> instead of pasting rule text.
New fs-ignore comments need a rule id and a reason (tooling/ignore-with-reason).
Interactive changes get a keyboard and screen reader check: no traps, announced status messages, focus not hidden (a11y/no-keyboard-trap, a11y/status-message-live, a11y/focus-not-obscured).
Test changes: no .only, no fixed waits, assertions that users would notice (test/no-focused-tests).
Separate blocking findings (at or above failOn) from suggestions; never block on taste.
Never approve on the audit alone; say what was checked automatically and what still needs a person.

Steps the agent follows

Get the diff: git diff --name-only <base>...HEAD (or the pull request's files). Note the frameworks from the profile.
Run audit --changed --base <base> --json; every finding on a changed line is in scope.
For each touched area, open its skill's ## Rules and check the manual ones against the diff: forms (fe-a11y-forms), widgets (fe-a11y-dialog, -menus, -tabs-accordion, -combobox), media, i18n, security sinks, performance of new dependencies and images.
If a preview URL exists and the person agrees, run audit --url <preview> for contrast, rendered names and Lighthouse.
Write the review: blocking findings, suggestions, manual checks done, manual checks left for a person.

How the agent checks the work

Every finding has a real rule id (list --rules) or is clearly marked as a suggestion without one.
The review says which commands ran and their result.

Checked by the audit

The static checks of these rules run in audit; this is a real session on the example project:

Terminal recording: audit lists findings by severity with rule ids and file:line, and fails at serious. — `audit`: counts by severity, each rule with its first location, the exit code.

Reference files

references/review.md789 tokens

SKILL.md on GitHub