Stop Pasting Review Prompts: Put a 'frontend-review' Skill in Your Repo

Stop Piling Up 10,000-Word Prompts: Use Agent Skills to Write a 'Frontend Review' Skill for Your Team

Cover: A SKILL.md on a workshop table

If someone on your team uses AI to help review PRs, you'll quickly run into the same thing: everyone's chat box has a copy of a "frontend review checklist." Today three items get added, tomorrow two get removed, and someone is still copying last month's version. The checklist itself isn't wrong; the problem is that it lives in the wrong place: in chat history, not in the repo.

Agent Skills does something simple: it bundles "how to do a certain type of work" into a folder, with a core SKILL.md file. The assistant reads it when needed, so you don't have to paste a 10,000-word manual into the prompt every time. On October 22, 2026, Anthropic donated this open standard to the Agentic AI Foundation (AAIF) under the Linux Foundation. The spec remains open; the name, logo, GitHub organization, and agentskills.io were handed over to improve cross-product reuse.

This article isn't a conceptual tour. The goal is simple: by the end, you can copy a frontend Review Skill into your repo and use it the same day. A full template is at the end, and the accompanying demo/ directory can run the validation script directly.

First, Clarify: What Each of Prompt, AGENTS.md, and Skill Handles

People often mix them up in conversation, but when you're implementing, it's best to separate them:

Thing	More like	Best for
One-off Prompt	An in-person request	"Check this diff for me this time"
Project-level description (e.g., `AGENTS.md`)	Orientation manual cover	Repo conventions, directory structure, default tone
Agent Skill (`SKILL.md`)	A specific work card on the wall	A fixed procedure for one type of task (e.g., frontend Review)

The value of a Skill isn't "writing longer"; it's discoverable, reusable, and loaded on demand. The spec calls this progressive disclosure: at startup, only each skill's name + description are seen; when a task really matches, the full SKILL.md is read; scripts and reference documents are opened on demand further along. This way you can have many skills in a repo without filling the context upfront.

Progressive disclosure: know the capability first, expand when used

For first-hand documentation, see: Agent Skills Specification, Anthropic donation announcement (2026-10-22).

What a Skill Directory Actually Looks Like

The minimum is one file:

frontend-review/
└── SKILL.md

A fuller example can look like this (the last three directories are optional):

frontend-review/
├── SKILL.md          # Required: YAML header + Markdown body
├── scripts/          # Optional: executable scripts
├── references/       # Optional: supplementary docs read on demand
└── assets/           # Optional: templates, static resources

What a Skill directory looks like

SKILL.md must start with YAML frontmatter. The spec requires at least two fields:

name: lowercase letters / numbers / hyphens, must match the directory name, can't contain --, and can't start or end with -
description: say clearly what it does and when to use it; this is the main basis for the assistant deciding whether to activate the skill

Optional fields include license, compatibility, metadata, allowed-tools (experimental), etc. There's no mandatory template for the body, but the official suggestion is to keep the main body from bloating: put detailed material in references/, and what can be scripted into scripts/.

The minimal skeleton looks like this:

---
name: frontend-review
description: Review frontend code changes in this repo. Use when the user asks for code review, PR review, 前端 review, 检查改动, or before merging UI changes.
---

# 前端 Review

按顺序执行：看清改动范围 → 类型检查 → Lint → 危险改动禁区。
输出固定结构的结论，少写空话。

Just these few lines already beat "pasting the review checklist into every new conversation" because it's version-controlled; change it once, and the whole team picks it up next session.

Why Frontend Review Is a Good First Skill

Not every process is worth making into a skill. Frontend Review happens to hit several points:

Stable steps: look at scope, then typecheck, then lint, then look at sensitive areas. Human review follows the same order.
Commands can run: tsc --noEmit, eslint, biome are more reliable than "that feels elegant".
A clear deny-list: .env, auth, dangerouslySetInnerHTML, postMessage without validating origin... you can make a list.
Team standards need to be unified: the worst is everyone having their own "must change / suggest change" in each prompt.

In one sentence: move "how our group agreed to review frontend" from chat history into the repo.

Four gates for frontend review

Do It: Write a Working "Frontend Review" Skill

The following is the same source as demo/frontend-review/SKILL.md at the end of the article; you can copy it directly. Change two places to match your repo's script names.

