plcode-linux-x64-baseline 2.1.0

package/.plcode/skill/core/frontend-design/SKILL.md

@@ -0,0 +1,516 @@
+---
+name: frontend-design
+description: Design and build distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, applications, dashboards, landing pages, prototypes, posters, or any UI work. Drives a structured workflow — brief, context, design system, build, verify — producing polished React/Next.js/HTML code that avoids generic AI aesthetics.
+category: design
+---
+
+# Frontend Design
+
+A structured design skill for building production-grade frontend interfaces in PLCODE's stack (Bun, TypeScript, React, Next.js, Tailwind CSS, shadcn/ui). This skill drives a complete workflow from brief to verified artifact, producing distinctive work that avoids generic AI aesthetics.
+
+## When To Use
+
+Use this skill for:
+
+- Landing pages and marketing surfaces
+- Dashboard concepts and data-rich UIs
+- High-fidelity interactive prototypes
+- React/Next.js component explorations
+- Design system previews and component labs
+- Visual option boards and comparison layouts
+- Onboarding flows, settings panels, modals, cards, forms, empty states
+- Redesigns based on screenshots, repos, brand docs, or UI kits
+- Any UI work where visual quality matters
+
+## Core Identity
+
+Act as an expert designer working with the user as the manager. The medium adapts to the assignment:
+
+- **UX designer** for flows and product surfaces
+- **Visual designer** for static explorations and marketing
+- **Interaction designer** for prototypes with state and transitions
+- **Component designer** for design system tokens and component variants
+- **Motion designer** for animated artifacts and micro-interactions
+- **Frontend engineer** for production-ready React/Next.js code
+
+Avoid generic web-design tropes unless the user explicitly asks for a conventional page.
+
+## Workflow
+
+Follow this sequence for every design task. Do not skip steps.
+
+### 1. Understand the Brief
+
+Before writing any code, answer these questions (internally or by asking the user):
+
+- What is being designed?
+- Who is it for?
+- What artifact should exist at the end? (page, component, prototype, comparison board)
+- What constraints are locked? (framework, brand, accessibility, viewport)
+- What fidelity level is expected? (wireframe, polished concept, production code)
+
+**When to ask questions:** When the assignment is new, ambiguous, high-fidelity, externally facing, or depends on taste. Keep questions short and focused — usually 2–4, not ten.
+
+**When to skip questions:** The user gave enough direction, it's a small tweak, it's clearly a continuation, or the missing detail has an obvious default. When proceeding with assumptions, label only the important ones.
+
+Usually ask for:
+
+- Intended output format and fidelity level
+- Audience
+- Brand/design system in play (or reference site to emulate)
+- Number of variations wanted
+- Whether to stay conservative or explore divergent ideas
+
+### 2. Gather Context
+
+Good design does not start from scratch. Before designing, look for source context:
+
+**From the user:**
+
+- Brand docs, design tokens, style guides
+- Existing product screenshots or mockups
+- Reference sites or design systems to emulate
+- Copy docs, content requirements
+- Constraints from product, legal, or engineering
+
+**From the repo (if available):**
+
+- `tailwind.config.ts` — theme tokens, colors, fonts, spacing
+- `globals.css` or global stylesheets — CSS variables, base styles
+- `components/ui/` — existing shadcn/ui components and customizations
+- Layout files (`layout.tsx`) — navigation, footer, shell structure
+- Existing page files — current patterns and conventions
+- `package.json` — available dependencies (motion libraries, icon sets)
+
+The file tree is only the menu. **Read the files that define the visual vocabulary before designing.**
+
+If context is missing and fidelity matters, ask concise focused questions instead of producing a generic mockup.
+
+### 3. Define the Design System for This Artifact
+
+Before writing component code, define these properties — either by extracting from existing context or by making deliberate choices:
+
+- **Colors:** palette, surfaces, text hierarchy, accents, semantic (success/warning/danger)
+- **Typography:** font families, scale, weights, line heights, letter-spacing
+- **Spacing:** base unit, scale progression, section rhythm
+- **Radii:** border-radius tokens for cards, buttons, inputs, badges
+- **Shadows/Elevation:** levels and usage rules
+- **Motion posture:** how things move, duration scale, easing
+- **Component treatment:** button styles, card density, input behavior, nav patterns
+- **Interaction rules:** hover, focus, active, disabled, loading states
+
+Use Tailwind CSS classes and CSS variables as the primary token layer. Extend `tailwind.config.ts` for project-level tokens rather than using inline arbitrary values everywhere.
+
+### 4. Choose the Right Format
+
+Match the artifact format to the assignment:
+
+| Need                       | Format                                            |
+| -------------------------- | ------------------------------------------------- |
+| Static visual comparison   | Side-by-side options on one page                  |
+| Interactive flow/prototype | Clickable multi-state React component             |
+| Component exploration      | Component lab with variants and props controls    |
+| Full page/feature          | Next.js page with real routing and layout         |
+| Standalone deliverable     | Self-contained HTML file (rare in PLCODE context) |
+
+### 5. Build the Artifact
+
+**In the PLCODE repo context:**
+
+- Use the existing stack: React, Next.js, TypeScript, Tailwind CSS, shadcn/ui
+- Follow the repo's component architecture and file conventions
+- Use existing components and tokens — extend, don't reinvent
+- Import from shadcn/ui for base primitives (Button, Card, Dialog, etc.)
+- Use `cn()` utility for conditional class merging
+- Keep components composable and typed
+
+**For standalone HTML artifacts (when requested):**
+
+- Create a descriptive filename (e.g., `Landing Page.html`, `Component Lab.html`)
+- Embed CSS in `<style>`, JS in `<script>`
+- Keep it openable directly in a browser
+- Avoid remote dependencies unless explicitly useful and stable
+- Include responsive behavior unless the format is intentionally fixed-size
+
+**For significant revisions:**
+
+- Preserve previous versions (`v1`, `v2`, etc.) or use in-page toggles for variant exploration
+
+### 6. Verify
+
+Before saying "done," verify as much as the environment allows:
+
+**Minimum:**
+
+- File exists at the stated path
+- Code is syntactically valid TypeScript/TSX
+- No obvious import errors or missing dependencies
+- Tailwind classes are valid
+
+**Better (when tools are available):**
+
+- Run `bun run build` or type-check with `bun tsc --noEmit`
+- Open in browser and check console for errors
+- Inspect at primary viewport (desktop) and responsive breakpoints
+- Test key interactions and state transitions
+- Test light/dark mode if present
+
+If verification is limited by environment, say exactly what was and was not verified. **Never say "done" if the file was not actually written.**
+
+### 7. Report Briefly
+
+Keep final responses short. Include:
+
+- Artifact path(s)
+- What was created
+- Verification status
+- Caveats or assumptions
+- Next suggested action, if useful
+
+Example:
+
+```
+Created: src/components/dashboard/MetricsPanel.tsx
+Three layout variants with density toggle, responsive grid, dark mode support.
+Verified: TypeScript compiles, no lint errors, renders in dev server.
+Next: Pick the strongest direction and I'll refine the data visualization.
+```
+
+---
+
+## Design Quality Standards
+
+### Typography
+
+Use the existing type system if one exists in the project.
+
+If choosing type for a new design:
+
+- **Editorial/content:** Serif or humanist headline with restrained sans body
+- **Software/productivity:** Precise sans with strong numeric treatment (Geist, Inter variants)
+- **Luxury/minimal:** Fewer weights, more spacing discipline
+- **Technical/developer:** Mono accents only for code, not mono everywhere
+- **Playful/friendly:** Rounded geometric sans, generous weight contrast
+
+**Avoid overused defaults** when a stronger choice is appropriate. Do not default to Inter for everything — pick type that serves the specific design's personality. Pair a distinctive display font with a refined body font.
+
+Use type as hierarchy before reaching for boxes, icons, or color. A well-set heading with proper weight, size, and spacing contrast communicates more than a decorated card.
+
+Keep web font families and weights low (2 families, 3–4 weights max).
+
+### Color
+
+Use brand/design-system colors first. Use Tailwind's color system as the foundation.
+
+If no palette exists:
+
+- Define a small, intentional system: neutrals, surfaces, ink, muted text, borders, accent, semantic states
+- Use one primary accent unless the assignment calls for a broader palette
+- Dominant colors with sharp accents outperform timid, evenly-distributed palettes
+- Check contrast for important text and controls (WCAG AA minimum)
+- Support both light and dark modes via Tailwind's `dark:` variant
+
+Do not invent lots of colors from scratch. Constraint breeds coherence.
+
+### Layout and Composition
+
+Design with rhythm and intention:
+
+- **Scale:** Size contrast creates hierarchy naturally
+- **Whitespace:** Generous negative space OR controlled density — both work, choose deliberately
+- **Alignment:** Consistent grid with purposeful breaks
+- **Repetition:** Consistent treatment of similar elements
+- **Contrast:** Visual weight differences guide the eye
+- **Interruption:** Break patterns at key moments to create focus
+
+Use CSS Grid and Flexbox through Tailwind utilities. Use `container` queries when component-level responsiveness matters.
+
+Avoid making every section the same card grid. For product UIs, prioritize speed of comprehension over decoration. For marketing surfaces, make one idea land per section.
+
+### Motion and Animation
+
+Use motion as discipline, not theater.
+
+**Good motion:**
+
+- Clarifies state changes (enter/exit transitions)
+- Reduces anxiety during loading (skeleton screens, progress)
+- Shows continuity between surfaces (page transitions, expand/collapse)
+- Gives controls tactility (hover, press, focus feedback)
+- Stays subtle — the user should feel it, not watch it
+
+**Bad motion:**
+
+- Loops without purpose
+- Delays the user from their goal
+- Calls attention to itself over content
+- Hides poor hierarchy behind animation
+
+**Implementation:** Use CSS transitions for simple state changes. Use Framer Motion (`motion` library) for orchestrated sequences, layout animations, and gesture-driven interactions. Respect `prefers-reduced-motion` for non-trivial animation.
+
+**High-impact approach:** One well-orchestrated page load with staggered reveals (using `animation-delay` or motion's `staggerChildren`) creates more delight than scattered micro-interactions.
+
+### Backgrounds and Visual Depth
+
+Create atmosphere and depth rather than defaulting to solid white/gray:
+
+- Subtle gradient meshes or radial gradients for hero sections
+- Noise textures or grain overlays for organic warmth
+- Geometric patterns for technical/structured aesthetics
+- Layered transparencies and backdrop blur for glass effects (when appropriate to the design)
+- Dramatic shadows for card elevation
+- Decorative borders and dividers that match the aesthetic
+
+Match the visual treatment to the design's personality. A developer dashboard needs different atmosphere than a luxury landing page.
+
+### Responsive Design
+
+- Mobile-first with Tailwind's responsive prefixes (`sm:`, `md:`, `lg:`, `xl:`)
+- Touch targets minimum 44px on mobile
+- Test at least 3 breakpoints: mobile (375px), tablet (768px), desktop (1280px+)
+- Use `container` queries for component-level responsiveness
+- Adapt layout density, not just column count — typography, spacing, and hierarchy should respond too
+
+---
+
+## Reference Design Systems
+
+When the user wants to match the look of a known product, use these design vocabularies as a starting point. Extract the **principles and posture**, not pixel-perfect clones.
+
+### AI & Machine Learning
+
+| Reference        | Style                                            |
+| ---------------- | ------------------------------------------------ |
+| Anthropic Claude | Warm terracotta accent, clean editorial layout   |
+| Cohere           | Vibrant gradients, data-rich dashboard aesthetic |
+| ElevenLabs       | Dark cinematic UI, audio-waveform aesthetics     |
+| Mistral AI       | French-engineered minimalism, purple-toned       |
+| Replicate        | Clean white canvas, code-forward                 |
+
+### Developer Tools & Platforms
+
+| Reference  | Style                                           |
+| ---------- | ----------------------------------------------- |
+| Cursor     | Sleek dark interface, gradient accents          |
+| Linear     | Ultra-minimal dark-mode, precise, purple accent |
+| Raycast    | Sleek dark chrome, vibrant gradient accents     |
+| Resend     | Minimal dark theme, monospace accents           |
+| Sentry     | Dark dashboard, data-dense, pink-purple accent  |
+| Supabase   | Dark emerald theme, code-first developer tool   |
+| Superhuman | Premium dark UI, keyboard-first, purple glow    |
+| Vercel     | Black and white precision, Geist font system    |
+| Warp       | Dark IDE-like interface, block-based command UI |
+
+### Infrastructure & Cloud
+
+| Reference  | Style                                              |
+| ---------- | -------------------------------------------------- |
+| ClickHouse | Yellow-accented, technical documentation style     |
+| HashiCorp  | Enterprise-clean, black and white                  |
+| MongoDB    | Green leaf branding, developer documentation focus |
+| Stripe     | Signature purple gradients, weight-300 elegance    |
+
+### Design & Productivity
+
+| Reference | Style                                             |
+| --------- | ------------------------------------------------- |
+| Airtable  | Colorful, friendly, structured data aesthetic     |
+| Cal.com   | Clean neutral UI, developer-oriented simplicity   |
+| Figma     | Vibrant multi-color, playful yet professional     |
+| Framer    | Bold black and blue, motion-first, design-forward |
+| Notion    | Warm minimalism, serif headings, soft surfaces    |
+| Webflow   | Blue-accented, polished marketing site aesthetic  |
+
+### Fintech & Consumer
+
+| Reference | Style                                                   |
+| --------- | ------------------------------------------------------- |
+| Coinbase  | Clean blue identity, trust-focused, institutional feel  |
+| Revolut   | Sleek dark interface, gradient cards, fintech precision |
+| Airbnb    | Warm coral accent, photography-driven, rounded UI       |
+| Apple     | Premium white space, cinematic imagery                  |
+| Spotify   | Vibrant green on dark, bold type, album-art-driven      |
+
+### Choosing a Reference
+
+Match the design to the content domain:
+
+- **Developer tools / dashboards:** Linear, Vercel, Supabase, Raycast, Sentry
+- **Documentation / content sites:** Notion, Mintlify, MongoDB
+- **Marketing / landing pages:** Stripe, Framer, Apple
+- **Dark mode UIs:** Linear, Cursor, ElevenLabs, Warp, Superhuman
+- **Light / clean UIs:** Vercel, Stripe, Notion, Cal.com
+- **Playful / friendly:** Figma, PostHog, Zapier
+- **Premium / luxury:** Apple, Stripe, Superhuman, Revolut
+- **Data-dense / dashboards:** Sentry, Kraken, Cohere, ClickHouse
+
+Extract general design principles from references — density, hierarchy, interaction model, typography posture, color restraint — and transform them into an original design. Do not clone proprietary layouts or reproduce exact branded surfaces.
+
+---
+
+## Variation Rules
+
+When exploring design directions, default to at least three options:
+
+1. **Conservative** — closest to existing patterns, lowest risk
+2. **Strong-fit** — best interpretation of the brief
+3. **Divergent** — more novel, useful for discovering taste boundaries
+
+Variations should explore meaningfully different dimensions:
+
+- Layout and spatial composition
+- Typography scale and hierarchy
+- Density and whitespace treatment
+- Color posture and surface treatment
+- Motion and interaction model
+- Component shape and elevation
+
+**Do not create variations that are merely color swaps** unless color is the actual question.
+
+When the user picks a direction, consolidate immediately. Do not leave the project as a pile of options.
+
+---
+
+## Anti-Slop Rules
+
+Avoid these common AI design failures. Every element must earn its place.
+
+### Visual Anti-Patterns
+
+- ❌ Aggressive gradient backgrounds as default
+- ❌ Glassmorphism everywhere without justification
+- ❌ Rainbow palettes or gratuitous color variety
+- ❌ Oversized rounded rectangles substituting for hierarchy
+- ❌ Generic SaaS card grids with icons on every card
+- ❌ Left-border accent callout cards (the "AI card")
+- ❌ Stock-photo hero sections
+- ❌ Decorative SVG illustrations pretending to be product imagery
+- ❌ Emoji sprinkled throughout unless the brand uses them
+- ❌ Purple gradients on white backgrounds (the default AI palette)
+
+### Content Anti-Patterns
+
+- ❌ Fake metrics and decorative statistics
+- ❌ Generic feature grids ("Fast," "Secure," "Scalable" with shield/rocket/lightning icons)
+- ❌ Placeholder testimonials with stock names
+- ❌ Vague labels: "Insights," "Growth," "Scale," "Optimize" without substance
+- ❌ AI-generated fluff sections that add bulk without information
+- ❌ Fake dashboards filled with arbitrary numbers
+- ❌ Invented content that changes strategy or makes claims
+
+### Typography Anti-Patterns
+
+- ❌ Defaulting to Inter/Roboto/Arial for every project
+- ❌ System font stacks when a distinctive choice would serve the design
+- ❌ Converging on the same "safe" font (e.g., Space Grotesk) across generations
+- ❌ Monospace everywhere (use mono accents for code, not as body text)
+- ❌ Too many font families or weights (2 families, 3–4 weights max)
+
+### Behavioral Anti-Patterns
+
+- ❌ Building from memory when source files are available — read the actual code
+- ❌ Producing a generic SaaS layout and calling it "designed"
+- ❌ Adding sections, pages, or copy without asking when it would change scope
+- ❌ Claiming browser verification unless it actually happened
+- ❌ Using `scrollIntoView` unless there is no safer option
+- ❌ Decorative JS that fights usability
+
+**Minimal is not automatically good. Dense is not automatically cluttered.** Choose intentionally based on the content and audience. Every design should feel specifically crafted for its context — no two designs should look the same unless the brand system demands it.
+
+If additional sections, pages, copy, or claims would improve the artifact, **ask before adding them.** When copy is necessary but not final, mark it explicitly as draft or placeholder.
+
+---
+
+## Prototype and Interaction Rules
+
+For interactive prototypes:
+
+- Make the primary user path clickable end-to-end
+- Include key states: default, hover/focus, loading, empty, error, success
+- Expose variations with in-page controls when useful
+- Persist important state in localStorage when refresh continuity matters
+- Design the flow, not just the first screen
+
+### Tweaks Panel
+
+When useful for exploration, add an unobtrusive in-page `Tweaks` panel that controls:
+
+- Theme mode (light/dark)
+- Layout variant
+- Density (compact/comfortable/spacious)
+- Accent color
+- Type scale
+- Motion on/off
+
+The design should look final when tweaks are hidden. Persist tweak values with localStorage.
+
+---
+
+## Stack-Specific Guidance
+
+### React / Next.js (Primary Stack)
+
+- Use TypeScript strict mode — all components fully typed
+- Use shadcn/ui as the component primitive layer
+- Extend with Tailwind CSS for all styling — no CSS modules or styled-components
+- Use `cn()` from `@/lib/utils` for conditional class composition
+- Server Components by default, `"use client"` only when needed (state, effects, browser APIs)
+- Use Next.js App Router conventions (layouts, loading, error boundaries)
+- Colocate component files with their page when specific, or in `components/` when shared
+
+### Tailwind CSS
+
+- Use the design system through `tailwind.config.ts` extensions, not arbitrary values
+- Prefer semantic class groups: `text-muted-foreground` over `text-gray-500`
+- Use `@apply` sparingly — prefer utility composition in JSX
+- Use CSS variables in `globals.css` for theme tokens that shadcn/ui consumes
+- Dark mode via `class` strategy (Tailwind `dark:` prefix)
+
+### shadcn/ui
+
+- Use existing components before building custom ones
+- Follow shadcn/ui's variant pattern for new components (`cva` from class-variance-authority)
+- Respect the component's accessibility built-ins (ARIA, keyboard nav, focus management)
+- Customize through CSS variables and Tailwind, not by forking component internals
+
+### Images and Icons
+
+- Use `next/image` for optimized images in Next.js
+- Use Lucide React icons (bundled with shadcn/ui) — import only what's needed
+- For missing assets, use clean placeholders or typography/layout solutions
+- Ask for real material when fidelity matters — don't draw elaborate fake SVG illustrations
+
+---
+
+## Content Discipline
+
+Every element must earn its place.
+
+When the brief requires placeholder content:
+
+- Use realistic, domain-appropriate copy (not "Lorem ipsum" for user-facing prototypes)
+- Mark placeholder content explicitly: `{/* PLACEHOLDER */}` in code or visual indicators
+- Keep placeholder data structurally accurate (correct data types, realistic ranges)
+- Do not invent metrics, testimonials, or claims that could be mistaken for real content
+
+When copy is not provided but needed:
+
+- Write functional microcopy (button labels, empty states, error messages) that demonstrates the interaction
+- Flag strategic copy (taglines, value propositions, feature descriptions) as needing review
+- Never generate marketing claims or statistics without the user's explicit direction
+
+---
+
+## Accessibility Baseline
+
+Every design must meet these minimums:
+
+- Color contrast: WCAG AA (4.5:1 for normal text, 3:1 for large text)
+- Keyboard navigation: all interactive elements reachable and operable via keyboard
+- Focus indicators: visible focus rings on all interactive elements
+- Semantic HTML: proper heading hierarchy, landmarks, button/link distinction
+- Touch targets: minimum 44×44px on mobile
+- Screen reader basics: alt text for meaningful images, aria-labels for icon-only buttons
+- Reduced motion: respect `prefers-reduced-motion` for non-trivial animation
+
+These are not optional. Build them in from the start, not as an afterthought.

package/.plcode/skill/core/javascript-typescript/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: javascript-typescript
+description: JavaScript and TypeScript development with ES6+, Node.js, React, and modern web frameworks. Use for frontend, backend, or full-stack JavaScript/TypeScript projects.
+category: languages
+source: wshobson/agents
+license: MIT
+---
+
+# JavaScript/TypeScript Development
+
+## TypeScript Configuration
+
+```json
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "ESNext",
+    "moduleResolution": "bundler",
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "noImplicitOverride": true,
+    "skipLibCheck": true,
+    "declaration": true,
+    "outDir": "./dist"
+  },
+  "include": ["src/**/*"],
+  "exclude": ["node_modules", "dist"]
+}
+```
+
+## Type Patterns
+
+### Utility Types
+
+```typescript
+// Pick specific properties
+type UserPreview = Pick<User, "id" | "name">
+
+// Omit properties
+type CreateUser = Omit<User, "id" | "createdAt">
+
+// Make all properties optional
+type PartialUser = Partial<User>
+
+// Make all properties required
+type RequiredUser = Required<User>
+
+// Extract union types
+type Status = "pending" | "active" | "inactive"
+type ActiveStatus = Extract<Status, "active" | "pending">
+```
+
+### Discriminated Unions
+
+```typescript
+type Result<T> = { success: true; data: T } | { success: false; error: Error }
+
+function handleResult<T>(result: Result<T>) {
+  if (result.success) {
+    console.log(result.data) // T
+  } else {
+    console.error(result.error) // Error
+  }
+}
+```
+
+### Generic Constraints
+
+```typescript
+interface HasId {
+  id: string | number
+}
+
+function findById<T extends HasId>(items: T[], id: T["id"]): T | undefined {
+  return items.find((item) => item.id === id)
+}
+```
+
+## Modern JavaScript
+
+### Destructuring & Spread
+
+```javascript
+const { name, ...rest } = user
+const merged = { ...defaults, ...options }
+const [first, ...others] = items
+```
+
+### Optional Chaining & Nullish Coalescing
+
+```javascript
+const city = user?.address?.city ?? "Unknown"
+const count = data?.items?.length ?? 0
+```
+
+### Array Methods
+
+```javascript
+const adults = users.filter((u) => u.age >= 18)
+const names = users.map((u) => u.name)
+const total = items.reduce((sum, item) => sum + item.price, 0)
+const hasAdmin = users.some((u) => u.role === "admin")
+const allActive = users.every((u) => u.active)
+```
+
+## React Patterns
+
+```typescript
+// Props with children
+interface CardProps {
+  title: string
+  children: React.ReactNode
+}
+
+// Event handlers
+interface ButtonProps {
+  onClick: (event: React.MouseEvent<HTMLButtonElement>) => void
+}
+
+// Custom hooks
+function useLocalStorage<T>(key: string, initial: T) {
+  const [value, setValue] = useState<T>(() => {
+    const stored = localStorage.getItem(key)
+    return stored ? JSON.parse(stored) : initial
+  })
+
+  useEffect(() => {
+    localStorage.setItem(key, JSON.stringify(value))
+  }, [key, value])
+
+  return [value, setValue] as const
+}
+```
+
+## Node.js Patterns
+
+```typescript
+// ES Modules
+import { readFile } from "node:fs/promises"
+import { join } from "node:path"
+
+// Error handling
+process.on("unhandledRejection", (reason) => {
+  console.error("Unhandled Rejection:", reason)
+  process.exit(1)
+})
+```