@muskanmeet/invoicing-design-system 0.1.0

package/.local/skills/media-generation/video_generation.md

@@ -0,0 +1,82 @@
+# Video Generation
+
+## Available Functions
+
+### generateVideo(prompt, ...)
+
+Generate short video clips from text descriptions.
+
+**Parameters:**
+
+- `prompt` (str, required): Detailed text description of the desired video
+- `summary` (str, default "generated_video"): Short description for the filename
+- `aspectRatio` (str, default "16:9"): "16:9" (landscape) or "9:16" (portrait)
+- `resolution` (str, default "720p"): "720p" or "1080p"
+- `durationSeconds` (int, default 6): 4, 6, or 8 seconds
+- `negativePrompt` (str, optional): Description of what should NOT appear
+- `personGeneration` (str, optional): "dont_allow" or "allow_adult" for controlling people
+
+**Returns:** Dict with `filePath` and `description` keys
+
+**Example:**
+
+```javascript
+const result = await generateVideo({
+    prompt: "A cat playing with a ball of yarn, cute and playful, natural lighting",
+    summary: "playful cat",
+    aspectRatio: "16:9",
+    durationSeconds: 6
+});
+console.log(`Video saved to: ${result.filePath}`);
+```
+
+### generateVideoAsync(prompt, ...)
+
+Generate a video asynchronously. Returns immediately with a workflow ID. Same parameters as `generateVideo`.
+
+**Returns:** Dict with `workflowId`, `workflowAlias`, `status`, and `videoPath`
+
+**Example:**
+
+```javascript
+const result = await generateVideoAsync({
+    prompt: "A cat playing with a ball of yarn, cute and playful, natural lighting",
+    summary: "playful cat",
+    aspectRatio: "16:9",
+    durationSeconds: 6
+});
+console.log(`Started workflow: ${result.workflowAlias}`);
+console.log(`Video will be saved to: ${result.videoPath}`);
+
+// Later, wait for completion
+await wait_for_background_tasks({ wait_mode: "all" });
+```
+
+## When to Use Each Function
+
+### generateVideo / generateVideoAsync
+
+- Use `generateVideoAsync` when the video is not needed immediately
+- Short animated clips or motion graphics
+- Video backgrounds or visual effects
+- Product animations or demonstrations
+- Social media video content
+
+## Aspect Ratio Guidelines
+
+### Videos
+
+- **16:9** - Widescreen landscape, good for web videos, presentations
+- **9:16** - Vertical portrait, good for mobile stories, social media shorts
+
+## Output Locations
+
+- Generated videos: `attached_assets/generated_videos/`
+
+## Limitations
+
+- Generated videos: 8 seconds maximum
+
+## Copyright
+
+- Generated videos are created for your use

package/.local/skills/mockup-extract/.fingerprint

@@ -0,0 +1 @@
+cdb85d2e7b5700016ed2203343b439c4