---
name: frontend-review
description: Review frontend code changes in this repo. Use when the user asks for code review, PR review, 前端 review, 检查改动, 帮我看看这段代码, or before merging UI/React/Vue/Next changes. Runs typecheck then lint, then checks a deny-list of risky paths. Do not invent security exploits; only report defensive findings.
license: MIT
metadata:
  author: team-frontend
  version: "1.0"
  audience: frontend
---

# 前端 Review Skill

你在帮这个仓库做**前端改动审查**。目标不是写长篇作文，而是按固定顺序把关，并给出可执行结论。

## 何时启用

用户提到 code review / PR review / 检查改动 / 帮我看看这段前端代码 / merge 前自查时启用本 skill。

## 硬规矩（按顺序，不要跳）

1. **看清改动范围**
   - 先列出本次相关文件（`git status` / `git diff --stat`，或用户粘贴的片段）。
   - 超出需求的顺手重构：标成「建议另开 PR」，默认不要帮用户直接改。

2. **类型检查**
   - 仓库有 TypeScript 时优先跑项目脚本，例如：
     - `pnpm typecheck` / `npm run typecheck` / `npx tsc --noEmit`
   - 有报错：先把错误路径和信息贴出来，再谈风格。

3. **Lint**
   - 有 ESLint / Biome / Oxlint 就跑对应脚本，例如 `pnpm lint`。
   - 只修与本次改动相关的告警；全仓历史债另记，不借机大扫除。

4. **危险改动禁区（防御清单）**
   若 diff 触及下列路径或模式，必须**显式标红**，并要求人工确认后再继续：
   - `**/.env*`、密钥、Token、私钥、内网地址硬编码
   - `**/auth/**`、登录态、Cookie / LocalStorage 写敏感字段
   - `dangerouslySetInnerHTML`、未消毒的 HTML 拼接
   - `postMessage` / `iframe` 未校验 `origin`
   - 依赖锁文件被无关改动大面积重写
   - 删除或弱化 CSP、CORS、CSRF、权限校验相关代码
   - 把用户输入直接拼进 `eval`、动态 `Function`、未校验的路由跳转

   只做**防御向说明**：指出风险点与建议改法。不要给出可复现的攻击步骤、PoC、payload。

## 输出格式（照抄结构）

（输出模板开始）

## Review 结论
- 结论：通过 / 有条件通过 / 不通过
- 一句话原因：…

## 已执行检查
- [ ] 改动范围已核对
- [ ] 类型检查：通过 / 失败 / 仓库无脚本（说明）
- [ ] Lint：通过 / 失败 / 仓库无脚本（说明）
- [ ] 禁区：未命中 / 命中（列出文件）

## 必须改
1. …

## 建议改
1. …

## 可以以后再说
1. …

（输出模板结束）

## 写作语气

- 像同事在评审：短句、点名文件、少形容词。
- 不确定就说不确定，并写出要用户确认的点。

You can put the deny-list details in a separate references/denylist.md and link to it from the body; this takes advantage of progressive disclosure: it doesn't take up context normally, and only expands when sensitive changes are encountered.

Put It in the Repo: Where, How to Validate, and How to Invoke It

1) Where to Place the Directory

The official Quickstart (with VS Code as an example) looks for skills under the project by default:

mkdir -p .agents/skills
cp -R frontend-review .agents/skills/

Different products may scan different paths, but the file format is the same. Follow the docs of the agent you're using; the key is that the name field and the folder name both say frontend-review.

2) Validate the Skill Itself First

The accompanying script doesn't need internet; it only checks frontmatter, naming, and line count:

bash demo/frontend-review/scripts/check-skill.sh

You should see something like:

OK:   frontmatter delimiters
OK:   name=frontend-review
OK:   description length ...
OK:   SKILL.md line count ...
All passed. Copy this directory to .agents/skills/frontend-review/ to try it.

The spec also mentions you can use skills-ref validate ./my-skill from the official reference implementation for a fuller check; the bash script above is for "zero dependency, run it right away."

3) How to Trigger It in a Conversation

Start a new agent conversation and just say it in plain language, for example:

Use the frontend review skill to review the current changes. Typecheck first, then lint.

Or:

This is a React PR, do a code review.

The assistant should first match frontend-review via the description, then load the body and output according to the four gates. If it merely compliments the code without running checks, make the "hard rules" harsher, or switch to a more obedient agent mode/model; tool obedience varies by product, as the official Quickstart honestly notes.

4) Division of Labor with CI

The Skill is a workflow card for the session; CI is the merge gate. The former improves daily self-check efficiency, and the latter should not be replaced. Typecheck/lint should still turn red when they fail.

What a "Respectable" Review Output Looks Like

