@mehuljatiya/troupe 0.1.15

package/commands/figma.md

@@ -0,0 +1,56 @@
+Help me turn a Figma design into working code.
+
+---
+
+## Prerequisites — Check Figma MCP
+
+Before doing anything, call `mcp__claude_ai_Figma__whoami`. If it fails or returns an auth error, stop and tell the user:
+
+> **Setup required before this command can run:**
+>
+> 1. Open the **Claude desktop app**
+> 2. Go to **Settings → Integrations**
+> 3. Find **Figma** and click **Enable**
+> 4. **Quit and relaunch** Claude Code — the MCP won't load until you restart
+> 5. Then re-run `/figma` with your Figma URL
+>
+> If you've already done this and it still fails, run `claude mcp add --transport http figma https://mcp.figma.com/mcp --scope user` in your terminal, then restart.
+
+Do not proceed until Figma MCP is confirmed working.
+
+---
+
+The user will paste a Figma URL. Here's what to do:
+
+**Step 1 — Read the design**
+Use the Figma MCP tools to understand what's being designed:
+- Call `get_design_context` with the URL (use `forceCode: true`)
+- Get each variant/state individually so you see the full picture
+- Call `get_screenshot` to visually confirm what you're seeing
+
+**Step 2 — Describe it before coding**
+In plain language (no code), tell the user:
+- What kind of component this is (button, card, nav, form field, etc.)
+- What states or variants it has
+- What the key interaction is
+
+Ask for the component name if it's not obvious from the design.
+
+**Step 3 — Understand the project**
+Before writing anything, look at the current project:
+- What framework/tech stack is being used?
+- What existing components exist to follow as patterns?
+- What design tokens or CSS variables are available?
+- Never use hardcoded colors, sizes, or fonts — use project tokens
+
+**Step 4 — Build it**
+Implement the component following the project's existing patterns.
+After building, tell the user:
+- What files were created/changed
+- How to find and use the component
+- Any decisions you made that they might want to adjust
+
+Keep all explanations in plain, friendly language. If you hit something unclear, ask before guessing.
+
+---
+If the user hasn't shared a Figma URL yet, ask them for it now.

package/commands/handoff.md

@@ -0,0 +1,92 @@
+Generate a developer handoff document for a component.
+
+If the user hasn't specified which component, ask them.
+
+Create a thorough, precise handoff spec that a developer could use to build this component from scratch. Be exact — use real token names, real pixel values, real behavior descriptions.
+
+---
+
+## [Component Name] — Handoff Spec
+
+**Overview**
+What this component is and what problem it solves. Where it lives in the product.
+
+---
+
+**Visual Specs**
+
+| Property | Value |
+|---|---|
+| Width / Height | |
+| Padding | |
+| Gap / spacing | |
+| Border radius | (token name + px value) |
+| Border | (width, style, color token) |
+| Background | (token name) |
+| Shadow | (token name or none) |
+
+Typography:
+- Label: font, size, weight, color token
+- (add any other text elements)
+
+---
+
+**States**
+
+For each state, describe exactly what changes visually:
+
+| State | What changes |
+|---|---|
+| Default | |
+| Hover | |
+| Focus | |
+| Active / pressed | |
+| Disabled | |
+| Loading | (if applicable) |
+| Error | (if applicable) |
+
+Transitions: describe any animations (duration, easing, what animates).
+
+---
+
+**Interactions**
+
+Mouse / touch:
+- Click / tap: what happens
+- Long press: (if applicable)
+
+Keyboard:
+- Tab: focus behavior
+- Enter / Space: action
+- Escape: (if applicable)
+- Arrow keys: (if applicable)
+
+---
+
+**Responsive behavior**
+
+Describe how the component adapts at:
+- Mobile (< 768px)
+- Tablet (768px – 1024px)
+- Desktop (> 1024px)
+
+---
+
+**Accessibility requirements**
+
+- Role: (button, link, checkbox, etc.)
+- Required ARIA attributes
+- Screen reader announcement on interaction
+- Focus visible style
+- Minimum touch target size
+
+---
+
+**Open questions**
+
+List anything that still needs a design decision or clarification.
+
+---
+
+Save as `[ComponentName].handoff.md` next to the component file.
+Confirm the save location when done.

package/commands/new-component.md

@@ -0,0 +1,26 @@
+Help me create a new component.
+
+Start a short, friendly conversation to understand what they need before writing any code.
+
+**Ask these questions (one at a time, not all at once):**
+1. "What should this component do?" — let them describe in plain language
+2. "Can you describe what it looks like? Or share a sketch, screenshot, or reference link?"
+3. "Does it need any special states — like a loading state, disabled version, or error message?"
+
+**Then, before building:**
+- Look at 2–3 existing components in this project to understand the patterns used
+- Check what design tokens and styles are available
+- Confirm the component name with the user if it's not clear
+
+**Build it:**
+- Follow the same structure, file naming, and patterns as existing components
+- Use design tokens and project styles — never hardcode colors, fonts, or spacing
+- Keep it focused — only build what was asked for, nothing extra
+- Add just enough to make it functional: no over-engineering
+
+**When done, tell the user:**
+- The name and location of every file created
+- How to use/import the component
+- What you'd suggest they try or configure first
+
+Speak in plain, encouraging language. Avoid jargon. If something requires a decision, explain the trade-off simply and let them choose.

