
Prowler UI Patterns
FreeStreamline UI development with Prowler-specific conventions.
Free · Opens the source repo
What Prowler UI Patterns does
Prowler UI Patterns is designed to assist developers working within the Prowler project, specifically in the ui/ directory. This skill provides guidance on adhering to Prowler's unique UI conventions, which include using the shadcn/ui component library in conjunction with Tailwind CSS for styling. By following the established patterns, developers can ensure consistency and maintainability across the codebase. The skill emphasizes the importance of reusing components and adhering strictly to the design system, which is the single source of truth for UI elements.
The skill outlines critical rules for component placement and styling, ensuring that new UI primitives are correctly categorized and that existing components are reused rather than reinvented. It also provides a clear structure for organizing code, including where to place server actions, types, hooks, and utilities. This structured approach helps prevent confusion and promotes best practices within the development team.
For teams working on the Prowler project, this skill is invaluable as it not only enforces design discipline but also streamlines the development process by reducing the likelihood of errors related to UI component usage. Developers can quickly reference the rules and guidelines to ensure they are following the correct procedures, saving time and effort in the long run. This skill is particularly useful for new team members who may be unfamiliar with the Prowler-specific conventions.
Overall, Prowler UI Patterns is an essential tool for any developer involved in UI work within the Prowler ecosystem, providing clarity and consistency in UI development.
When to use it
Use this skill when developing UI components for the Prowler project to ensure compliance with established patterns.
When not to use it
This skill is not suitable for projects outside the Prowler ecosystem or for generic UI development.
What you can build with it
Onboarding New Developers
New team members can quickly understand the UI conventions and rules through this skill, facilitating smoother onboarding.
Maintaining UI Consistency
Developers can reference the skill to ensure all UI components adhere to the established design guidelines, maintaining consistency.
Reviewing UI Pull Requests
When reviewing PRs, developers can use this skill to identify and flag any violations of the component usage rules.
How to install Prowler UI Patterns
View source1. Install with the skills CLI
npx skills add prowler-cloud/prowler/prowler-ui --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by prowler-cloudRelated Generic Skills
typescript- Const types, flat interfacesreact-19- No useMemo/useCallback, compilernextjs-16- App Router, Server Actionstailwind-4- cn() utility, styling ruleszod-4- Schema validationzustand-5- State managementai-sdk-5- Chat/AI featuresplaywright- E2E testing (see alsoprowler-test-ui)
Tech Stack (Versions)
Next.js 16.2.3 | React 19.2.5 | Tailwind 4.1.18 | shadcn/ui
Zod 4.1.11 | React Hook Form 7.62.0 | Zustand 5.0.8
NextAuth 5.0.0-beta.30 | Recharts 2.15.4
CRITICAL: Component Library Rule
- ALWAYS: Use
shadcn/ui+ Tailwind (components/shadcn/) - NEVER: Add components to
components/ui/(temporary re-export shims for the prowler-cloud overlay only)
Design System Discipline (REQUIRED)
Applies to ALL UI work. The design system is the single source of truth — reuse it exactly, extend it deliberately.
- Reuse first, never reinvent. Before building anything, search
components/shadcn/and existing usages in the codebase for an equivalent. Do NOT create a custom component, modal wrapper, or primitive when one already exists. - Use exactly the defined variants/styles — no more, no less. At the call site, drive appearance through the component's
variant/size/toneprops. Never add ad-hoc visualclassName(color, opacity, hover/focus/disabled, spacing-for-looks) to shared controls (Button,SelectTrigger,SelectItem,Modal, badges…), and never skip the correct semantic variant. - Modals: only
@/components/shadcn/modal. Selects:components/shadcn/select. - Colors: reuse existing semantic tokens from
ui/styles/globals.css. No raw Tailwind color utilities (e.g.bg-blue-950/40), no hex. If no token fits, STOP and ask the design owner — do not invent or near-duplicate tokens. - Need a genuinely new variant/token? That is a design-system change: add it to the shared component API (with design sign-off), then consume it. It is never a call-site decision.
When reviewing UI PRs, flag: custom modals/primitives that duplicate shadcn, call-site visual className on shared controls, raw color utilities, and new variants/tokens introduced without going through the shared component API.
DECISION TREES
Component Placement
New UI primitive? → components/shadcn/ (shadcn/ui + Tailwind)
Used by 1 domain? → components/{domain}/
Used by 2+ domains? → components/shared/
Needs state/hooks? → "use client"
Server component? → No directive needed
Code Location
Server action → actions/{feature}/{feature}.ts
Data transform → actions/{feature}/{feature}.adapter.ts
Types (shared 2+) → types/{domain}.ts
Types (local 1) → {feature}/types.ts
Utils (shared 2+) → lib/
Utils (local 1) → {feature}/utils/
Hooks (shared 2+) → hooks/
Hooks (local 1) → {feature}/hooks.ts
UI primitive → components/shadcn/
Domain component → components/{domain}/
Deprecated:
components/ui/is a temporary re-export shim that maps legacy import paths tocomponents/shadcn/for the prowler-cloud overlay. HeroUI is fully removed. Never add or import components here — use@/components/shadcn(primitives) or@/components/{domain}instead. Delete the shim once the cloud repo migrates to@/components/shadcn.
Styling Decision
Tailwind class exists? → className
Dynamic value? → style prop
Conditional styles? → cn()
Static only? → className (no cn())
Recharts/library? → CHART_COLORS constant + var()
Scope Rule (ABSOLUTE)
- Used 2+ places →
lib/ortypes/orhooks/(components go incomponents/{domain}/) - Used 1 place → keep local in feature directory
- This determines ALL folder structure decisions
Project Structure
ui/
├── app/
│ ├── (auth)/ # Auth pages (login, signup)
│ └── (prowler)/ # Main app
│ ├── compliance/
│ ├── findings/
│ ├── providers/
│ ├── scans/
│ ├── services/
│ └── integrations/
├── components/
│ ├── shadcn/ # shadcn/ui primitives (USE THIS)
│ ├── shared/ # Cross-domain composed components (2+ domains)
│ ├── ui/ # DEPRECATED shim → re-exports shadcn (do not use)
│ ├── {domain}/ # Domain-specific (compliance, findings, providers, etc.)
│ ├── filters/ # Filter components
│ ├── graphs/ # Chart components
│ └── icons/ # Icon components
├── actions/ # Server actions
├── types/ # Shared types
├── hooks/ # Shared hooks
├── lib/ # Utilities
├── store/ # Zustand state
├── tests/ # Playwright E2E
└── styles/ # Global CSS
Recharts (Special Case)
For Recharts props that don't accept className:
const CHART_COLORS = {
primary: "var(--color-primary)",
secondary: "var(--color-secondary)",
text: "var(--color-text)",
gridLine: "var(--color-border)",
};
// Only use var() for library props, NEVER in className
<XAxis tick={{ fill: CHART_COLORS.text }} />
<CartesianGrid stroke={CHART_COLORS.gridLine} />
Form + Validation Pattern
"use client";
import { useForm } from "react-hook-form";
import { zodResolver } from "@hookform/resolvers/zod";
import { z } from "zod";
const schema = z.object({
email: z.email(), // Zod 4 syntax
name: z.string().min(1),
});
type FormData = z.infer<typeof schema>;
export function MyForm() {
const { register, handleSubmit, formState: { errors } } = useForm<FormData>({
resolver: zodResolver(schema),
});
const onSubmit = async (data: FormData) => {
await serverAction(data);
};
return (
<form onSubmit={handleSubmit(onSubmit)}>
<input {...register("email")} />
{errors.email && <span>{errors.email.message}</span>}
<button type="submit">Submit</button>
</form>
);
}
Commands
# Development
cd ui && pnpm install
cd ui && pnpm run dev
# Code Quality
cd ui && pnpm run typecheck
cd ui && pnpm run lint:fix
cd ui && pnpm run format:write
cd ui && pnpm run healthcheck # typecheck + lint
# Testing
cd ui && pnpm run test:e2e
cd ui && pnpm run test:e2e:ui
cd ui && pnpm run test:e2e:debug
# Build
cd ui && pnpm run build
cd ui && pnpm start
Batch vs Instant Component API (REQUIRED)
When a component supports both batch (deferred, submit-based) and instant (immediate callback) behavior, model the coupling with a discriminated union — never as independent optionals. Coupled props must be all-or-nothing.
// ❌ NEVER: Independent optionals — allows invalid half-states
interface FilterProps {
onBatchApply?: (values: string[]) => void;
onInstantChange?: (value: string) => void;
isBatchMode?: boolean;
}
// ✅ ALWAYS: Discriminated union — one valid shape per mode
type BatchProps = {
mode: "batch";
onApply: (values: string[]) => void;
onCancel: () => void;
};
type InstantProps = {
mode: "instant";
onChange: (value: string) => void;
// onApply/onCancel are forbidden here via structural exclusion
onApply?: never;
onCancel?: never;
};
type FilterProps = BatchProps | InstantProps;
This makes invalid prop combinations a compile error, not a runtime surprise.
Reuse Shared Display Utilities First (REQUIRED)
Before adding local display maps (labels, provider names, status strings, category formatters), search ui/types/* and ui/lib/* for existing helpers.
// ✅ CHECK THESE FIRST before creating a new map:
// ui/lib/utils.ts → general formatters
// ui/types/providers.ts → provider display names, icons
// ui/types/findings.ts → severity/status display maps
// ui/types/compliance.ts → category/group formatters
// ❌ NEVER add a local map that already exists:
const SEVERITY_LABELS: Record<string, string> = {
critical: "Critical",
high: "High",
// ...duplicating an existing shared map
};
// ✅ Import and reuse instead:
import { severityLabel } from "@/types/findings";
If a helper doesn't exist and will be used in 2+ places, add it to ui/lib/ or ui/types/ and reuse it. Keep local only if used in exactly one place.
Derived State Rule (REQUIRED)
Avoid useState + useEffect patterns that mirror props or searchParams — they create sync bugs and unnecessary re-renders. Derive values directly from the source of truth.
// ❌ NEVER: Mirror props into state via effect
const [localFilter, setLocalFilter] = useState(filter);
useEffect(() => { setLocalFilter(filter); }, [filter]);
// ✅ ALWAYS: Derive directly
const localFilter = filter; // or compute inline
If local state is genuinely needed (e.g., optimistic UI, pending edits before submit), add a short comment:
// Local state needed: user edits are buffered until "Apply" is clicked
const [pending, setPending] = useState(initialValues);
Strict Key Typing for Label Maps (REQUIRED)
Avoid Record<string, string> when the key set is known. Use an explicit union type or a const-key object so typos are caught at compile time.
// ❌ Loose — typos compile silently
const STATUS_LABELS: Record<string, string> = {
actve: "Active", // typo, no error
};
// ✅ Tight — union key
type Status = "active" | "inactive" | "pending";
const STATUS_LABELS: Record<Status, string> = {
active: "Active",
inactive: "Inactive",
pending: "Pending",
// actve: "Active" ← compile error
};
// ✅ Also fine — const satisfies
const STATUS_LABELS = {
active: "Active",
inactive: "Inactive",
pending: "Pending",
} as const satisfies Record<Status, string>;
QA Checklist Before Commit
-
pnpm run typecheckpasses -
pnpm run lint:fixpasses -
pnpm run format:writepasses - Relevant E2E tests pass
- All UI states handled (loading, error, empty)
- No secrets in code (use
.env.local) - Error messages sanitized (no stack traces to users)
- Server-side validation present (don't trust client)
- Accessibility: keyboard navigation, ARIA labels
- Mobile responsive (if applicable)
Pre-Re-Review Checklist (Review Thread Hygiene)
Before requesting re-review from a reviewer:
- Every unresolved inline thread has been either fixed or explicitly answered with a rationale
- If you agreed with a comment: the change is committed and the commit hash is mentioned in the reply
- If you disagreed: the reply explains why with clear reasoning — do not leave threads silently open
- Re-request review only after all threads are in a clean state
Resources
- Documentation: See references/ for links to local developer guide
Frequently asked questions about Prowler UI Patterns
Similar skills
Playwright Component Testing
Test React and Vue components in isolation with Playwright.
Fluent UI Blazor
Integrate Fluent UI components in Blazor applications effortlessly.
Build MCP App
Create interactive UI widgets for MCP servers.
Web Design Reviewer
Identify and fix design issues in websites efficiently.
Markstream Install
Seamlessly integrate Markstream for Markdown rendering.
GSAP & Framer Scroll Animation
Create advanced scroll animations effortlessly.
