Implement

Implement Use Case

Instructions

Implement $ARGUMENTS using Next.js App Router for both the UI and API layer. $ARGUMENTS can be a use case (UC-XXX), a technical task (TT-XXX), or a bug fix (BUG-XXX). Write unit tests alongside the implementation. Integration tests (vitest-test) and e2e tests (playwright-test) are separate skills.

Use the context7 MCP server to look up Next.js documentation when needed.

DO NOT

• Create integration or e2e tests (use dedicated testing skills instead)
• Use the Pages Router (use App Router exclusively)
• Use raw SQL queries (use Prisma Client)
• Use client components when server components suffice
• Put database calls in client components or API routes called only by server components
• Make implementation decisions without documenting their provenance (EXPLICIT vs INFERRED)
• Over-engineer — implement only what the specification requires. No speculative abstractions, unnecessary indirection, premature generalisation, or features not in the spec. Three similar lines of code are better than a premature abstraction. If a simple approach satisfies the requirement, use it.

Nexa Rules Gate

Read and follow ${CLAUDE_PLUGIN_ROOT}/shared/readiness/NEXA_RULES_GATE.md.

Sprint Branch Gate

Read and follow ${CLAUDE_PLUGIN_ROOT}/shared/readiness/SPRINT_BRANCH_GATE.md.

Project Readiness Gate

Read and follow ${CLAUDE_PLUGIN_ROOT}/shared/readiness/PROJECT_READINESS.md.

This gate checks that cross-cutting infrastructure (middleware, error logging, security headers, environment configuration) exists before use case implementation begins. It applies to UC-XXX items only — TT-XXX and BUG-XXX items skip this gate.

Do not proceed with implementation until all items pass or the user explicitly waives failures.

DoR Check

• For UC-XXX: Read and follow ${CLAUDE_PLUGIN_ROOT}/shared/readiness/DEFINITION_OF_READY.md.
• For TT-XXX: Read and follow ${CLAUDE_PLUGIN_ROOT}/shared/readiness/DEFINITION_OF_READY_TT.md.
• For BUG-XXX: Read and follow ${CLAUDE_PLUGIN_ROOT}/shared/readiness/DEFINITION_OF_READY_BUG.md.

Do not proceed with implementation until all items pass or the user explicitly waives failures.

Tracking

Read and follow the Before Implementation steps in ${CLAUDE_PLUGIN_ROOT}/shared/tracking/TRACKING.md.

Test Data Conventions

• Use only example.com for test emails and accounts (e.g., user@example.com, admin@example.com). This is an IANA-reserved domain that will never route real mail.

Workflow

1. Read the specification:

• For UC-XXX: Read the use case specification from docs/use_cases/
• For TT-XXX: Read the technical task specification from docs/technical_tasks/
• For BUG-XXX: Read the bug report from docs/bugs/

1. Read the entity model from docs/entity_model.md (if applicable)
2. Read the design artifact from docs/designs/ (if it exists for this UC). When a design artifact exists, the implementation must match the specified screens, layout, components, states, and navigation flow.
3. Read project design rules from docs/designs/DESIGN_RULES.md (if it exists). These are project-specific constraints — e.g., shared layout elements (header, footer, sidebar), mandatory components, or navigation patterns — that every implementation must follow. Missing a shared element specified in design rules is a defect.
4. Check existing code for patterns and conventions
5. i18n Detection — Always check whether the project uses internationalization.

First, check the project's CLAUDE.md for the marker `. If absent, fall back to looking for i18n indicators: translation/message files, i18n configuration, locale directories, translation function imports (useTranslations, getTranslations, t(), intl, etc.), locale-based routing segments ([locale], [lang]), or i18n libraries in package.json (e.g., next-intl, react-intl, react-i18next, i18next`). If any i18n setup is found, all user-facing strings in this implementation MUST use the project's established translation pattern:

• Study how existing pages use translations and follow the same pattern
• For every new page or section, add translation keys to all locale files following

the project's existing file structure and naming conventions

• User-facing error messages in server actions and API route handlers must also use

translation keys, not hardcoded strings

• Use the project's localized navigation utilities if they exist, instead of raw framework imports
• Place new pages under the locale route segment if the project uses locale-based routing

1. Implement API route handlers (if needed for client-side fetching):

• Create route handlers in app/api/**/route.ts
• Export named functions matching HTTP methods (GET, POST, PUT, DELETE)
• Validate request bodies with zod
• Use Prisma Client for data access
• Return NextResponse.json() with appropriate status codes

1. Implement server actions (if needed for form mutations):

• Create actions in app/actions/ or colocate with the page
• Mark with "use server" directive
• Validate input with zod
• Use Prisma Client for data access
• Call revalidatePath() or revalidateTag() for cache invalidation

1. Implement the UI:

• Create or update page.tsx and layout.tsx files
• Use server components by default for data fetching with Prisma
• Use client components ("use client") only for interactivity (forms, event handlers, state)
• Create reusable UI components in components/
• Handle loading states with loading.tsx
• Handle errors with error.tsx
• Handle empty states
• When a design artifact exists, match the specified layout, components, states, and navigation
• When project design rules exist (read in step 4), enforce every rule — e.g., include shared layout elements, follow mandatory navigation patterns, and apply required brand guidelines
• When i18n is active (detected in step 6), every user-facing string must use the project's translation pattern — no hardcoded text in JSX
• When implementing forms where users enter data, always add client-side and server-side validation:
• Define a zod schema for each form's input fields
• Apply client-side validation to show inline field errors before submission
• Validate again on the server side in the server action or API route handler (never trust client-only validation)
• Display server-side validation errors back to the user

1. Write unit tests for the implemented logic:

• Test API route handlers with mocked Prisma Client
• Test server actions with mocked dependencies
• Test client components with React Testing Library
• When forms are involved, write dedicated validation unit tests:
• Test the zod schema directly: valid inputs pass, invalid inputs produce the expected errors
• Test that server actions and API route handlers reject invalid input and return appropriate error responses
• Test that form components display validation errors for invalid input
• Run tests with npx vitest run to verify they pass

1. Run the /code-quality skill
2. Verify the implementation compiles successfully with next build
3. Document implementation decisions in a DECISIONS.md file (or in the PR description):

• For each non-trivial decision made during implementation, record:
• Decision: What was decided
• Provenance: EXPLICIT (from spec/requirements) or INFERRED (agent reasoning)
• Source/Reasoning: Quote the source document or explain the reasoning
• INFERRED decisions are candidates for stakeholder review before merge

Post-Implementation Tracking

Read and follow the After Implementation steps in ${CLAUDE_PLUGIN_ROOT}/shared/tracking/TRACKING.md.

Resources

• Use the context7 MCP server for Next.js documentation

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: nexadevapp
• Source: nexadevapp/nexa-claude-skills-marketplace
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.