How do I install the Pmtl Fe Implementation skill?

Run npx skillmds add majiayu000/pmtl-fe-implementation in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pmtl Fe Implementation safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pmtl Fe Implementation?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pmtl Fe Implementation free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pmtl Fe Implementation?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pmtl Fe Implementation by majiayu000

Name: Pmtl Fe Implementation
Rating: 4.5 (4 reviews)
Author: majiayu000

Pmtl Fe Implementation

Frontend implementation rules for PMTL_VN. Use for React or Next.js feature work, UI refactors, and frontend code reviews that should follow repo conventions, human-like code quality, and strict production-ready discipline.

majiayu000 661cf55 2 files · 4.1 KB Updated Sep 9, 2026 567 repo stars

File contents

PMTL Frontend Implementation

Purpose

Guide day-to-day React and Next.js implementation in PMTL so frontend work stays feature-first, type-safe, and production-ready.

Use When

Adding or refactoring frontend features in apps/web.
Updating client/server boundaries, component structure, or fetch flows.
Reviewing whether a frontend change follows PMTL implementation habits.

Required Inputs

touched route, feature folder, or component boundary
current owner docs when the surface already exists
verification scope expected after the edit

Expected Output

Frontend code placed in the right layer with clear domain ownership.
No placeholder branches, weak typing, or accidental client-side sprawl.

Read First

AGENTS.md
design/ui/PAGE_INVENTORY.md when route or page purpose matters
design/ui/USER_FLOWS.md when the work changes journey behavior
design/ui/COMPONENT_SPECS.md or module owner docs when component or domain rules already exist

Execution Approach

Inspect the existing feature folder before creating new abstractions.
Default to Server Components and only move to the client when interactivity requires it.
Keep data contracts typed and validated close to the boundary.
Finish with a verification pass through the quality gate.

Core rules

Default to Server Components. Add "use client" only for real interactivity.
Reuse existing feature folders before creating new shared abstractions.
Keep code flat with early returns and domain naming.
Never ship TODO, placeholder comments, or half-finished state branches.
Validate API inputs and responses with Zod-backed shapes.
Avoid any. Use narrow unions and explicit types.
Trigger independent async work in parallel.
Add concise comments only when the reason is not obvious from the code.

File placement

Route entrypoints: apps/web/src/app
Feature code: apps/web/src/features/<domain>
Shared web utilities: apps/web/src/lib
Shared UI primitives: apps/web/src/components

Verification

Run py infra/tools/codex_actions.py quality-gate --scope web after meaningful changes.
Recheck that the final file placement still respects feature-first boundaries.
If the change touched route behavior, compare the implemented surface against the relevant design/ui/* owner docs.
If the change touched auth/search/runtime boundaries, pair with the narrower verification skill instead of relying on web-only checks.

Edge Cases

Quick fixes often leak business logic into route files or shared UI.
Over-eager client components usually indicate missing server-first design, not a requirement.

References

AGENTS.md
docs/architecture/conventions.md
design/ui/PAGE_INVENTORY.md
design/ui/USER_FLOWS.md
design/ui/COMPONENT_SPECS.md
apps/web/src/features

Pair with

pmtl-ui-behavior for accessibility, forms, and state discipline.
pmtl-ui-style-system for visual direction.
vercel-react-best-practices when performance is part of the task.

---name: pmtl-fe-implementationdescription: Frontend implementation rules for PMTL_VN. Use for React or Next.js feature work, UI refactors, and frontend code reviews that should follow repo conventions, human-like code quality, and strict production-ready discipline.--- # PMTL Frontend Implementation ## Purpose Guide day-to-day React and Next.js implementation in PMTL so frontend work stays feature-first, type-safe, and production-ready. ## Use When - Adding or refactoring frontend features in `apps/web`. - Updating client/server boundaries, component structure, or fetch flows. - Reviewing whether a frontend change follows PMTL implementation habits. ## Required Inputs - touched route, feature folder, or component boundary - current owner docs when the surface already exists - verification scope expected after the edit ## Expected Output - Frontend code placed in the right layer with clear domain ownership. - No placeholder branches, weak typing, or accidental client-side sprawl. ## Read First 1. `AGENTS.md` 2. `design/ui/PAGE_INVENTORY.md` when route or page purpose matters 3. `design/ui/USER_FLOWS.md` when the work changes journey behavior 4. `design/ui/COMPONENT_SPECS.md` or module owner docs when component or domain rules already exist ## Execution Approach 1. Inspect the existing feature folder before creating new abstractions. 2. Default to Server Components and only move to the client when interactivity requires it. 3. Keep data contracts typed and validated close to the boundary. 4. Finish with a verification pass through the quality gate. ## Core rules - Default to Server Components. Add `"use client"` only for real interactivity. - Reuse existing feature folders before creating new shared abstractions. - Keep code flat with early returns and domain naming. - Never ship `TODO`, placeholder comments, or half-finished state branches. - Validate API inputs and responses with Zod-backed shapes. - Avoid `any`. Use narrow unions and explicit types. - Trigger independent async work in parallel. - Add concise comments only when the reason is not obvious from the code. ## File placement - Route entrypoints: `apps/web/src/app` - Feature code: `apps/web/src/features/<domain>` - Shared web utilities: `apps/web/src/lib` - Shared UI primitives: `apps/web/src/components` ## Verification - Run `py infra/tools/codex_actions.py quality-gate --scope web` after meaningful changes. - Recheck that the final file placement still respects feature-first boundaries. - If the change touched route behavior, compare the implemented surface against the relevant `design/ui/*` owner docs. - If the change touched auth/search/runtime boundaries, pair with the narrower verification skill instead of relying on web-only checks. ## Edge Cases - Quick fixes often leak business logic into route files or shared UI. - Over-eager client components usually indicate missing server-first design, not a requirement. ## References - `AGENTS.md` - `docs/architecture/conventions.md` - `design/ui/PAGE_INVENTORY.md` - `design/ui/USER_FLOWS.md` - `design/ui/COMPONENT_SPECS.md` - `apps/web/src/features` ## Pair with - `pmtl-ui-behavior` for accessibility, forms, and state discipline. - `pmtl-ui-style-system` for visual direction. - `vercel-react-best-practices` when performance is part of the task.

Frequently asked questions