package/commands/qa.md

@@ -0,0 +1,89 @@
+Compare a Figma design to what's actually built and flag gaps.
+
+If the user hasn't shared a Figma URL, ask for one. Also ask which component or file in the codebase to compare it against.
+
+---
+
+## Step 1 — Read the design
+
+Call `mcp__claude_ai_Figma__whoami` first. If it fails, tell the user:
+
+> **Setup required:**
+> 1. Open Claude desktop app → Settings → Integrations → Enable Figma
+> 2. Quit and relaunch Claude Code
+> 3. Re-run `/qa` with your Figma URL
+
+Call `get_design_context` on the provided URL. Call `get_screenshot` to get a visual reference of every variant and state.
+
+---
+
+## Step 2 — Read the built component
+
+Find the component in the codebase. Read its implementation and any associated styles, tokens, and tests.
+
+---
+
+## Step 3 — Compare and report
+
+Output a gap analysis report in this format:
+
+```
+# QA Report — [Component Name]
+Figma: [url]
+Built: [file path]
+
+## Summary
+One sentence verdict: how close is the implementation to the design?
+
+## Gaps Found
+
+### Visual
+| Property | Figma | Built | Severity |
+|---|---|---|---|
+| [property] | [design value] | [actual value] | High / Medium / Low |
+
+### Missing States
+List every state visible in Figma that is not handled in the implementation.
+
+| State | In Figma | In Code | Notes |
+|---|---|---|---|
+| [state] | ✓ | ✗ | [what's missing] |
+
+### Missing Variants
+List every variant in Figma that has no corresponding implementation.
+
+### Interaction gaps
+Describe any behaviours defined in the design (hover, transitions, animations) that are missing or wrong in the code.
+
+### Accessibility gaps
+- Missing ARIA attributes
+- Keyboard navigation issues
+- Colour contrast failures (compare design tokens to WCAG AA)
+
+## What's correct
+List things that match the design well — this gives the developer confidence in what not to change.
+
+## Recommended fixes
+Prioritised list of what to fix, most important first.
+
+1. [Fix] — why it matters
+2. [Fix] — why it matters
+```
+
+---
+
+## Severity guide
+
+- **High** — visible to users, breaks the intended experience, or blocks accessibility
+- **Medium** — noticeable difference but doesn't break functionality
+- **Low** — minor polish, pixel-level spacing, or nice-to-have
+
+---
+
+## Quality check
+
+Before finishing:
+- [ ] Every state in Figma is checked against the code
+- [ ] All gaps have a severity rating
+- [ ] Recommended fixes are ordered by impact, not by what's easiest
+- [ ] Nothing invented — all findings come from the Figma file and codebase

package/commands/review.md

@@ -0,0 +1,49 @@
+Review this component or design for quality.
+
+If the user hasn't said what to review, ask which component or file they're working on.
+
+Look at the component carefully and evaluate each area below. Be specific — don't just say "looks good", point to exact things.
+
+---
+
+**Consistency**
+- Are design tokens and CSS variables used, or are there hardcoded values (colors, spacing, font sizes)?
+- Does the visual style match other components in this project?
+- Is naming consistent with the rest of the codebase?
+
+**Completeness — states**
+Check that all of these are handled (visually and functionally):
+- [ ] Default
+- [ ] Hover
+- [ ] Focus (keyboard)
+- [ ] Active / pressed
+- [ ] Disabled
+- [ ] Loading (if the component triggers async actions)
+- [ ] Error / validation
+- [ ] Empty state (if the component can have no content)
+
+**Responsiveness**
+- Does it work on mobile screen sizes?
+- Is text readable and tappable (minimum 44px touch targets)?
+- Does it reflow or adapt, or does it break?
+
+**Accessibility**
+- Can it be navigated by keyboard alone?
+- Is color contrast sufficient for text and icons?
+- Are interactive elements labeled for screen readers?
+- Does it work with browser zoom up to 200%?
+
+**Edge cases**
+- What happens with very long or very short text?
+- What if an image fails to load?
+- What if there's no data / empty content?
+
+---
+
+Format the review using these ratings for each finding:
+✓ **Good** — working as expected, worth calling out
+⚠ **Needs attention** — works but could be better; explain why it matters
+✗ **Missing** — not handled; explain the impact and how to fix it
+
+End with a short "Priority fixes" list (max 3 items) if there are any ✗ findings.
+Write for a designer — plain language, no code jargon unless necessary.

package/commands/spec.md

