@hiver/skills 1.0.1

package/collections/common/skills/solve-issue/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: solve-issue
+description: This skill is used to analyze the user issue, figure out the root cause and the fix to implement. Use it only when user explicitly asks to solve an issue or a problem statment.
+dependencies: [build-milestone]
+---
+
+# Solve issue
+
+Helps to analyze the user's problem statement , their concerns and figure out the root causes and its solutions. Go through the problem statement in context of the codebase and help to come up with a good solution.
+
+
+## When to Use
+
+- Use this skill when user wanted to solve a specific bug or an issue in the codebase or a feature.
+- This skill is helpful for solving an issue anywhere in the current codebase with proper implementation
+
+## Instructions
+
+- Get the problem statement from the user
+- Analyze the problem, dig deep in it
+- Analyze the problem statement in context of the current codebase
+- Ask right questions until you are clear on the problem statment
+- go through the codebase and figure out how we can solve this problem
+- use the correct tools to explore the specific directory or file required to solve the or analyze the issue
+- Provide your thoughts and opinions on how to tackle this
+- Figure out problems, issues and edge cases which can come up while solving the problem
+- take inputs from the user if he has any
+- keep discussing until you and the user are not on the same page
+- Keep discussing until all the issues being presented didn't got solved
+- once both of you are on the same page ask the user if he needs to implement the fix or not
+- if the users askes to implement it then implement the feature using the `/build-milestone` agent providing him the required inputs.

package/collections/common/skills/write-test-cases/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: write-test-cases
+description: Writes structured behavioural test cases for a milestone into a progress-sheet markdown file. Invoked by build-milestone before any implementation begins (Normal Mode) or once per feedback round (Fix Mode). Never writes source code.
+---
+
+# Write Test Cases
+
+Generates a complete set of structured behavioural test cases for a milestone and saves them as a progress sheet that `build-milestone` uses to drive its TDD loop.
+
+## When to Use
+
+- Invoked by `build-milestone` at the start of **Normal Mode** — before any implementation begins
+- Invoked by `build-milestone` at the start of **Fix Mode** — once per feedback round, scoped to the feedback
+
+## Inputs
+
+- Path to the milestone document (always required)
+- Mode: `normal` or `feedback`
+- If `feedback` mode: path to the feedback file
+
+## Instructions
+
+### Normal Mode
+
+1. Read the milestone document thoroughly. Extract:
+   - Goal
+   - Acceptance criteria (2–3 product-level "done" conditions)
+   - Architectural approach and high-level areas affected
+
+2. Explore the codebase **scoped strictly to the "High-level areas affected" section of the milestone doc**. Read only the files and directories explicitly named there. Do NOT fan out to unrelated modules. Limit reads to what is minimally needed to understand current state — what exists, what doesn't, what will change.
+
+3. If the milestone doc contains Figma design links, load them using the Figma MCP tool. Analyze the designs to identify UI-specific behaviours and edge cases. Load only the specific nodes linked — do not traverse the full Figma file.
+
+4. Derive test cases from the acceptance criteria and your codebase exploration. For each observable behaviour the milestone introduces or changes, write one test case. Aim for full coverage across:
+   - Happy path (primary user flows)
+   - Edge cases (boundary conditions, empty states, large data)
+   - Error states (API failures, invalid input, permission issues)
+   - Regressions (existing behaviours that must not break)
+
+5. Write ALL test cases to `milestone-tests/<milestone-name>-tests.md` — create the file if it doesn't exist. All test cases start with `⬜ Pending` status.
+
+6. Use this format for every test case:
+
+```markdown
+## TC-001 | Category: happy-path | ⬜ Pending
+Given: <system or state precondition>
+When:  <user action or system trigger>
+Then:  <observable outcome — what the user sees or what changes in state>
+```
+
+7. After writing all test cases, exit. Do not write any source code.
+
+---
+
+### Feedback Mode
+
+1. Read the milestone document to understand the original scope.
+
+2. Read the feedback file. Identify the **active** (non-stale) feedback entry.
+
+3. Explore the codebase to understand the current state of the implementation for this milestone.
+
+4. Derive test cases scoped **only** to what the feedback describes. Write as many as needed to fully cover the feedback — happy path, edge cases, and regressions relevant to the fix.
+
+5. Append the new test cases to the existing `milestone-tests/<milestone-name>-tests.md` under a new section:
+
+```markdown
+## Feedback Round N
+
+### FTC-001 | Category: regression | ⬜ Pending
+Given: <precondition>
+When:  <action>
+Then:  <expected outcome>
+```
+
+Where `N` is incremented from the last existing Feedback Round number in the file.
+
+6. After appending, exit. Do not write any source code.
+
+---
+
+## Output
+
+A `milestone-tests/<milestone-name>-tests.md` file (created or appended) with all new test cases set to `⬜ Pending`.
+
+The `milestone-tests/` directory lives alongside the `milestones/` directory under the same parent.
+
+## Rules
+
+- NEVER write source code
+- NEVER mark any test case as passing — all new TCs start as `⬜ Pending`
+- NEVER modify existing test case entries — only append new ones
+- In Feedback Mode, only write TCs scoped to the active feedback — do not add unrelated cases

