@hiver/skills 1.0.1 → 1.0.3

package/collections/common/skills/discuss-problem/SKILL.md

@@ -36,8 +36,8 @@ Help the user to grill down on a problem to its core discussing all sorts of the
 
 1. Take input from the user related to the problem they want to discuss or grill down
 2. If the problem is related to building a new feature, check with the user if prototype designs are available
-3. If Figma designs are available, use the Figma MCP tool to get the prototype details and analyze them
-4. Keep asking if the user has more Figma designs available until all designs are provided; keep using the Figma MCP tool to load them into memory
+3. If Figma designs are available, use the claude Figma desktop MCP tool to get the prototype details and analyze them
+4. Keep asking if the user has more Figma designs available until all designs are provided; keep using the claude Figma desktop MCP tool to load them into memory
 5. Analyze the problem statement in context of the current codebase — use read and search tools to explore, never write tools
 6. Ask the right questions until you are clear on the problem statement
 7. Go through the codebase and figure out how the problem can be solved — discussion only

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

@@ -0,0 +1,41 @@
+---
+name: build-feature
+model: default
+description: Senior Manager owning a PRD to build the feature from end to end
+---
+
+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/extension/agents/build-milestone.md

@@ -0,0 +1,62 @@
+---
+name: build-milestone
+model: sonnet
+description: Senior Frontend specialist helping to complete a milestone from the PRD document.
+---
+
+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.** 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.
+- **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:
+      - `build-backbone-component` → scaffolding, Model/Collection/View/Controller/template/SASS, React-into-Backbone mount
+      - `scaffold-react-feature` → folder structure, wiring, feature flag boilerplate
+      - `build-component` → UI (React path)
+      - `connect-api` → data fetching and mutations
+      - `ci-cd` → read and follow **before** any pipeline/build script changes
+      - `modify-extension` → read and follow before touching any Chrome extension layer code
+   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/extension/skills/build-backbone-component/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: build-backbone-component
+description: Scaffold and build UI components and logic in the Backbone module system. Covers Model, Collection, View, Controller, templates, SASS, and optionally mounting a React component into a Backbone View. Use when the task involves building a new Backbone module or adding to an existing one.
+---
+
+# Build Backbone Component
+
+**Scope:** Building UI and logic inside `src/modules/<featureName>/` — Models, Collections, Views,
+Controllers, Underscore templates, and SASS. Also covers the React-into-Backbone mounting path
+when the UI is better built in React.
+
+---
+
+## Step 1 — Understand the Requirement
+
+Read the input carefully. Identify:
+- What data does this component need? Where does it live?
+- Does the UI slot naturally into an existing HTML template, or is it a standalone interactive widget?
+- Does it need to share its logic/API with other modules?
+
+---
+
+## Step 2 — Choose the Rendering Path
+
+### Backbone Template path (default)
+Use when:
+- The data the component needs lives on the Backbone side (models, collections, `grexit.*` globals)
+- The UI slots naturally into an existing HTML template — inserting a `<div>` and rendering into it is simpler than wiring a React mount point
+- Interactivity can be handled with Backbone `events` + jQuery
+
+### React Mount path
+Use when:
+- The component is complex and interactive: needs hooks, React Query, or local React state
+- The data it needs already lives in the Redux store or comes from React Query
+- Building the equivalent insertion/wiring logic in React is simpler than doing it in Backbone
+
+---
+
+## Step 3 — Determine Which Files to Create
+
+| File | When to create |
+|---|---|
+| `<FeatureName>Model.js` | When the component has meaningful state or data attributes |
+| `<FeatureName>Collection.js` | When working with a list of models |
+| `<FeatureName>View.js` | Always |
+| `<FeatureName>Controller.js` | Only when logic needs to be exposed to other modules |
+| `templates.html` | Always on the Backbone Template path |
+| `src/sass/framework_revamp/<featureName>.sass` | Always |
+
+For the React Mount path, additionally:
+
+| File | Purpose |
+|---|---|
+| `react-extn/src/<FeatureName>/<FeatureName>.jsx` | React component |
+| `react-extn/src/<FeatureName>/mounter.js` | Mount factory |
+| `react-extn/src/ReactBackboneModules/index.js` | Registration (add import + entry) |
+
+---
+
+## Step 4 — Create the Module Folder
+
+Create `src/modules/<featureName>/`. The gulp build auto-discovers all folders under `src/modules/`
+via `build_utils.getModules()` — no manual webpack alias registration is needed.
+
+---
+
+## Step 5 — Scaffold the Files
+
+### Conventions
+- **CommonJS only** (`require` / `module.exports`) for all Backbone files
+- **IIFE pattern** wrapping `Backbone.Model.extend` / `Backbone.Collection.extend`
+- **Plain IIFE singleton** for Controllers — not a Backbone class
+- **Template IDs** → `h-<feature-name>-<element>` (must be globally unique across the app)
+- **`destroyView`** is the standard teardown method — not `close` or `remove` alone
+
+## 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 |
+|-------|------|--------------|
+| Backbone scaffolds (Model, Collection, View, Controller, Template, SASS) | [references/backbone-scaffolds.md](references/backbone-scaffolds.md) | When creating Backbone files |
+| React mount path (mounter, registration, wiring) | [references/react-mount-path.md](references/react-mount-path.md) | Only when using React Mount path |
+
+---
+
+## Checklist
+
+- [ ] Rendering path chosen (Backbone template or React mount) with clear reasoning
+- [ ] `src/modules/<featureName>/` folder created
+- [ ] Model created (if needed)
+- [ ] Collection created (if needed)
+- [ ] View created with `destroyView`
+- [ ] Controller created only if logic is shared externally
+- [ ] `templates.html` created with `h-` prefixed IDs (Backbone path)
+- [ ] `src/sass/framework_revamp/<featureName>.sass` created and `@import` added to `style.sass`
+- [ ] React component + mounter created (React path)
+- [ ] Mounter registered in `ReactBackboneModules/index.js` (React path)
+- [ ] `window.react?.modules.<name>.mount(...)` called in View with `this.reactRoot` stored (React path)
+- [ ] `this.reactRoot.unmount()` called in `destroyView` before `this.remove()` (React path)