@@ -0,0 +1,77 @@
+Generate a ticket-ready spec from a Figma design.
+
+If the user hasn't shared a Figma URL, ask for one before proceeding.
+
+---
+
+## Step 1 — Read the design
+
+Call `mcp__claude_ai_Figma__whoami` first. If it fails, tell the user:
+
+> **Setup required:**
+> 1. Open Claude desktop app → Settings → Integrations → Enable Figma
+> 2. Quit and relaunch Claude Code
+> 3. Re-run `/spec` with your Figma URL
+
+Call `get_design_context` on the provided URL. Also call `get_screenshot` to visually verify all variants and states.
+
+---
+
+## Step 2 — Write the spec
+
+Output a structured spec a PM could paste directly into a Jira/Linear ticket or Notion page.
+
+```
+# [Component / Feature Name] — Spec
+
+## Overview
+One paragraph: what this is, what problem it solves, where it lives in the product.
+
+## Variants & States
+List every variant and state visible in the Figma design. Do not invent states that don't exist in the file.
+
+| Variant / State | Description | Trigger |
+|---|---|---|
+| [name] | [what it looks like] | [what causes it] |
+
+## Behaviour
+Describe every interaction:
+- What happens on click / tap
+- What happens on hover
+- Any transitions or animations
+- Error handling visible in the design
+
+## Edge Cases
+List at least 3 non-obvious edge cases the developer needs to handle:
+- Empty state (no data / no content)
+- Long text / overflow
+- Loading state
+- Error state
+- Any other edge cases visible or implied by the design
+
+## Acceptance Criteria
+Bulleted checklist a developer can use to verify the feature is complete. Write each item as a testable statement starting with "User can..." or "System should...".
+
+- [ ] User can...
+- [ ] System should...
+
+## Open Questions
+List anything that is unclear or not defined in the Figma file that needs a decision before development starts.
+
+1. [Question]
+2. [Question]
+
+## Out of Scope
+Explicitly list anything that looks related but is NOT part of this ticket.
+```
+
+---
+
+## Quality check
+
+Before finishing, verify:
+- [ ] Every state visible in Figma is listed
+- [ ] At least 3 edge cases documented
+- [ ] Acceptance criteria are testable, not vague
+- [ ] Open questions flag actual gaps — do not leave this section empty if there are genuine unknowns
+- [ ] Nothing invented — all content comes from the Figma file

package/commands/tokens.md

@@ -0,0 +1,42 @@
+Help me understand the design tokens in this project.
+
+Look through the project for design tokens — CSS variables, theme files, token definitions, or any named design values.
+
+Organize them into a readable reference guide grouped by type:
+
+---
+
+**Colors**
+For each color token:
+- Name (what it's called in the code)
+- Value (the actual hex/rgb/etc.)
+- Purpose (plain English: "Used for primary buttons and links")
+- Group by role: backgrounds, text, borders, brand, status (success/error/warning/info)
+
+**Typography**
+- Font families and what they're used for
+- Type sizes and their intended use (heading 1, body, caption, etc.)
+- Font weights available
+
+**Spacing**
+- The spacing scale (4px, 8px, 16px, etc.)
+- What each size is typically used for (padding inside buttons, gap between sections, etc.)
+
+**Shape**
+- Border radius values and when to use each
+- Border/stroke widths
+
+**Shadows & elevation**
+- Shadow tokens and the visual hierarchy they create
+
+---
+
+**Hardcoded values to fix**
+After listing the tokens, scan the codebase for hardcoded values (raw hex colors, pixel values not using tokens, font sizes not referencing the scale).
+List any you find with the file and a suggestion for which token to use instead.
+
+---
+
+Write this as a designer-friendly reference, not a code dump.
+For colors, if you can describe them visually ("a light warm grey", "vivid blue"), do that alongside the hex value.
+If the token naming is confusing or inconsistent, flag it.

package/package.json

@@ -0,0 +1,44 @@
+{
+  "name": "@mehuljatiya/troupe",
+  "version": "0.1.15",
+  "description": "AI-powered workflow toolkit for designers, developers, and PMs — 9 slash commands for Claude Code",
+  "type": "module",
+  "bin": {
+    "troupe": "bin/cli.js",
+    "design": "bin/design.js"
+  },
+  "files": [
+    "bin/",
+    "src/",
+    "commands/"
+  ],
+  "scripts": {
+    "start": "node bin/cli.js setup",
+    "release": "npm version patch && git push && npm publish --access public"
+  },
+  "keywords": [
+    "claude",
+    "claude-code",
+    "design",
+    "figma",
+    "ai",
+    "designer",
+    "developer",
+    "product-manager",
+    "troupe",
+    "cli"
+  ],
+  "author": "Mehul Jatiya",
+  "license": "MIT",
+  "dependencies": {
+    "@inquirer/prompts": "^7.0.0",
+    "chalk": "^5.3.0"
+  },
+  "engines": {
+    "node": ">=20"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/mehuljatiya/troupe.git"
+  }
+}