package/collections/web/agents/build-feature.md

@@ -0,0 +1,42 @@
+---
+name: build-feature
+model: default
+description: Senior Manager owning a PRD to build the feature from end to end
+dependencies: [build-milestone]
+---
+
+You are a Senior Manager who has owned a PRD to develop the feature or issue mentioned inside it from end to end.
+
+> **HARD RULE — NEVER VIOLATE:**
+> You are a **manager**, not an implementer. You MUST NEVER write, edit, or implement code yourself. Every milestone MUST be implemented exclusively by spawning a `build-milestone` subagent. Skipping subagent spawning and implementing directly is strictly forbidden, regardless of how simple a milestone appears.
+
+**Token efficiency rules:**
+- **Do NOT re-read milestone documents** after the initial analysis — you already know the scope.
+- **Keep review conversations brief** — when presenting milestones to the user, summarize the changes in 3-5 bullet points instead of replaying the full milestone doc.
+- **Spawn independent milestones in parallel** to avoid sequential context accumulation.
+
+When invoked:
+1. Ask for the directory path for the milestones implementation documents.
+2. Analyze the documents inside that directory.
+3. Create a `progress.md` in the same directory if not already present, listing all milestones in table format with status `Pending`:
+
+```
+| Milestone | Status |
+|-----------|--------|
+| M1: <name> | Pending |
+```
+
+   Valid statuses: `Pending` | `In Progress` | `Review Required` | `Completed`
+
+4. Pick the next milestone(s) that are not `Completed`. Start with all independent milestones first (they can be spawned in parallel). Dependent milestones only start after their dependencies are `Completed`.
+5. **MANDATORY:** Spawn a `build-milestone` subagent in **normal mode** for each ready milestone, passing the milestone document path. You MUST spawn the subagent — do not implement the milestone yourself under any circumstances.
+6. Wait for the subagent(s) to finish, then re-read `progress.md`.
+7. If the milestone status is `Review Required`:
+   a. Present the milestone to the user with a brief summary (3-5 bullets of what changed) and ask for approval.
+   b. **If approved:** update `progress.md` → `Completed`. Repeat from step 4.
+   c. **If rejected:** collect the user's feedback. Write it to `milestone-feedbacks/<milestone-name>-feedback.md` in the same root directory (create the file if it doesn't exist; if it exists, mark all current active feedback entries as stale and append the new feedback as the active entry). **MANDATORY:** Spawn a `build-milestone` subagent in **fix mode**, passing both the milestone document path and the feedback file path. Repeat from step 6.
+8. Once all milestones are `Completed`, run the following post-processing steps in order:
+   a. **Prettify** — get the list of all modified files via `git diff --name-only` and run the project formatter (Prettier / ESLint `--fix`) on them.
+   b. **Lint check** — run the linter on the same file set and surface any remaining errors to the user.
+   c. **Remove debug artifacts** — scan all modified files for leftover `console.log`, `debugger` statements, and agent-added `TODO` comments. Remove them.
+9. Exit.

package/collections/web/agents/build-milestone.md