package/collections/extension/skills/build-backbone-component/references/backbone-scaffolds.md

@@ -0,0 +1,162 @@
+# Backbone Scaffolds — Code Templates
+
+## Model (`<FeatureName>Model.js`)
+
+```js
+var Backbone = require('backbone');
+var _ = require('underscore-new');
+
+var <FeatureName>Model = (function() {
+    return Backbone.Model.extend({
+        defaults: function() {
+            return {
+                // default attributes
+            };
+        }
+    });
+})();
+
+module.exports = <FeatureName>Model;
+```
+
+---
+
+## Collection (`<FeatureName>Collection.js`)
+
+```js
+var Backbone = require('backbone');
+var <ItemModel> = require('<ItemModel>');
+
+var <FeatureName>Collection = (function() {
+    'use strict';
+    return Backbone.Collection.extend({
+        model: <ItemModel>,
+        comparator: function(m) {
+            // optional: return the value to sort by
+        }
+    });
+})();
+
+module.exports = <FeatureName>Collection;
+```
+
+---
+
+## View (`<FeatureName>View.js`)
+
+```js
+var Backbone = require('backbone');
+var $ = require('jquery');
+var _ = require('underscore-new');
+
+var <FeatureName>View = Backbone.View.extend({
+
+    template: _.template($('#h-<feature-name>-container').html()),
+
+    initialize: function(options) {
+        this.options = options;
+        this.listenTo(this.model, 'change:<attr>', this.render);
+    },
+
+    events: {
+        'click .h-<feature-name>-btn': 'handleClick',
+    },
+
+    render: function() {
+        this.$el.html(this.template(this.model.toJSON()));
+        return this;
+    },
+
+    handleClick: function(e) {
+        // event handler
+    },
+
+    destroyView: function() {
+        this.undelegateEvents();
+        this.model.unbind();            // omit if no model
+        this.$el.removeData().unbind();
+        // remove external listeners:  document.removeEventListener(...)
+        // unmount React children:     this.reactRoot && this.reactRoot.unmount()
+        this.remove();
+        Backbone.View.prototype.remove.call(this);
+    },
+});
+
+module.exports = <FeatureName>View;
+```
+
+---
+
+## Controller (`<FeatureName>Controller.js`)
+
+Only create when this module's logic or state needs to be accessed by other modules.
+
+```js
+var $ = require('jquery');
+var _ = require('underscore-new');
+var <FeatureName>Model = require('<FeatureName>Model');
+var <FeatureName>View = require('<FeatureName>View');
+
+var <FeatureName>Controller = (function() {
+    'use strict';
+
+    var viewInstance = null;
+
+    function render(el, data) {
+        var model = new <FeatureName>Model();
+        model.set(data);
+        viewInstance = new <FeatureName>View({ model: model, el: el });
+        viewInstance.render();
+    }
+
+    function clearView() {
+        if (viewInstance) {
+            viewInstance.destroyView();
+            viewInstance = null;
+        }
+    }
+
+    function init() {
+        // subscribe to pubsub events if needed
+    }
+
+    init();
+
+    return {
+        render: render,
+        clearView: clearView,
+    };
+})();
+
+module.exports = <FeatureName>Controller;
+```
+
+---
+
+## Template (`templates.html`)
+
+```html
+<script type="text/template" id="h-<feature-name>-container">
+    <div class="h-<feature-name>">
+        <!--
+            Underscore template syntax:
+            <%= value %>   escaped output
+            <%- value %>   unescaped output
+            <% code %>     logic / conditionals
+        -->
+    </div>
+</script>
+```
+
+The gulp `build_template_files` task auto-picks up `templates.html` from every module folder —
+no manual registration needed.
+
+---
+
+## SASS (`src/sass/framework_revamp/<featureName>.sass`)
+
+Create the file, then add one line to `src/sass/framework_revamp/style.sass`:
+
+```sass
+@import '<featureName>'
+```