Assume a colleague changed a component near the login page and also touched a postMessage listener. After the skill runs, the ideal output is close to this (illustrative, not something to memorize):

## Review 结论
- 结论：有条件通过
- 一句话原因：类型检查和 Lint 过了，但 `src/features/auth/sessionBridge.ts` 的 postMessage 未校验 origin，需人工确认。

## 已执行检查
- [x] 改动范围已核对（5 files）
- [x] 类型检查：通过（pnpm typecheck）
- [x] Lint：通过（pnpm lint）
- [x] 禁区：命中 sessionBridge.ts（postMessage）

## 必须改
1. `sessionBridge.ts`：处理消息前校验 `event.origin`，只接受白名单域名；来源不明时直接 return。
2. 不要把 access token 写入 `localStorage` 的调试字段；改用现有 session 封装。

## 建议改
1. 登录按钮 loading 态与错误文案拆开，避免失败时按钮一直转圈。

## 可以以后再说
1. 顺手重排的无关 import，建议另开 PR，别和鉴权改动绑在一起。

Note two things:

"Conditional pass" is the norm, not a cop-out. When a deny-list item is hit, you should stop and get human confirmation.
Bucketing into must/should/later is easier to review than one long essay. Human reviewers also save time: you only need to check whether the must-do items are covered.

If you find the assistant still outputs "overall good, suggest paying attention to performance" empty talk, go back and edit the skill body: make the output format a mandatory structure, and explicitly forbid praise without file paths.

Team Rollout: Don't Invent Twelve Work Cards at Once

The recommended order is:

Start with Review (this article): it pays off immediately in daily PR conversations.
Then add "New Page / New Component": specify directory, naming, whether story/testing is required.
Finally do narrow domain skills (e.g., "edit charts", "edit form validation"), to avoid having a skill list longer than the component library.

Three practical collaboration tips:

Skill changes go through PR; reviewers look at "whether the procedure got stricter/looser," not prose.
Changes to description need regression: try three rounds of triggering using the team's high-frequency phrases.
In README or contributing guide, write: "For frontend self-check, you can invoke frontend-review skill" — that's more durable than a verbal recommendation.

Compared to writing standards into the system prompt, Skills add two things: version control and on-demand loading. Changing a system prompt affects every conversation; a Skill only lights up for relevant tasks and is easier to change confidently.

How to Write a `description` That Can Be Invoked

Many people write description as "help review code" — too vague; the assistant doesn't know when to activate it.

A better description answers two things: what it will do, and how the user might call for it:

description: Review frontend code changes in this repo. Use when the user asks for code review, PR review, 前端 review, 检查改动, 帮我看看这段代码, or before merging UI/React/Vue/Next changes.

Include both Chinese and English keywords that match your team's actual verbal habits. After changing the description, test triggering with a few real phrases; if it doesn't fire when it should, the description is likely too narrow or too vague, not that the body isn't long enough.

Common Pitfalls (We've Stepped In or Seen Others Step In)

name and directory name mismatch
The spec says they must match. If the directory is frontend-review but name is FrontendReview, that's directly disqualified.
Stuffing the entire design doc into SKILL.md
The spec suggests keeping the main body lean and externalizing details. A Review skill especially shouldn't paste the full component spec from three years ago; link to references/ or a repo documentation path.
Turning the deny-list into an "attack tutorial"
The defensive list only writes "what to flag and how to tighten it up." Don't include PoCs or payloads. For third-party skills, read through scripts/ before installing; official research also emphasizes only trusting reviewed sources.
Expecting the skill to replace human review
It's good at fixed procedures and catching omissions; product semantics and interaction reasonableness are still a human call. Keeping a "conditional pass" in the conclusion is more honest than forcing a "pass."
Everyone has a local copy that's out of sync
A Skill only makes sense in Git. Rule changes go through normal PRs; don't send a colleague another .docx privately.

What You Can Take Away

Agent Skills = folder + SKILL.md; an open cross-product format now hosted by AAIF.
Progressive disclosure: name/description first, load body and attachments when used.
Frontend Review is a good first team skill: fixed order, runnable commands, listable deny-list.
The template and demo/frontend-review/ in this article can be copied directly; run scripts/check-skill.sh first, then put it in .agents/skills/.

Next time you want to add rules like "modified components must include unit tests" or "before styling, search for design tokens", don't open a new 10,000-word prompt; add a hard rule to the same SKILL.md, or hang another narrower skill. As work cards pile up, the chat box can get shorter.