@@ -0,0 +1,61 @@
+---
+name: build-milestone
+model: sonnet
+description: Senior Frontend specialist helping to complete a milestone from the PRD document.
+dependencies: [write-test-cases]
+---
+
+You are a Senior frontend developer with years of experience in frontend development, debugging issues and developing features from end to end.
+
+**Source of truth principle:**
+- The milestone document is the authority on **WHAT** — goal, architectural approach, feature flag, affected areas, skills to activate, and acceptance criteria.
+- The `milestone-tests/<milestone-name>-tests.md` file is the authority on **test progress** — it is the single source of truth for what has been verified and what remains pending.
+- The skills are the authority on **HOW** — exact files to create, exact registration lines, exact wiring and scaffolding. Never override a skill's output with anything written in the milestone doc. If there is a conflict, the skill wins.
+
+**Token efficiency rules:**
+- **Only load skills listed in the milestone doc's "Skills to activate" section**, with one exception below. Do NOT read or reference skills that are not listed. If the milestone says `skills: [build-component, connect-api]`, do NOT load `modify-extension`, `ci-cd`, `build-backbone-component`, or any other skill.
+- **Auto-activate `build-component`**: Always activate the `build-component` skill by default for every milestone, even if it is not listed in "Skills to activate" — unless the milestone is explicitly backend-only or non-UI (e.g., pure API wiring, config changes, backend logic with no React/JSX involvement).
+- **Within each skill, load reference files lazily** — only when you are about to perform the specific task that reference covers. Do NOT read all reference files upfront.
+- **Minimize file re-reads** — read a file once, retain key details in your reasoning, do not re-read unless the file was modified.
+
+**Invocation modes:**
+
+## Normal Mode
+Invoked with: milestone document path only.
+
+1. Ask for the path to the milestone document.
+2. Read the milestone document thoroughly. Extract: goal, architectural approach, feature flag decision, skills to activate, and acceptance criteria.
+3. Update `progress.md` → status: **In Progress** for the current milestone.
+4. **Invoke the `write-test-cases` skill (Normal Mode)** — pass the milestone document path. Wait for the skill to finish writing all test cases to `milestone-tests/<milestone-name>-tests.md` before proceeding. Do not write any implementation code before this step completes.
+5. **Batched TDD loop** — read `milestone-tests/<milestone-name>-tests.md` **once** and load all `⬜ Pending` TCs into memory. Do NOT re-read the file on each iteration. **Group related TCs** (e.g., TCs that test the same component, same API, or same user flow) and implement them together in batches:
+   a. Pick the next batch of related `⬜ Pending` TCs from the in-memory list (2-4 TCs per batch when they share implementation scope).
+   b. If none remain → all TCs pass → go to step 6.
+   c. Reason: "what code do I need to write to make this batch of TCs pass?" — think before acting.
+   d. Implement using **only** the skills listed in the milestone doc's "Skills to activate" section, invoking them in this order as needed:
+      - `scaffold-react-feature` → folder structure, wiring, feature flag boilerplate
+      - `build-component` → UI (React path)
+      - `connect-api` → data fetching and mutations
+   e. Trace through the implemented code — do the `Then` conditions of all TCs in the batch hold?
+      - All pass → update all statuses to `✅ Pass` in the test file (single write) → go to step (a)
+      - Some fail → re-think → fix code → trace again → update statuses → go to step (a)
+6. Once every test case passes, update `progress.md` → status: **Review Required** and exit.
+
+---
+
+## Fix Mode
+Invoked with: milestone document path + feedback file path.
+
+1. Read the milestone document to understand the goal and scope.
+2. Read the feedback file. Identify the **active** (non-stale) feedback entry — this is the only feedback to address.
+3. Update `progress.md` → status: **In Progress** for the current milestone.
+4. **Invoke the `write-test-cases` skill (Feedback Mode)** — pass the milestone document path and feedback file path. Wait for the skill to finish appending the new feedback-scoped TCs under `## Feedback Round N` in the existing `milestone-tests/<milestone-name>-tests.md`.
+5. **Batched TDD loop** — read `milestone-tests/<milestone-name>-tests.md` **once**, load the `⬜ Pending` TCs from the current Feedback Round section into memory. Group related TCs and implement in batches:
+   a. Pick the next batch of related `⬜ Pending` TCs from the in-memory list.
+   b. If none remain → go to step 6.
+   c. Reason: "what change do I need to make to satisfy this batch of TCs?" — think before acting.
+   d. Apply only the changes needed to address the active feedback. Do **not** re-scaffold or re-implement what is already done. Load **only** the skills needed for the fix.
+   e. Trace through the changed code — do the `Then` conditions hold?
+      - All pass → update statuses in the test file → go to step (a)
+      - Some fail → re-think → fix → trace again → update statuses → go to step (a)
+6. Once all feedback TCs pass, mark the active feedback entry in the feedback file as stale (strikethrough heading and body, append `(stale)` label). Keep the entry — do not delete it.
+7. Update `progress.md` → status: **Review Required** and exit.

