---
name: erp-kit-app-6-impl-frontend
description: Implement frontend code for applications. Use after deploying the backend with erp-kit-app-5-impl-backend. Triggers when implementing frontend pages, creating React components from screen specs, or when the user mentions implementing frontend, creating pages, or building UI for an application.
metadata:
  erp-kit-version: "0.23.0"
---

# Application Frontend Implementation

Implement frontend pages for an application, driven by screen spec documentation and a deployed backend. This phase adapts the existing frontend to match the actual requirements.

## Version Check

Run `npx erp-kit --version` and compare against this skill's `metadata.erp-kit-version`. If they differ, the local skills are outdated — tell the user to run `pnpm erp-kit update skills` and stop.

## Progress Logging

Run `npx erp-kit app progress schema` once to load the schema before your first log. Log at every step boundary marked with **Log:** below using `npx erp-kit app progress log --json '<payload>'`. Every payload requires: `v` (always `1`), `sessionId`, `prompt` (user's original request), `event`, `data`, and `conversation` (array of `{role, message}` since last log). See [progress-protocol.md](../erp-kit-shared/references/progress-protocol.md) for the full schema reference.

## When to Use

- Implementing frontend pages from screen spec docs
- Creating React components for ListView, Form, or DetailView screens
- Building the frontend UI for an application after backend deployment

## Prerequisites

- Deployed backend (from `erp-kit-app-5-impl-backend`)
- `.env` with `VITE_TAILOR_APP_URL` and `VITE_TAILOR_CLIENT_ID`
- All four tiers of documentation:
  - `README.md` — Application overview
  - `docs/actors/*.md` — Actor definitions
  - `docs/business-flow/*/README.md` + `story/*.md` — Business flows and user stories
  - `docs/screen/*.md` — Screen specifications (ListView, Form, DetailView)

> **Log:** `step.start` with `data: { skill: "erp-kit-app-6-impl-frontend", context: { app: APP_NAME, screens: count } }`

## Workflow

```
ANALYZE SCREENS → GENERATE GRAPHQL SCHEMA → IMPLEMENT PAGES → VERIFY
```

### Phase 1: Analyze Screen Documentation

Read all screen specs (`docs/screen/*.md`) to build a complete picture:

> **Parallelize if possible:** Dispatch one agent per screen spec to extract page structure, fields, actions, and navigation. Each agent reads a single screen doc and returns structured analysis.

1. **Screen types** — Identify each screen as ListView, Form (create/edit), or DetailView
2. **Fields and columns** — Map required columns (ListView), form fields (Form), and detail fields (DetailView) from each spec
3. **Actions** — Identify navigation actions (create, edit, back-to-list) and mutation actions (save, delete, activate/deactivate)

### Phase 2: Generate GraphQL Schema

Run `pnpm generate` in the frontend directory to fetch the GraphQL schema from the deployed backend.

> **Sync barrier:** Schema generation must complete before page implementation. Generated types are shared across all pages.

### Phase 2b: Code Orientation

Read existing pages under `src/pages/` to understand the page patterns (ListView, Form, DetailView), component structure, and GraphQL fragment conventions. Keep what applies, adapt what's close, and remove what doesn't fit.

**Read [project-setup.md](references/project-setup.md)** for routing, authentication, and sidebar conventions. This is read once and not needed per-page.

**Read [styling.md](references/styling.md)** for theming and component styling conventions.

### Phase 3: Implement Frontend Pages

> **Barrier step:** Write shared layout and router files before dispatching page agents. These files are shared across all pages and must not be modified by individual page agents.

Run `pnpm lint`, `pnpm typecheck`, and `pnpm gql-tada:check` regularly during implementation. Fix errors before moving on.

Create pages driven by screen spec docs. Each screen type has a standard implementation pattern.

> **Parallelize if possible:** Dispatch one agent per screen. Each agent writes only to its own directory:
> - `src/pages/<screen-name>/`
>
> **Shared-file guard:** Layout files, router configuration, and generated types are written before dispatch. Page agents must NOT modify shared files.

**Reference loading (per screen type):**

| Screen type        | Required references                                                            |
| ------------------ | ------------------------------------------------------------------------------ |
| All                | [page-common.md](references/page-common.md)                                   |
| ListView           | + [page-list.md](references/page-list.md)                                     |
| Form (create/edit) | + [page-form.md](references/page-form.md)                                     |
| DetailView         | + [page-detail.md](references/page-detail.md)                                 |

> **Sub-agent dispatch:** Each page agent reads ONLY the references matching its screen type. Do NOT load all references into every agent.

### Phase 3b: Implement E2E Page Objects and Specs

After implementing frontend pages, create E2E test infrastructure:

1. **Page objects** — One per screen doc, grouped by domain under `e2e/pages/`
2. **Spec-specific fixtures** — One fixture file per spec file under `e2e/fixtures/` (same basename), extending `user.ts` with test-scoped fixtures for data needed by that spec
3. **Spec files** — One per business flow under `e2e/tests/`, with `test.describe` per story and `test()` per scenario pattern. Import `test`/`expect` from the spec's own fixture file
4. **Actor fixtures** — Define in `e2e/fixtures/user.ts` with `Actor` type union matching `docs/actors/` filenames

**Read [e2e testing reference](references/e2e-testing.md)** for page object patterns, fixture setup, spec file structure, and sync check rules.

### Phase 4: Verify

```bash
cd <app-root>/frontend
pnpm lint
pnpm typecheck
pnpm gql-tada:check
pnpm build
```

> **Log:** `validation` with `data: { command: "pnpm lint && pnpm typecheck && pnpm build", status: "pass"|"fail", issues: [] }`

> **Log:** `step.complete` with `data: { status: "pass"|"fail"|"blocked", summary: "<one-line result with page counts>", artifacts: ["<list of created page paths>"] }`

After verification passes, proceed to implementation review with `/erp-kit-app-7-impl-review`.
