ワンクリックで
frontend-dev
Frontend development. Use for React, Next.js, Raycast extensions, Vite-based frontend projects.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Frontend development. Use for React, Next.js, Raycast extensions, Vite-based frontend projects.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Compare Claude Code and Codex on the same real code-change task with isolated worktrees, identical gates, transcripts, time, and cost.
Align AGENTS.md, rules, README, plans, and chronicles with the codebase; use --clean to archive obsolete task docs into ATLAS.md.
Research current best practices and turn the evidence into a clear recommendation. Use for state-of-the-art, evidence-based, optimal-approach, comparison, or pros-and-cons questions in any field.
Clarify an ambiguous or consequential change before planning or implementation when more than one sound approach exists.
Add CHANGELOG.md entries, derive them from commits, or cut a Keep a Changelog and SemVer release.
Create a user-requested Conventional Commit from the staged changes.
| name | frontend-dev |
| description | Frontend development. Use for React, Next.js, Raycast extensions, Vite-based frontend projects. |
| user-invocable | true |
| allowed-tools | Glob, Read, Grep, Bash, Task, Skill, Edit, Write, AskUserQuestion |
Announce: "I'm using the frontend-dev skill. Following the 4-phase workflow."
Before any command suggestion, you MUST detect the project's package manager. Do NOT default to npm without checking.
Read ../typescript-dev/references/package-manager.md and apply its detection algorithm: packageManager field in package.json wins; otherwise the lockfile (bun.lock/bun.lockb → bun, pnpm-lock.yaml → pnpm, yarn.lock → yarn, package-lock.json → npm). No signal → ask the user.
State the result before proceeding: "Detected [pm] (via [signal]). Will use [pm] commands."
Record durably. In-context memory is volatile (compaction, subagent dispatch, /clear all wipe it). Add a Package Manager: line to the WORKFLOW STATE block of the active plan file:
Package Manager: <pm> (via <signal>)
If the plan file does not exist yet (Phase 1 will create it), carry the value forward in your immediate working notes and re-state it as the first WORKFLOW STATE field the moment the plan is created. Phase 3 verify resolves <PM> from this recorded line, not from in-context recall — never substitute from memory.
Gate: Package manager detected (or user-confirmed) AND recorded. Then proceed to Pre-Step B.
Before starting the workflow, you MUST detect the frontend framework. Do NOT skip this step. Do NOT assume a framework without checking.
Examine the project root for config files and package.json dependencies. Match the first row that applies.
ALWAYS read patterns/typescript.md AND patterns/coding-conventions.md as a base — they apply to every frontend framework.
| Signal | Framework | Pattern Files to Read (+ typescript.md, coding-conventions.md) |
|---|---|---|
next.config.* or app/layout.tsx exists | Next.js | patterns/react.md + patterns/nextjs.md |
@raycast/api in deps | Raycast | patterns/react.md + environments/raycast.md |
vite.config.* + react in deps | React + Vite | patterns/react.md + environments/vite.md |
*.tsx/*.jsx + react in deps | React | patterns/react.md |
vue in deps or vite.config.* + vue | Vue | (no Vue-specific patterns yet) |
svelte in deps or svelte.config.* | Svelte | (no Svelte-specific patterns yet) |
@angular/core in deps | Angular | (no Angular-specific patterns yet) |
Note: Frameworks without dedicated pattern files use general TypeScript patterns. Consider creating
patterns/[framework].mdfor team-specific standards.
State: "Detected framework: [Framework Name]. Reading pattern files: [list of files]."
If no framework matches, ask: "I couldn't auto-detect your frontend framework. Which are you using?"
Gate: Framework detected and pattern files identified. Only after detection, proceed to the workflow.
You MUST read workflow.md NOW and follow ALL 4 phases defined there. The sections below provide frontend-specific inputs for each phase.
Phase 1: Read patterns/typescript.md AND patterns/coding-conventions.md FIRST (always), then ALL framework-specific pattern files identified in Framework Detection.
If you lost workflow.md from context: Re-read ../../shared/workflow.md NOW before continuing.
WORKFLOW STATE Verification line: <PM> run build, <lint-commands>, <PM> test — resolve <PM> from the Package Manager: line recorded in WORKFLOW STATE during Pre-Step A (do NOT substitute from in-context recall). Lint failure BLOCKS Phase 3 verify — see Lint Enforcement below.
Phase 3 Tier A commands — use the commands appropriate for the detected framework. The <PM> run <script> placeholders below resolve via the detected package manager (npm/pnpm/yarn/bun):
| Framework | Type Check | Build | Lint † | Test |
|---|---|---|---|---|
| Next.js | (included in build) | <PM> run build | <PM> run lint | vitest/jest |
| React + Vite | tsc --noEmit | vite build | eslint | vitest |
| Raycast | ray build | (included) | eslint | — |
† Lint command shown is the conventional default. The skill detects the actual linter(s) per Lint Enforcement below — failure blocks Phase 3 verify.
Lint failures BLOCK Phase 3 verification with the same severity as a failing test. Read ../typescript-dev/references/lint-enforcement.md at the start of Phase 3 verification and follow it.
Detection is a union, not a priority ladder:
package.json defines scripts.lint → run <PM> run lint. Done.No --fix auto-remediation — agents fix lint errors intentionally.
schemas.ts, types derived via z.infer, composition over deep extends chains.transform() for renamed fields, .default() for new fields, preserve exported signatures and component propspatterns/typescript.md, patterns/coding-conventions.md, AND the framework-specific pattern file(s)Two upstream sources extend the local pattern files. Both are opt-in — never auto-install or auto-fetch.
If framework = Next.js, check whether the project ships version-matched docs:
test -d node_modules/next/dist/docs && echo "bundled docs present"
When present, treat node_modules/next/dist/docs/ as the authoritative source for routing, data fetching, caching, and API references — it is version-matched to the installed next, so it overrides anything conflicting from training data. Index: node_modules/next/dist/docs/index.mdx.
If absent, tell the user they can opt in via npx @next/codemod@latest agents-md (adds bundled docs + an AGENTS.md block). Do not run it for them. See nextjs.org/docs/app/guides/ai-agents.
react-best-practices (separate installable skill)For React perf work (async waterfalls, bundle bloat, unnecessary re-renders), Vercel publishes 40+ impact-rated rules as a standalone agent skill. If the user wants stronger React performance guidance, suggest:
npx skills add vercel-labs/agent-skills
Source: vercel.com/blog/introducing-react-best-practices. Once installed, it loads as its own skill alongside frontend-dev — this skill does not invoke or depend on it.
install / run <script> / exec <bin> command — never default to npmscripts.lint, no biome/eslint/oxlint config). See ../typescript-dev/references/lint-enforcement.md.Add these to the shared workflow's verification checklist:
typescript.md and coding-conventions.md read (always)any types