package/collections/web/skills/build-component/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: build-component
+description: Build UI React components following Hiver design system and patterns
+---
+
+# Build Component
+
+**Scope:** Pure UI concerns only — Figma → React component, Hiver UI kit, layout, icons, typography, component organization, and UI-level state management.
+
+**Out of scope:** Feature folder structure, Backbone mounting, `ReactBackboneModules` registration, lazy imports in `index.js`, and feature flag wiring. Those belong in the `scaffold-react-feature` skill.
+
+When building UI React components, use the currently selected Figma node as the design reference and follow the Hiver design system. Use `@hiver/hiver-ui-kit` for all components; prefer `Stack` for layout and MUI/SVG for icons. Map Figma colors and text styles using the **palette** and **typography** references below.
+
+## Mandatory Rules (always apply)
+
+### UI Kit and Styling
+
+- **Use `@hiver/hiver-ui-kit` package** for all UI components and styling
+  - This package uses Material-UI (MUI) internally, so follow MUI patterns
+  - Import components directly from `@hiver/hiver-ui-kit`: `import { Stack, Button, Typography, TextField, Select } from '@hiver/hiver-ui-kit'`
+- **Map Figma to design tokens**: Use [palette/README.md](palette/README.md) for colors and [typography/README.md](typography/README.md) for text styles so Figma specs map to the correct `theme.palette.*` and `<Typography variant="...">`.
+- **Analyze the Figma selection** to identify all required components:
+  - Form inputs: Use `TextField`, `Select`, `Checkbox`, `Radio`, etc.
+  - Typography: Use `Typography` with variants from the typography reference (e.g. `body1_regular`, `h2_medium`, `caption1_medium`)
+  - Layout: Use `Stack`, `Box`, `Grid` for layout structure
+  - Buttons: Use `Button` with appropriate variants (`contained`, `outlined`, `text`)
+  - Modals: Use `Modal`
+  - Other: `Tooltip`, `CircularProgress`, `IconButton`, etc.
+
+### Layout and Structure
+
+- **Prefer `Stack` component** for flex layouts instead of raw flexbox CSS
+  - Use `Stack` with `direction="row"` or `direction="column"`
+  - Use `gap` prop for spacing between items
+  - Example: `<Stack direction="row" gap={2} alignItems="center">`
+- **Use `Box`** for simple container elements or when you need custom styling
+- Use `sx` prop for component-specific styling
+
+### Component Organization
+
+- **Small sub-components** (less than ~50 lines, simple logic):
+  - Define them in the same file, outside the main component
+  - Place them above the main component export
+- **Large sub-components** (complex logic, reusable, >50 lines):
+  - Extract to separate files in the same directory or `components/` subdirectory
+  - Follow the pattern: `ComponentName/index.js` for main component, `ComponentName/SubComponent.js` for sub-components
+  - Reference example: `react-extn/src/AiCopilot/Pages/Chat/components/` or `react-extn/src/AiCopilot/Pages/Tags/components/`
+- **File naming**: Use PascalCase for component files (e.g., `TagItem.js`, `ModifyTagDialog.js`)
+
+## Lazy-loaded References
+
+**Load lazily — only read a reference file when you are about to perform that specific task. Do NOT read all files upfront.**
+
+| Topic | File | When to load |
+|-------|------|--------------|
+| Figma integration | [references/figma-integration.md](references/figma-integration.md) | Only when a Figma link is present |
+| Icons | [references/icons.md](references/icons.md) | Only when adding icons |
+| State management | [references/state-management.md](references/state-management.md) | Only when adding local or shared state |
+| Best practices | [references/best-practices.md](references/best-practices.md) | Only when uncertain about a pattern |
+
+### Figma → design tokens (map colors and type from Figma here)
+
+| Topic | File |
+|-------|------|
+| **Palette** (colors) | [palette/README.md](palette/README.md) |
+| **Typography** (variants) | [typography/README.md](typography/README.md) |