package/.local/skills/mockup-extract/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: mockup-extract
+description: "Use when the user wants to pull an existing component from their main app onto the canvas — whether to redesign it, create variants, or simply display it as a visual reference. Also activate when the user asks to redesign, improve, or create variants of any UI that already exists as code in the main app, even if they don't explicitly say 'extract' — the real source code must be used as the starting point, never hand-coded approximations. Copies the component and its dependencies into the mockup sandbox, rewrites imports, stubs external dependencies, and embeds the result as an iframe on the canvas. Activate when the user says 'put my X on the canvas', 'show my current Y on the board', 'redesign my existing Z', 'create variants of my current W', 'improve my Y', or wants to see or iterate on something already in the app."
+---
+
+# Mockup Extract Skill
+
+Pull an existing component from the main app into the `mockup/` sandbox so it can be previewed on the canvas and used as a starting point for design iteration.
+
+## When to Use
+
+Activate this skill when the user:
+
+- Wants to see an existing component on the canvas as a visual reference ("show my homepage on the board", "put my current settings page on the canvas")
+- Wants to redesign an existing component ("redesign my navbar", "redo my pricing page", "improve the onboarding flow")
+- Wants to create variants starting from an existing component
+- Needs to compare their current design against new alternatives
+
+**Important:** This skill must also be activated implicitly when the user asks to redesign, improve, or create variants of something that already exists as code in the main app — even if they don't say "extract". If the component exists in the codebase, extract it first. Never rebuild an existing component from scratch by hand-coding approximations; you will get exact dimensions, colors, spacing, opacity values, and other details wrong. The real source code has the correct values.
+
+## Subagent Guidance
+
+If you need to parallelize extraction (e.g., extract multiple components at once), use a **GENERAL** subagent — never a DESIGN subagent. Extraction is an engineering task (import graph tracing, dependency stubbing, path rewriting) that requires codebase navigation, not creative visual output.
+
+## Prerequisites
+
+The mockup sandbox must be set up first. If `mockup/` doesn't exist, activate the {{skill("mockup-sandbox")}} skill to set it up before proceeding.
+
+## Do Not Iframe the Main App Directly
+
+When the user asks to "show my component on the canvas" or "redesign my navbar," do **not** create an iframe pointing at the main app's dev server URL. This is the wrong approach because:
+
+- It shows the entire app (navbar, sidebar, footer, routing), not the target component in isolation
+- You cannot create independent design variants from it
+- Clicking links or buttons inside the iframe navigates away from the component
+- Editing the main app code changes the iframe live, making it impossible to compare before/after
+
+Instead, always extract the component into the `mockup/` sandbox and embed the sandbox's `/preview/` URL.
+
+## Process
+
+### Step 1: Locate and read the target component
+
+Ask the user which component to extract if it isn't clear. Read the component file and understand its structure and imports.
+
+### Step 2: Analyze the dependency tree
+
+Read the target component and trace every import. Classify each dependency:
+
+| Category | When | Action |
+|---|---|---|
+| **Inline** | Small sub-components, simple hooks, utility functions (<50 lines) | Copy the code directly into the mockup file |
+| **Copy** | Larger shared components, complex hooks, asset files | Copy into `mockup/src/` with updated import paths |
+| **Stub** | Context providers, API calls, routing, auth, global state | Replace with static mock data or no-op wrappers |
+
+Walk the full import chain -- a component may import a hook that imports a context that imports an API client. Trace until you reach leaf dependencies or hit a stub boundary.
+
+### Step 3: Handle external dependencies
+
+For dependencies that can't transfer cleanly:
+
+- **API calls / data fetching:** Replace with hardcoded mock data matching the response shape. Use realistic values.
+- **Context providers (auth, theme):** Inline the values as constants.
+- **Routing (`useNavigate`, `Link`, `useParams`):** Replace with no-ops or static values.
+- **Global state (Redux, Zustand):** Extract the relevant slice as a local `useState` or constant.
+
+### Step 4: Rewrite import paths
+
+`@/` resolves to different roots in the main app vs the sandbox:
+
+- Main app: `@/` → `client/src/`
+- Sandbox: `@/` → `mockup/src/`
+
+Every `@/` import must point to a file that exists under `mockup/src/`. If the imported file doesn't exist in the sandbox, either copy it there or inline it. `@/components/ui/*` imports work without changes (shadcn/ui is pre-installed).
+
+### Step 5: Create `_group.css` and the mockup component
+
+The main app's global styles are invisible to Step 2's import trace — they live in `index.html` `<link>` tags and global CSS, not in any `import` statement. Collect them into a group-level stylesheet that every component in this group will explicitly import.
+
+Create `mockup/src/components/mockups/{group}/_group.css` with everything the app applies globally:
+
+- **CSS variables** — copy the `:root` and `.dark` blocks from the main app's `client/src/index.css` so semantic classes like `bg-background` and `text-foreground` resolve to the app's values, not the sandbox defaults.
+- **External font links** — read the main app's `client/index.html` for `<link href="https://fonts.googleapis.com/...">` (or Adobe Fonts, etc.) and convert each to `@import url("...");` at the top of `_group.css`.
+- **`@font-face` declarations** — if the main app self-hosts fonts, copy the `@font-face` blocks and the font files they reference.
+
+Do **not** edit the sandbox's global `index.css` — that leaks this app's tokens into every unrelated mockup group. Do **not** add font `<link>` tags to `mockup/index.html` — that file is shared across all mockup groups, so app-specific fonts would load for every unrelated preview. The sandbox already pre-loads a large common font bundle there; put any additional app-specific fonts in `_group.css` via `@import` to keep them scoped to this extraction.
+
+Then create `mockup/src/components/mockups/{group}/Current.tsx`:
+
+```tsx
+import './_group.css';
+
+export function Current() {
+  // ... extracted component
+}
+```
+
+The `_group.css` import loads after the plugin's base `index.css` import, so its rules win by normal cascade order. Every variant you create later (`VariantA.tsx`, `VariantB.tsx`) also imports `./_group.css` to inherit the same baseline. A variant that needs to diverge adds a second import for its own sibling CSS file.
+
+Use a descriptive group name (e.g., `navbar-redesign/`). Export a single component per file; named or default exports both work. Use `min-h-screen` on the root element.
+
+### Step 6: Type-check, embed, and create variants
+
+Type-check with `cd mockup && npm run check`. Embed on the canvas using the sandbox `/preview/` URL (see {{skill("mockup-sandbox")}} for iframe creation). Label it "Current", then create new variant files alongside it.
+
+## Guidelines
+
+- **Prefer inlining over copying.** Fewer files = easier iteration. Inline anything under ~50 lines.
+- **Keep mock data realistic.** Visual fidelity depends on it.
+- **Don't import from the main app.** Every import must resolve within `mockup/src/`.
+- **Preserve the visual output exactly.** The extracted component should look identical to the original.
+- **Copy assets first.** Images and icons must exist in `mockup/` before the component references them.
+
+## Common Mistakes
+
+- **Leaving `@/` imports pointing to main app files.** Every `@/` path must resolve under `mockup/src/`.
+- **Forgetting nested dependencies.** Trace the full import chain — component → hook → context → API client.
+- **Not stubbing side effects.** API calls, analytics, and router navigations will crash in the sandbox.
+- **Copying too much.** Extract only what the target component needs.
+- **Editing the global `index.css` instead of creating `_group.css`.** The extraction's tokens leak into every other mockup group in the sandbox.
+- **Forgetting `import './_group.css'` in the component file.** Without it the component renders with sandbox defaults, not the app's tokens. No error — it just looks wrong.
+- **Adding font `<link>` tags to `mockup/index.html`.** That file is shared across all mockup groups — app-specific fonts leak into every unrelated preview. Put fonts in `_group.css` via `@import` instead to keep them scoped to this group.
+- **Assuming fonts loaded because nothing errored.** Missing fonts fall back silently — no console error, no build failure. The component still renders, just with the wrong stroke weight, character width, and spacing. Verify typography visually against the original; "it didn't crash" is not "it looks right."