package/collections/extension/skills/build-backbone-component/references/react-mount-path.md

@@ -0,0 +1,93 @@
+# React Mount Path — Mounting React Inside Backbone
+
+## React Component + Mounter
+
+**Without Redux** (component uses React Query only or is stateless):
+
+```jsx
+// react-extn/src/<FeatureName>/mounter.js
+import { createRoot } from 'react-dom/client';
+import { HiverProvider } from '@hiver/hiver-ui-kit';
+import HiverQueryClientProvider from '../../reactQueryClient.js';
+import { <FeatureName> } from './<FeatureName>';
+
+export const mount<FeatureName> = (container, props) => {
+    const root = createRoot(container);
+    root.render(
+        <HiverProvider>
+            <HiverQueryClientProvider>
+                <FeatureName> {...props} unmount={() => root.unmount()} />
+            </HiverQueryClientProvider>
+        </HiverProvider>
+    );
+    return root.unmount.bind(root);
+};
+```
+
+**With Redux** (component reads from or dispatches to the Redux store):
+
+```jsx
+// react-extn/src/<FeatureName>/mounter.js
+import { createRoot } from 'react-dom/client';
+import { Provider } from 'react-redux';
+import { HiverProvider } from '@hiver/hiver-ui-kit';
+import HiverQueryClientProvider from '../../reactQueryClient.js';
+import { <FeatureName> } from './<FeatureName>';
+
+export const mount<FeatureName> = (store) => (container, props) => {
+    const root = createRoot(container);
+    root.render(
+        <HiverProvider>
+            <HiverQueryClientProvider>
+                <Provider store={store}>
+                    <FeatureName> {...props} unmount={() => root.unmount()} />
+                </Provider>
+            </HiverQueryClientProvider>
+        </HiverProvider>
+    );
+    return root.unmount.bind(root);
+};
+```
+
+## Register in `ReactBackboneModules/index.js`
+
+Add the import at the top of the file:
+```js
+import { mount<FeatureName> } from '../<FeatureName>/mounter';
+```
+
+Inside `appendReactBackboneModules()`, add to the `modules` object:
+```js
+// without Redux:
+<featureName>: createModule(mount<FeatureName>),
+
+// with Redux:
+<featureName>: createModule(mount<FeatureName>(store)),
+```
+
+Use camelCase for the module key.
+
+## Wire mount/unmount in the Backbone View
+
+```js
+// in initialize or render — create container and mount:
+var container = document.createElement('div');
+container.id = 'h-<feature-name>-react-root';
+this.$el.find('.h-<feature-name>-mount-point').append(container);
+this.reactRoot = window.react?.modules.<featureName>.mount(container, {
+    prop1: this.model.get('attr1'),
+});
+
+// in destroyView — unmount before remove:
+destroyView: function() {
+    this.undelegateEvents();
+    this.model.unbind();
+    this.$el.removeData().unbind();
+    if (this.reactRoot) {
+        this.reactRoot.unmount();
+        this.reactRoot = null;
+    }
+    this.remove();
+    Backbone.View.prototype.remove.call(this);
+}
+```

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

@@ -0,0 +1,33 @@
+---
+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.
+
+## 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 |
+|-------|------|--------------|
+| Figma integration | [references/figma-integration.md](references/figma-integration.md) | Only when a Figma link is present |
+| UI Kit and styling | [references/ui-kit-and-styling.md](references/ui-kit-and-styling.md) | Before writing component JSX/styles |
+| Layout and structure | [references/layout-and-structure.md](references/layout-and-structure.md) | Only when laying out a new screen/panel |
+| Icons | [references/icons.md](references/icons.md) | Only when adding icons |
+| Component organization | [references/component-organization.md](references/component-organization.md) | Only when splitting into sub-components |
+| 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/extension/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/extension/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/extension/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/extension/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/extension/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