package/collections/web/skills/build-component/palette/README.md

@@ -0,0 +1,3 @@
+# Palette reference (`@hiver/hiver-ui-kit`)
+
+See [colors.md](colors.md) for all palette tokens and Figma mapping.

package/collections/web/skills/build-component/palette/colors.md

@@ -0,0 +1,87 @@
+# Palette reference (`@hiver/hiver-ui-kit`)
+
+Use this to map Figma fill/text colors to theme tokens. Prefer `theme.palette.*` or `sx={{ color: '...' }}` with these tokens.
+
+## Semantic / brand colors
+
+| Token | Hex | Usage |
+|-------|-----|--------|
+| `palette.yellow.primary` | `#FFE250` | Primary yellow |
+| `palette.yellow.hover` | `#FCCF59` | Yellow hover |
+| `palette.yellow.light` | `#FFF0D3` | Yellow light bg |
+| `palette.blue.primary` | `#196FE0` | Primary blue |
+| `palette.blue.hover` | `#0456C2` | Blue hover |
+| `palette.blue.light` | `#E2F1FF` | Blue light bg |
+| `palette.purple.primary` | `#506DFF` | Primary purple (theme primary) |
+| `palette.purple.hover` | `#4763F0` | Purple hover |
+| `palette.purple.light` | `#F0F3FF` | Purple light bg |
+| `palette.green.primary` | `#00BC7E` | Success / green |
+| `palette.green.hover` | `#05A570` | Green hover |
+| `palette.green.light` | `#E3FCF4` | Green light bg |
+| `palette.red.primary` | `#CD3746` | Error / red |
+| `palette.red.hover` | `#D24B58` | Red hover |
+| `palette.red.light` | `#FFE0E3` | Red light bg |
+| `palette.orange.primary` | `#FF8B00` | Warning / orange |
+| `palette.orange.hover` | `#DE7D0A` | Orange hover |
+| `palette.orange.light` | `#FFEFE0` | Orange light bg |
+
+## Gray scale
+
+| Token | Hex | Usage |
+|-------|-----|--------|
+| `palette.gray.gray1` | `#3E4C5A` | Darkest gray |
+| `palette.gray.gray2` | `#4D596C` | Text primary |
+| `palette.gray.gray3` | `#6F7C90` | |
+| `palette.gray.gray4` | `#97A3B7` | Text secondary, disabled |
+| `palette.gray.gray5` | `#D6DDE8` | |
+| `palette.gray.gray6` | `#ECEFF6` | Borders, dividers |
+| `palette.gray.gray6a` | `#F6F8FC` | |
+| `palette.gray.gray7` | `#0F13160A` | Subtle overlay |
+| `palette.gray.background` | `#FCFCFF` | Page background |
+| `palette.gray.white16` | `rgba(255, 255, 255, 0.16)` | White 16% opacity |
+| `palette.gray.white` | `#FFFFFF` | White |
+| `palette.gray.black` | `#343C45` | Black / primary text |
+
+## Tag colors
+
+| Token | Hex |
+|-------|-----|
+| `palette.tag.gray` | `#90A4AE` |
+| `palette.tag.green` | `#81C784` |
+| `palette.tag.red` | `#E57373` |
+| `palette.tag.yellow` | `#FFC107` |
+| `palette.tag.blue` | `#64B5F6` |
+| `palette.tag.teal` | `#4DD0E1` |
+| `palette.tag.brown` | `#A1887F` |
+| `palette.tag.pink` | `#FF5B92` |
+| `palette.tag.purpleDark` | `#9575CD` |
+| `palette.tag.purpleLight` | `#CE93D8` |
+
+## Avatar colors (array)
+
+Use `palette.avatar[index]` for avatar backgrounds (e.g. by user index).
+
+| Index | Hex |
+|-------|-----|
+| 0 | `#F05388` |
+| 1 | `#BE75CA` |
+| 2 | `#E57373` |
+| 3 | `#9575CD` |
+| 4 | `#68B66B` |
+| 5 | `#19ABBE` |
+| 6 | `#A1887F` |
+| 7 | `#64B5F6` |
+
+## MUI theme mapping
+
+Use these when wiring to MUI theme (e.g. `color="primary"`, `color="text.secondary"`).
+
+- **Primary**: purple (main `#506DFF`)
+- **Secondary**: yellow
+- **Text primary**: `gray.gray2`
+- **Text secondary**: `gray.gray4`
+- **Success**: green
+- **Error**: red
+- **Info**: blue
+- **Warning**: orange
+- **Divider**: `gray.gray6`

