Workflow

Audit the project

Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, "what is wrong with this site", or before a release.

fe-auditevery web project5 rules83 tokens always loaded, 778 tokens when used, 731 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-audit lands for Claude Code

.claude/skills/fe-audit/SKILL.mdskill
.claude/skills/fe-audit/references/report.mdskill
.claude/rules/fe-audit.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-audit.md

---
paths:
  - "**/frontend-report.md"
  - "**/.frontend-skills/**"
---

# Audit the project (frontend-skills)

Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, "what is wrong with this site", or before a release.

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for OpenAI Codex

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.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-audit lands for Cursor

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.mdskill
.cursor/rules/fe-audit.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-audit.mdc

---
description: Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, "what is wrong with this site", or before a release.
globs: **/frontend-report.md, **/.frontend-skills/**
alwaysApply: false
---

# Audit the project (frontend-skills)

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for GitHub Copilot

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.mdskill
.github/instructions/fe-audit.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-audit.instructions.md

---
applyTo: "**/frontend-report.md,**/.frontend-skills/**"
description: "Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, \"what is wrong with this site\", or before a release."
---

# Audit the project (frontend-skills)

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for Gemini CLI

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.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-audit lands for Antigravity CLI

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.mdskill
.agents/rules/fe-audit.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-audit.md

---
trigger: glob
globs: "**/frontend-report.md, **/.frontend-skills/**"
description: "Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, \"what is wrong with this site\", or before a release."
---

# Audit the project (frontend-skills)

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for Devin / Windsurf

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.mdskill
.devin/rules/fe-audit.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-audit.md

---
trigger: glob
globs: "**/frontend-report.md,**/.frontend-skills/**"
---

# Audit the project (frontend-skills)

Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, "what is wrong with this site", or before a release.

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for OpenCode

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.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-audit lands for Cline

.claude/skills/fe-audit/SKILL.mdskill
.claude/skills/fe-audit/references/report.mdskill
.clinerules/fe-audit.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-audit.md

---
paths:
  - "**/frontend-report.md"
  - "**/.frontend-skills/**"
---

# Audit the project (frontend-skills)

Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, "what is wrong with this site", or before a release.

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for Zed

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.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-audit lands for JetBrains Junie

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.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-audit lands for Kiro

.kiro/skills/fe-audit/SKILL.mdskill
.kiro/skills/fe-audit/references/report.mdskill
.kiro/steering/fe-audit.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-audit.md

---
inclusion: fileMatch
fileMatchPattern: ["**/frontend-report.md", "**/.frontend-skills/**"]
---

# Audit the project (frontend-skills)

Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, "what is wrong with this site", or before a release.

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for Augment

.agents/skills/fe-audit/SKILL.mdskill
.agents/skills/fe-audit/references/report.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-audit lands for Trae

.trae/skills/fe-audit/SKILL.mdskill
.trae/skills/fe-audit/references/report.mdskill
.trae/rules/fe-audit.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-audit.md