package/.local/skills/mockup-graduate/.fingerprint

@@ -0,0 +1 @@
+a34b27d1f23f55c674d3a44dccf5752b

package/.local/skills/mockup-graduate/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: mockup-graduate
+description: "Use when the user approves a mockup on the canvas and wants it integrated into their main app. Reads the approved mockup component, analyzes the main app's patterns, transforms the mockup to match, installs dependencies, and verifies the integration. Activate when the user says 'use this one', 'put this in my app', 'I like variant B, integrate it', 'graduate this mockup', or approves a design for production."
+---
+
+# Mockup Graduate Skill
+
+Move an approved mockup from the mockup sandbox (`mockup`) into the main app. Transform the self-contained prototype into production code that matches the app's conventions.
+
+## When to Use
+
+Activate this skill when the user:
+
+- Approves a mockup variant ("I like this one", "go with the bold version")
+- Asks to integrate a mockup ("put this in my app", "use this design")
+- Wants to graduate a prototype to production
+- Says "ship it" or "let's go with this"
+
+## Subagent Guidance
+
+If you need to parallelize graduation (e.g., graduate multiple pages at once), use a **GENERAL** subagent — never a DESIGN subagent. Graduation is an engineering task (understanding app architecture, transforming mockup code to production patterns, wiring routing and state) that requires codebase navigation, not creative visual output.
+
+## Prerequisites
+
+- The mockup sandbox must be running ({{skill("mockup-sandbox")}})
+- The user must have identified which mockup to graduate (if multiple variants exist, ask which one)
+
+## Process
+
+### Step 1: Identify the approved mockup
+
+Confirm which mockup the user wants. Read the mockup component file and extract key design decisions: colors, gradients, shadows, typography, layout approach, icons, and animations.
+
+### Step 2: Analyze the main app's patterns
+
+Understand how the main app handles routing, state management, data fetching, styling, and component structure. Read a few existing components to understand conventions.
+
+### Step 3: Plan the transformation
+
+Map each part of the mockup to the main app's equivalent:
+
+| Mockup | Main App |
+|---|---|
+| Hardcoded mock data | API call or data hook |
+| Inline sub-components | Existing shared components where they exist |
+| Direct `className` styling | App's styling approach (may be the same) |
+| `@/components/ui/*` (sandbox shadcn) | App's UI component library (may differ) |
+| Static images from `mockup/` | App's asset directory or CDN |
+
+### Step 4: Install missing dependencies
+
+Compare the mockup's imports against the main app's `package.json`. Install anything missing using the `packager_install_tool`. Add font links to `index.html` if needed.
+
+### Step 5: Transform and place the component
+
+Create the production component in the main app. Replace mock data with real data fetching, wire up navigation, connect to app state, and adapt UI components to the app's library. Copy any assets from `mockup/` to the main app's asset directory.
+
+### Step 6: Update routing and verify
+
+Add a route if the graduated component is a new page. If it replaces an existing component, update the import. Run the main app's linter, restart the workflow, and confirm it renders correctly.
+
+### Step 7: Clean up (optional)
+
+Ask the user if they want to remove the graduated mockup from the sandbox, keep it for reference, or remove the canvas iframes. Don't clean up automatically.
+
+## When Graduation Is Complex
+
+Most graduations are straightforward — just proceed. Only pause and check with the user when the main app uses a fundamentally different design system than the mockup (requiring a full visual translation), or when the graduation would require a complete refactor of the existing backend to support the new design.
+
+## What to Preserve
+
+These elements from the mockup should transfer exactly to production:
+
+- **Visual design:** Colors, gradients, shadows, border radius, spacing
+- **Typography:** Font families, weights, sizes, line heights
+- **Layout:** Grid/flex structure, responsive breakpoints, spacing
+- **Animations:** Transitions, hover states, entry animations
+- **Icons:** Same icon library and icon choices
+
+## What to Transform
+
+These elements need adaptation for production:
+
+- **Data:** Static mock data → real API calls or state
+- **Navigation:** No-op handlers → real router navigation
+- **State:** Local constants → app state management
+- **Auth:** Stubbed user objects → real auth context
+- **Error handling:** Add loading states, error boundaries, empty states
+- **Accessibility:** Add ARIA labels, keyboard navigation, focus management
+
+## Common Mistakes
+
+- **Losing visual fidelity during transformation.** Ship what was approved — don't "improve" the design during graduation.
+- **Forgetting loading and error states.** Mockups show the happy path. Production needs skeletons, error messages, and empty states.
+- **Not checking the UI component library.** If the main app uses different components than shadcn/ui, translate — don't just copy imports.
+- **Breaking existing functionality.** If replacing an existing component, ensure all existing features still work.
+- **Skipping responsive behavior.** If the mockup was designed at a single viewport, ensure it works at other breakpoints.

package/.local/skills/mockup-sandbox/.fingerprint

@@ -0,0 +1 @@
+af8435a76628ddd12e5fb24236243221