package/collections/web/skills/build-component/references/best-practices.md

@@ -0,0 +1,8 @@
+# Best Practices
+
+- **Follow existing code patterns** in the codebase
+- **Use TypeScript/PropTypes** if the project uses them
+- **Handle loading and error states** appropriately
+- **Keep components focused** - single responsibility principle
+- **Use meaningful variable and function names**
+- **Add comments** for complex logic or non-obvious decisions

package/collections/web/skills/build-component/references/component-organization.md

@@ -0,0 +1,21 @@
+# Component Organization
+
+- **Small sub-components** (less than ~50 lines, simple logic):
+  - Define them in the same file, outside the main component
+  - Place them above the main component export
+  - Example structure:
+    ```javascript
+    const SubComponent = ({ prop1, prop2 }) => {
+      // component logic
+    };
+    
+    const MainComponent = () => {
+      // main component logic
+      return <SubComponent />;
+    };
+    ```
+- **Large sub-components** (complex logic, reusable, >50 lines):
+  - Extract to separate files in the same directory or `components/` subdirectory
+  - Reference example: `react-extn/src/AiCopilot/Pages/Chat/components/` or `react-extn/src/AiCopilot/Pages/Tags/components/`
+  - Follow the pattern: `ComponentName/index.js` for main component, `ComponentName/SubComponent.js` for sub-components
+- **File naming**: Use PascalCase for component files (e.g., `TagItem.js`, `ModifyTagDialog.js`)

package/collections/web/skills/build-component/references/figma-integration.md

@@ -0,0 +1,5 @@
+# Figma Integration
+
+- **Always use the currently selected node in Figma** as the design reference
+- Extract design specifications (colors, spacing, typography, dimensions) from the Figma selection
+- Match the visual design exactly as specified in Figma

package/collections/web/skills/build-component/references/icons.md

@@ -0,0 +1,8 @@
+# Icons
+
+- **Use MUI icons only** - import from `@mui/icons-material` or `@hiver/hiver-ui-kit` icons
+- **For SVG icons**: Import SVG files directly and use them in `<img>` tags
+  - Import SVG files: `import iconName from 'path/to/icon.svg'`
+  - Use in component: `<img src={iconName} alt="description" />`
+  - Example: `import AILogo from '../assets/ai_logo.svg'` then `<img src={AILogo} alt="AI Copilot" />`
+- **Do not import icons from other packages** (no FontAwesome, Heroicons, etc.)

package/collections/web/skills/build-component/references/layout-and-structure.md

@@ -0,0 +1,8 @@
+# Layout and Structure
+
+- **Prefer `Stack` component** for flex layouts instead of raw flexbox CSS
+  - Use `Stack` with `direction="row"` or `direction="column"`
+  - Use `gap` prop for spacing between items
+  - Example: `<Stack direction="row" gap={2} alignItems="center">`
+- **Use `Box`** for simple container elements or when you need custom styling
+- use `sx` prop for component-specific styling

package/collections/web/skills/build-component/references/state-management.md

@@ -0,0 +1,25 @@
+# State Management
+
+## Identifying State
+
+- **Connect dynamic elements to state**:
+  - User inputs (form fields, toggles, selections)
+  - Data that changes based on user interactions
+  - UI state (modals open/closed, tabs active, loading states)
+
+## State Implementation
+
+- **Use React hooks** for local component state:
+  - `useState` for simple state values
+  - `useReducer` for complex state with multiple sub-values
+  - `useMemo` for computed/derived values
+  - `useCallback` for memoized functions
+- **Add proper event handlers**:
+  - `onChange` handlers for inputs
+  - `onClick` handlers for buttons/actions
+  - `onSubmit` handlers for forms
+  - Ensure handlers update state appropriately
+- **Handle state updates correctly**:
+  - Use functional updates when state depends on previous state: `setCount(prev => prev + 1)`
+  - Batch related state updates when possible
+  - Clean up subscriptions/effects in `useEffect` cleanup functions

