frontend

What this skill does

# Frontend Skill

Use this as the single entrypoint for all frontend work in any repo shape.

## When to Use This Skill

- The user wants frontend help in a plain app, design-system, or monorepo.
- You need a stable frontend workflow that adapts to the repo instead of
  assuming a specific stack.
- You want later tasks to reuse a persistent repo-local digest instead of
  rediscovering tooling every session.

## Example Prompts

- `/frontend:work review 123` - Review PR #123 with thread-aware context.
- `/frontend:work api feedback` - Implement or debug frontend API integration
  for the "feedback" flow.
- `/frontend:work testing` - Run, add, or repair tests using the detected
  frontend test stack.
- `/frontend:refresh-digest` - Recompute and persist
  `docs/frontend-skill-digest/AGENTS.md` and
  `docs/frontend-skill-digest/project-digest.md`.
- `/frontend:work new-branch 45 digest-contract-fix` - Create a branch using
  the repo's detected branch model.
- `/frontend:work commit "align frontend digest contract"` - Create an atomic
  commit using detected repo conventions.

## Digest-First Preflight

Every frontend task starts here.

### 1. Load the digest

Read both files from the target repo:

- `docs/frontend-skill-digest/AGENTS.md`
- `docs/frontend-skill-digest/project-digest.md`

### 2. Evaluate freshness

Treat the digest as stale when any of these changed since the last run:
lockfile, workspace layout, primary framework, testing stack,
analytics/observability stack, design-system ownership, API contract source,
or backend directory mapping.

Freshness evidence in the digest (when present): generated commit SHA,
inspected file list, key file hashes or mtimes.

### 3. Decide persist vs ephemeral

- **User ran `/frontend:refresh-digest`**: run full detection (see Detection
  Workflow below) and **persist** the result to `docs/frontend-skill-digest/`.
- **User ran any other command**: if the digest is missing or stale, run
  **ephemeral inline detection** (no file writes). Detect package manager,
  framework, workspace layout, AND lane-specific facts relevant to the
  requested lane (API contract sources, analytics stack, observability stack,
  CI provider, test stack, branch model). Proceed with reduced confidence and
  note the missing digest in output.

Do not silently write digest files outside of `/frontend:refresh-digest`.

### 4. Anti-assumptions

Do not assume: `yarn`, `dev` / `main`, React Query, axios, styled-components,
Playwright, CloudFlare / Crafting, Sentry, or Mixpanel. Use what the digest or
inline detection finds.

## Detection Workflow

Follow this order when persisting a full digest.

1. **Classify the repo** — `frontend-app`, `design-system`,
   `monorepo-frontend`, or `unknown`. Use workspace manifests, package layout,
   Storybook/token packages, app entrypoints, framework markers, internal
   package relationships.
2. **Detect package and workspace tooling** — package manager, workspace
   system, install command, likely lint/type-check/unit/E2E commands.
3. **Detect framework and rendering model** — React, Next.js, Vite, Remix,
   Storybook, library-only, SSR/SPA/component-library hints.
4. **Detect styling and design-system stack** — styled-components, Emotion,
   Tailwind, CSS Modules, Sass, component libraries, token packages, whether
   the repo publishes/consumes a design system.
5. **Detect data, state, and API patterns** — React Query, RTK Query, Redux,
   Zustand, Apollo, fetch wrappers, generated clients, endpoint registries.
   Determine API contract sources in ranked order (generated SDK, OpenAPI,
   Bruno/Postman, local backend, external backend).
6. **Detect testing stack** — Vitest, Jest, RTL, Playwright, Cypress,
   Storybook visual tests, workspace scoping.
7. **Detect analytics and observability** — Mixpanel, PostHog, Segment,
   Sentry, LogRocket, Datadog RUM. Do not force a tool if none is present.
8. **Detect CI/CD and workflow conventions** — CI provider, deploy platform,
   preview/sandbox tooling, release workflows, default branches, docs/planning
   folder conventions.
9. **Write applicability guidance** — mark each lane as `applies`, `partial`,
   or `out_of_scope`.

### Digest output

Write to `docs/frontend-skill-digest/AGENTS.md` (operating contract) and
`docs/frontend-skill-digest/project-digest.md` (full fingerprint). Both files
have required schemas defined in `references/digest-schema.md`.

Include freshness evidence: generated commit SHA, inspected file list, key
file hashes or mtimes.

## Lane Routing

After loading or detecting context, route the work into one lane.

### refresh-digest

Run the full Detection Workflow and persist both
`docs/frontend-skill-digest/AGENTS.md` and
`docs/frontend-skill-digest/project-digest.md`.

This is the only lane allowed to write digest files to the repo.

### review

PR review using Bumang-style priorities. Collect inline review threads,
resolved comments, and author replies via `gh api` for thread-aware review.

See `references/review.md` and `references/review-taste.md`.

### api

Frontend API integration using the repo's real contract source.

See `references/api-integration.md`.

### testing

Unit, component, integration, and E2E testing using detected stack.

See `references/testing.md`.

### analytics

Analytics tracking (Mixpanel, PostHog, Segment, etc.). Verify the tool
exists before proceeding; refuse if absent.

See `references/analytics.md`.

### observability

Error monitoring and observability (Sentry, LogRocket, Datadog RUM, etc.).
Verify the tool exists before proceeding; refuse if absent.

See `references/observability.md`.

### cicd

CI/CD pipeline debugging, deploy, preview, and release workflows.

See `references/cicd.md`.

### plan / new-branch

Feature planning and branch creation using detected conventions.

See `references/planning.md`.

### commit / pre-commit

Atomic commit creation and pre-commit quality gates.

See `references/commit-hygiene.md`.

### create-pr

PR creation using detected branch model, templates, and quality gates.

See `references/pr-workflow.md`.

## Applicability Rules

The digest must identify which lanes are safe:

- `design-system` repos: review, testing, planning, CI/CD, and
  release-dependency review usually apply. API integration or app analytics
  may be out of scope.
- `frontend-app` repos: all lanes may apply depending on local tooling.
- `monorepo-frontend` repos: lanes must identify the affected package(s)
  before choosing commands.

If the user requests a lane that does not fit the repo type, explain why and
stop or narrow the task.

## Missing Context Rules

Do not guess when important context is absent.

- If the frontend consumes an API but the contract lives only in a separate
  backend repo, record that and ask for a backend directory.
- If the repo has Bruno collections but no backend code, prefer Bruno as the
  contract source.
- If the repo has OpenAPI/Swagger, prefer that over reverse-engineering.
- If the repo is a monolith with frontend and backend together, detect the
  local backend path instead of asking.

## Output Expectations

When this skill is active:

- Mention whether you reused, refreshed, or ran ephemeral detection for the
  digest.
- State the detected repo class and the lane chosen.
- Name any missing context you had to ask for.
- Keep guidance repo-aware and dynamic.