---
description: "Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, \"what is wrong with this site\", or before a release."
globs: **/frontend-report.md,**/.frontend-skills/**
alwaysApply: false
---

# Audit the project (frontend-skills)

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for Continue

.frontend-skills/skills/fe-audit/SKILL.mdskill
.frontend-skills/skills/fe-audit/references/report.mdskill
.continue/rules/fe-audit.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-audit.md

---
name: "Audit the project"
description: "Audits a front-end project with frontend-skills - runs the static audit (and the page audit with --url when a page is running), reads the condensed JSON, explains the top findings by rule id with their source, lists what needs a person, and proposes an order of fixes. Use when asked to audit, check or score a project or page, \"what is wrong with this site\", or before a release."
globs: ["**/frontend-report.md", "**/.frontend-skills/**"]
alwaysApply: false
---

# Audit the project (frontend-skills)

- Run the audit, do not imitate it: `npx github:dawidolko/frontend-skills audit --json` and read the JSON, not the source by eye.
- Run the page audit only on a page the person started, with their yes: `audit --url <address>`.
- Present findings by rule id, severity first: critical, serious, moderate, minor.
- For each top rule say why it matters, the fix and how many places; `explain <id>` gives the text and the source.
- Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
- Group fixes by file and by shared component, so one change clears many findings.
- List what the audit cannot check (browser rules without `--url`, manual rules) as a checklist for a person.
- Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
- Never change files during an audit; propose the fixes and let `fe-fix` apply them.

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

The real file

Where fe-audit lands for Amazon Q Developer

.frontend-skills/skills/fe-audit/SKILL.mdskill
.frontend-skills/skills/fe-audit/references/report.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-audit` (Audit the project): when editing `**/frontend-report.md`, `**/.frontend-skills/**`, first read `.frontend-skills/skills/fe-audit/SKILL.md`.

The real file

Where fe-audit lands for Aider

.frontend-skills/skills/fe-audit/SKILL.mdskill
.frontend-skills/skills/fe-audit/references/report.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-audit` (Audit the project): when editing `**/frontend-report.md`, `**/.frontend-skills/**`, first read `.frontend-skills/skills/fe-audit/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:

what is wrong with this site

And to check and fix the work:

Use the fe-audit skill on this file.
Run the front-end audit on what I changed and fix everything serious.
Explain a11y/control-name and fix it here.

Rules it teaches

a11y/control-name
Every button and link has an accessible name; icon-only controls get visually hidden text or aria-label.
criticalstaticWCAG 4.1.2, 2.4.4
a11y/input-label
Every form field has a programmatic label (label element, aria-label or aria-labelledby); a placeholder is not a label.
criticalstaticWCAG 1.3.1, 3.3.2, 4.1.2
a11y/img-alt
Every img and area element has an alt attribute; a decorative image has alt="".
criticalstaticWCAG 1.1.1
a11y/color-contrast
Text has a contrast ratio of at least 4.5:1 with its background; large text (24px, or 18.5px bold) at least 3:1.
seriousbrowserWCAG 1.4.3
perf/lcp-image
The LCP image is in the initial HTML, not lazy, and has fetchpriority="high"; a CSS background LCP image is preloaded.
moderatebrowser

The rule digest

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

Run the audit, do not imitate it: npx github:dawidolko/frontend-skills audit --json and read the JSON, not the source by eye.
Run the page audit only on a page the person started, with their yes: audit --url <address>.
Present findings by rule id, severity first: critical, serious, moderate, minor.
For each top rule say why it matters, the fix and how many places; explain <id> gives the text and the source.
Blocking problems first: missing names and labels (a11y/control-name, a11y/input-label, a11y/img-alt) before contrast (a11y/color-contrast) and speed (perf/lcp-image).
Group fixes by file and by shared component, so one change clears many findings.
List what the audit cannot check (browser rules without --url, manual rules) as a checklist for a person.
Never claim the project is accessible, compliant, secure or fast; say "N problems found, M items need a person".
Never change files during an audit; propose the fixes and let fe-fix apply them.

Steps the agent follows

npx github:dawidolko/frontend-skills audit --json (add --changed for only the changed files). Exit code 1 means something is at or above failOn; 2 is a usage error; 3 means a requested tool is missing.
Read counts, then each entry of rules: severity s, fix, locations at (file:line).
If a dev or preview server is running and the person agrees: audit --url http://localhost:5173/ --json for contrast, rendered names, Lighthouse scores and lab metrics.
Write a short summary: counts by severity, the five rules that matter most with their fix and count, the shared components to fix first, the manual checklist.
Point to frontend-report.md for the full list with sources, and to explain <id> for any rule.

How the agent checks the work

The summary names rule ids that exist (frontend-skills list --rules), and every location is file:line from the JSON.
The person can rerun the same command and get the same counts.

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/report.md731 tokens

SKILL.md on GitHub