package/collections/web/skills/build-component/references/ui-kit-and-styling.md

@@ -0,0 +1,13 @@
+# UI Kit and Styling
+
+- **Use `@hiver/hiver-ui-kit` package** for all UI components and styling
+  - This package uses Material-UI (MUI) internally, so follow MUI patterns
+  - Import components directly from `@hiver/hiver-ui-kit`: `import { Stack, Button, Typography, TextField, Select } from '@hiver/hiver-ui-kit'`
+- **Map Figma to design tokens**: Use [palette/README.md](../palette/README.md) for colors and [typography/README.md](../typography/README.md) for text styles so Figma specs map to the correct `theme.palette.*` and `<Typography variant="...">`.
+- **Analyze the Figma selection** to identify all required components:
+  - Form inputs: Use `TextField`, `Select`, `Checkbox`, `Radio`, etc.
+  - Typography: Use `Typography` with variants from the typography reference (e.g. `body1_regular`, `h2_medium`, `caption1_medium`)
+  - Layout: Use `Stack`, `Box`, `Grid` for layout structure
+  - Buttons: Use `Button` with appropriate variants (`contained`, `outlined`, `text`)
+  - Modals: Use `Modal`
+  - Other: `Tooltip`, `CircularProgress`, `IconButton`, etc.

package/collections/web/skills/build-component/typography/README.md

@@ -0,0 +1,3 @@
+# Typography reference (`@hiver/hiver-ui-kit`)
+
+See [variants.md](variants.md) for all typography variants and Figma mapping.

package/collections/web/skills/build-component/typography/variants.md

@@ -0,0 +1,79 @@
+# Typography reference (`@hiver/hiver-ui-kit`)
+
+Map Figma text styles to `<Typography variant="...">`. Font family is **Open Sans**. Match by fontSize + fontWeight (regular 400, medium 500, semiBold 600, bold 700).
+
+## Heading variants
+
+| Variant | fontSize | fontWeight | lineHeight | letterSpacing | Figma match |
+|---------|----------|------------|------------|---------------|-------------|
+| `h1_medium` | 20 | 500 | 28px | -0.16px | Large title |
+| `h1_semiBold` | 20 | 600 | 28px | -0.16px | |
+| `h1_bold` | 20 | 700 | 28px | -0.16px | |
+| `h2_regular` | 16 | 400 | 21px | -0.16px | Section title |
+| `h2_medium` | 16 | 500 | 21px | -0.16px | |
+| `h2_semiBold` | 16 | 600 | 21px | -0.16px | |
+| `h2_5_regular` | 15 | 400 | 18px | -0.16px | |
+| `h2_5_medium` | 15 | 500 | 18px | -0.16px | |
+| `h2_5_semiBold` | 15 | 600 | 18px | -0.16px | |
+| `h3_regular` | 14 | 400 | 18px | 0 | Subsection |
+| `h3_medium` | 14 | 500 | 18px | 0 | |
+| `h3_semiBold` | 14 | 600 | 18px | 0 | |
+| `h4_regular` | 13 | 400 | 16px | 0 | |
+| `h4_medium` | 13 | 500 | 16px | 0 | |
+| `h4_semiBold` | 13 | 600 | 16px | 0 | |
+| `h5_regular` | 12 | 400 | 14px | -0.12px | Small heading |
+| `h5_medium` | 12 | 500 | 14px | -0.12px | |
+| `h5_semiBold` | 12 | 600 | 14px | -0.12px | |
+| `h5_bold` | 12 | 700 | 14px | -0.12px | |
+
+## Body variants
+
+| Variant | fontSize | fontWeight | lineHeight | letterSpacing |
+|---------|----------|------------|------------|---------------|
+| `body0_5_regular` | 16 | 400 | 22px | 0 |
+| `body0_5_medium` | 16 | 500 | 22px | 0 |
+| `body0_5_semiBold` | 16 | 600 | 22px | 0 |
+| `body1_regular` | 14 | 400 | 21px | 0 |
+| `body1_medium` | 14 | 500 | 21px | 0.25px |
+| `body1_semiBold` | 14 | 600 | 21px | 0 |
+| `body2_regular` | 13 | 400 | 18px | 0 |
+| `body2_medium` | 13 | 500 | 18px | 0 |
+| `body2_semiBold` | 13 | 600 | 18px | 0 |
+| `body3_regular` | 12 | 400 | 14px | 0 |
+| `body3_medium` | 12 | 500 | 14px | 0 |
+| `body3_semiBold` | 12 | 600 | 14px | 0 |
+| `body4_regular` | 11 | 400 | 12px | 0 |
+| `body4_medium` | 11 | 500 | 12px | 0 |
+| `body4_semiBold` | 11 | 600 | 12px | 0 |
+
+## Caption & overline
+
+| Variant | fontSize | fontWeight | lineHeight | letterSpacing | Notes |
+|---------|----------|------------|------------|---------------|-------|
+| `caption1_regular` | 12 | 400 | 16px | 0.25px | |
+| `caption1_medium` | 12 | 500 | 16px | 0.25px | |
+| `caption1_semiBold` | 12 | 600 | 16px | 0.25px | |
+| `caption2_regular` | 11 | 400 | 14px | 0.20px | |
+| `caption2_medium` | 11 | 500 | 14px | 0.20px | |
+| `caption2_semiBold` | 11 | 600 | 14px | 0.20px | |
+| `overline_medium` | 11 | 500 | 18px | 0 | UPPERCASE |
+| `overline_semiBold` | 11 | 600 | 18px | 0 | UPPERCASE |
+
+## Button & chip
+
+| Variant | fontSize | fontWeight | lineHeight | letterSpacing |
+|---------|----------|------------|------------|---------------|
+| `buttonLarge` | 14 | 500 | 28px | 0.2px |
+| `buttonMedium` | 13 | 500 | 24px | 0.2px |
+| `buttonSmall` | 12 | 500 | 20px | 0.4px |
+| `chip` | 12 | 500 | 12px | 0.4px |
+
+## Usage
+
+```jsx
+<Typography variant="h2_medium">Section title</Typography>
+<Typography variant="body1_regular">Body text</Typography>
+<Typography variant="caption1_medium" color="text.secondary">Caption</Typography>
+```
+
+**Figma → variant:** Compare Figma text style fontSize and weight (Regular/Medium/Semi Bold/Bold) to the tables above and pick the closest match.

package/collections/web/skills/connect-api/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: connect-api
+description: API integration rules for React Query, custom hooks, and Hiver fetchers. Use when connecting to APIs, creating data-fetching or mutation hooks, or working with React Query and service utilities.
+---
+
+# Connect API
+
+When integrating APIs, use React Query for data and mutations, put hooks in a `hooks` folder, and use the correct fetcher from `react-extn/src/utils`. Define query keys in `constants/queries.js`.
+
+## Reference files
+
+**Load lazily — only read a reference file when you are about to perform that specific task. Do NOT read all files upfront.**
+
+| Topic | File | When to load |
+|-------|------|--------------|
+| Hook organization | [references/hook-organization.md](references/hook-organization.md) | Before creating a new hook file |
+| React Query (queries & mutations) | [references/react-query-usage.md](references/react-query-usage.md) | Before writing useQuery/useMutation |
+| Query key management | [references/query-keys.md](references/query-keys.md) | Before defining query keys |
+| Data fetcher selection | [references/data-fetchers.md](references/data-fetchers.md) | Before choosing a fetcher utility |
+| API call structure | [references/api-call-structure.md](references/api-call-structure.md) | Before writing the fetch call body |
+| URL and method placeholders | [references/url-placeholders.md](references/url-placeholders.md) | Only when constructing dynamic URLs |
+| Error handling | [references/error-handling.md](references/error-handling.md) | Only when adding error/loading states |
+| Best practices | [references/best-practices.md](references/best-practices.md) | Only when uncertain about a pattern |