@relipa/ai-flow-kit 0.0.1

package/custom/skills/figma-to-component/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: figma-to-component
+description: Read designs from Figma and generate React/Next.js/Vue components following project conventions. Supports specific frame URLs and entire pages.
+keywords: figma, design, component, ui, generate, react, nextjs, vue, frontend
+---
+
+# Figma to Component
+
+## When to use
+
+- Received a Figma link from a designer and need to generate a component
+- Designer has approved the UI, developer starts implementation
+- Need to ensure pixel-perfect matching with the design
+
+---
+
+## Process
+
+### Step 1: Identify input
+
+Receive one of the following from the user:
+- Figma URL frame: `https://www.figma.com/design/<fileKey>/...?node-id=<nodeId>`
+- Figma URL file: `https://www.figma.com/design/<fileKey>/...`
+- Node description: "UserCard component in file ABC"
+
+Extract `fileKey` and `nodeId` from the URL.
+
+### Step 2: Read design via Figma MCP
+
+Use Figma MCP tools to fetch design information:
+
+```
+1. Get node info: figma_get_file_nodes(fileKey, nodeIds=[nodeId])
+2. Get styles: figma_get_file_styles(fileKey)
+3. Get components: figma_get_file_components(fileKey) if needed
+4. Export image if visual reference needed: figma_get_image(fileKey, nodeId)
+```
+
+Analyze the output to extract:
+- **Layout**: flexbox direction, gap, padding, alignment
+- **Sizing**: width/height (fixed vs fill vs hug)
+- **Colors**: fills, strokes → map to Tailwind colors if available
+- **Typography**: font-size, font-weight, line-height, letter-spacing → map to Tailwind text classes
+- **Spacing**: padding, margin, gap → map to Tailwind spacing scale
+- **Border**: radius, width, color → map to Tailwind border classes
+- **Shadow**: box-shadow → map to Tailwind shadow classes
+- **States**: hover, focus, disabled, active (if variants present)
+- **Responsive**: breakpoints if multiple frames present
+
+### Step 3: Map Figma tokens → Tailwind / CSS
+
+**Color mapping:**
+```
+Figma hex #3B82F6 → Tailwind blue-500
+Figma hex #EF4444 → Tailwind red-500
+Figma rgba(0,0,0,0.5) → Tailwind black/50
+No Tailwind match → use arbitrary value [#hexcode]
+```
+
+**Spacing mapping (8px grid):**
+```
+4px  → p-1 / gap-1
+8px  → p-2 / gap-2
+12px → p-3 / gap-3
+16px → p-4 / gap-4
+24px → p-6 / gap-6
+32px → p-8 / gap-8
+No match → arbitrary value [20px]
+```
+
+**Typography mapping:**
+```
+text-xs: 12px
+text-sm: 14px
+text-base: 16px
+text-lg: 18px
+text-xl: 20px
+text-2xl: 24px
+text-3xl: 30px
+font-normal: 400
+font-medium: 500
+font-semibold: 600
+font-bold: 700
+```
+
+### Step 4: Generate component
+
+**Framework detection** — check the project's CLAUDE.md to determine the framework:
+- `reactjs` / `nextjs` → generate `.tsx` with React conventions
+- `vue-nuxt` → generate `.vue` with Vue 3 Composition API
+
+#### React/Next.js component template:
+
+```tsx
+interface [ComponentName]Props {
+  // Props extracted from Figma variants or dynamic content slots
+  className?: string;
+}
+
+export const [ComponentName] = ({ className }: [ComponentName]Props) => {
+  return (
+    <div className={cn(
+      // Layout classes
+      // Sizing classes
+      // Color classes
+      // Typography classes (if text node)
+      className
+    )}>
+      {/* Child nodes rendered recursively */}
+    </div>
+  );
+};
+```
+
+#### Vue 3 component template:
+
+```vue
+<script setup lang="ts">
+interface Props {
+  // Props extracted from Figma variants
+  class?: string;
+}
+
+const props = withDefaults(defineProps<Props>(), {});
+</script>
+
+<template>
+  <div :class="cn(
+    // Layout classes
+    // Sizing classes
+    // Color classes
+    props.class
+  )">
+    <!-- Child nodes -->
+  </div>
+</template>
+```
+
+### Step 5: Handle interactive states
+
+If Figma has variants (Default, Hover, Disabled, Active):
+
+```tsx
+// Map variants into props + conditional classes
+interface ButtonProps {
+  variant?: 'primary' | 'secondary' | 'outline';
+  size?: 'sm' | 'md' | 'lg';
+  disabled?: boolean;
+}
+
+const variantClasses = {
+  primary: 'bg-blue-600 text-white hover:bg-blue-700',
+  secondary: 'bg-gray-100 text-gray-900 hover:bg-gray-200',
+  outline: 'border border-gray-300 hover:bg-gray-50',
+};
+```
+
+### Step 6: Verify and output
+
+After generation, verify:
+
+- [ ] Layout matches Figma (flex direction, alignment, gap)
+- [ ] Colors mapping correct (or use arbitrary values if no Tailwind match)
+- [ ] Typography correct (size, weight, line-height)
+- [ ] Spacing correct (padding, margin, gap)
+- [ ] Component has `className` prop for external overrides
+- [ ] Use `cn()` helper for conditional/mergeable classes
+- [ ] Responsive if Figma has mobile frames
+- [ ] Props typed with TypeScript interface
+
+---
+
+## Output format
+
+Always output in order:
+
+1. **Design Summary** (brief): layout structure, color palette, typography scale
+2. **Component file** with full code
+3. **Usage example**:
+   ```tsx
+   <ComponentName variant="primary" className="mt-4" />
+   ```
+4. **Notes** if anything cannot be mapped 100% accurately from Figma
+
+---
+
+## Rules
+
+- **Do not hardcode** hex colors directly into className if a Tailwind equivalent exists
+- **Always use** `cn()` (clsx + twMerge) to merge classes
+- **No new CSS imports** — use Tailwind utilities only
+- **Responsive** — if Figma only has 1 breakpoint, default to mobile-first design
+- **Accessibility** — add `aria-label`, `role`, `alt` for interactive and image elements
+- **Image** — use `next/image` for Next.js, `<img>` for React, add `alt` from Figma layer name
+- **Icon** — if Figma uses SVG icons, extract SVG or map to lucide-react / heroicons
+
+---
+
+## Trigger Example Commands
+
+```
+Read Figma and generate component: https://www.figma.com/design/xxxxx/App?node-id=123-456
+
+Generate UserCard component from Figma frame node-id=123-456
+
+Implement UI from this Figma link following my project: [URL]
+```

package/custom/skills/generate-spec/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: generate-spec
+description: Gate 2 — After DEV approves the requirement document (Gate 1), AI creates a detailed implementation plan using TDD approach. This is the bridge between requirement and code.
+keywords: spec, plan, implementation, tdd, coding plan
+---
+
+# Implementation Plan — Gate 2
+
+> **GATE 2: Runs after Gate 1 (requirement document) has been APPROVED by DEV.**
+>
+> Principle: AI uses the approved requirement document to create a detailed implementation plan with TDD steps. DEV confirms the plan before coding begins.
+
+---
+
+## Conditions to Enter Gate 2
+
+- ✅ Gate 1 APPROVED — `plan/[ticket-id]/requirement.md` reviewed and approved by DEV
+- ✅ Requirement document includes: requirements, solution, impact analysis, estimate
+
+---
+
+## Process
+
+### Step 1: Read Approved Requirement
+
+Read `plan/[ticket-id]/requirement.md` — use the chosen approach, file list, and testing plan as input.
+
+### Step 2: Create Implementation Plan
+
+**INVOKE:** `superpowers:writing-plans`
+
+Create a detailed step-by-step plan based on the requirement document:
+
+```markdown
+## Implementation Plan
+
+### Task Breakdown (TDD Order)
+
+| # | Task | File | Test First? | Dependencies |
+|---|------|------|-------------|--------------|
+| 1 | Write test for [scenario] | [test file] | ✅ | None |
+| 2 | Implement [component] | [source file] | — | Task 1 |
+| 3 | Write test for [scenario] | [test file] | ✅ | Task 2 |
+| ... | ... | ... | ... | ... |
+
+### Commit Strategy
+- Commit after each test+implementation pair
+- Keep commits small and focused
+
+### Test Commands
+```bash
+[specific test commands for this project]
+```
+```
+
+### Step 3: GATE 2 — Present Plan & Start Coding
+
+```markdown
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⏸️  GATE 2: IMPLEMENTATION PLAN READY
+
+Based on the approved requirement document, here is the coding plan:
+
+[Show task breakdown summary]
+
+**Total tasks:** [N]
+**Estimated commits:** [N]
+**Test-first tasks:** [N]
+
+Ready to start coding?
+Type **"APPROVED"** to begin implementation.
+Type feedback to adjust the plan.
+
+⚠️  I will NOT write code until I receive "APPROVED".
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Step 4: Handle Feedback
+
+**If DEV provides feedback:**
+→ Update the implementation plan
+→ Re-display GATE 2 prompt
+
+**If DEV types "APPROVED":**
+→ Proceed to Gate 3 (Code Generation with TDD)
+→ Follow the task breakdown order exactly
+
+---
+
+## Mandatory Rules
+
+- ❌ **DO NOT** start coding until "APPROVED" is received for the plan
+- ❌ **DO NOT** deviate from the approved requirement document
+- ✅ **MUST** use TDD order: test first, then implementation
+- ✅ **MUST** invoke `superpowers:writing-plans` for plan creation
+- ✅ **MUST** show clear task breakdown before getting approval
+- ✅ **MUST** plan small, focused commits

package/custom/skills/impact-analysis/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: impact-analysis
+description: Analyze the impact scope when modifying logic or the database to ensure system-wide safety.
+keywords: impact, refactor, breaking change, scope
+---
+
+# Impact Analysis
+
+## When mandatory to run
+
+- Modifying **Core Services / shared utilities** used in many places
+- Changing **database schema** (add/rename/drop column, table)
+- Changing **API response structure** (rename field, remove field)
+- Changing **interfaces / contracts** between modules
+- After fixing a bug — to ensure the fix doesn't break other parts
+
+---
+
+## Analysis Process
+
+### Step 1: Find all usage (Dependency Map)
+
+```bash
+# Find all files importing/calling the class/function being modified
+grep -r "ClassName\|functionName\|methodName" --include="*.php" .
+grep -r "ClassName\|functionName\|methodName" --include="*.java" .
+grep -r "ClassName\|functionName\|methodName" --include="*.ts" .
+
+# Check which routes/controllers trigger this service
+grep -r "ServiceName" app/Http/Controllers/
+```
+
+List all:
+- Controllers / Routes calling it directly
+- Jobs / Commands / Events calling it indirectly
+- Tests mocking/stubbing this class
+- Frontend components calling related APIs
+
+### Step 2: Evaluate each aspect
+
+| Aspect | Checkpoint questions |
+|-----------|---------------------|
+| **Database / Cache** | Which queries are affected by schema changes? Which cache keys need flushing? |
+| **Background Jobs** | Which Crons / Queues call this logic? Will they break? |
+| **Import / Export** | Do bulk data flows use this field/logic? |
+| **Permissions** | Are API / UI permission checks sufficient after the change? |
+| **API / Mobile** | Will JSON responses lose fields? Do mobile clients need updates? |
+| **Tests** | Which tests will fail? Which mocks/stubs need updating? |
+
+### Step 3: Classify impact level
+
+| Level | Definition | Action |
+|-----|-----------|-----------|
+| 🟢 Low | Only 1 file, no dependencies | Proceed |
+| 🟡 Medium | 2–5 files, tests need updates | Review carefully before merging |
+| 🔴 High | 6+ files, API breaking change, DB migration | Discuss with the team first |
+| ⛔ Critical | Affects payment, auth, data integrity | Tech Lead review mandatory |
+
+### Step 4: Export report
+
+**Report structure:**
+
+```
+## Impact Analysis: [Change Name]
+
+**Level:** 🟡 Medium
+
+### Impact Scope
+- [File/Class A] — [reason for impact]
+- [File/Class B] — [reason for impact]
+
+### Breaking changes
+- [Describe breaking change if any]
+
+### Tests to check after merge
+- [ ] [Test case / screen 1]
+- [ ] [Test case / screen 2]
+- [ ] [Job/Command to test run]
+
+### Notes for QA
+[Specific points QA should pay attention to]
+```
+
+---
+
+## Completion Checklist
+
+- [ ] Found all dependencies using grep/IDE search
+- [ ] Checked Jobs, Events, and Crons
+- [ ] Checked API response structure
+- [ ] Checked tests
+- [ ] Determined impact level (Low/Medium/High/Critical)
+- [ ] Wrote impact report
+- [ ] Notified the team if High/Critical

package/custom/skills/investigate-bug/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: investigate-bug
+description: Investigate and fix bugs based on the project's data flow, inheriting from superpowers' systematic-debugging.
+keywords: bug, fix, error, crash, broken
+---
+
+# Investigate Bug
+
+> This skill **inherits and extends** `superpowers:systematic-debugging`.
+> First, invoke `superpowers:systematic-debugging` to understand the core process,
+> then apply these project-specific steps.
+
+---
+
+## When to use this skill
+
+- Developer requests finding / fixing a bug
+- A backlog/jira ticket describes an error
+- Logs, stack traces, or descriptions of incorrect behavior are provided
+
+---
+
+## Additional Steps after Phase 1 of systematic-debugging
+
+### 1. Read context from ticket (if available)
+
+Check `.claude/context/current.json`:
+- `description` — bug description from the ticket
+- `comments` — discussions, additional info
+- `context.files` — related files mentioned
+
+### 2. Trace data flow according to project architecture
+
+Depending on the framework, trace the corresponding flow:
+
+**Spring Boot (Java)**
+```
+Controller (@RestController)
+  → Service (@Service / ServiceImpl)
+    → Repository (JpaRepository)
+      → Database
+```
+
+**Laravel (PHP)**
+```
+Route / Controller
+  → FormRequest (validation)
+    → Service / Action
+      → Model / Repository
+        → Database
+```
+
+**React / Next.js**
+```
+Page / Route component
+  → Custom Hook (useXxx)
+    → API call (axios / fetch)
+      → Backend endpoint
+```
+
+At each layer: log input/output to pinpoint exactly **which layer** generates the incorrect value.
+
+### 3. Check Git history
+
+```bash
+# Who changed this file last, and why
+git blame <file>
+
+# See detailed changes over time
+git log -p <file>
+
+# Find which commit introduced the bug (if the timing is known)
+git bisect start
+```
+
+Purpose: **to avoid accidentally breaking other business logic** when fixing.
+
+### 4. After fixing — run Impact Analysis
+
+Invoke the `impact-analysis` skill to ensure the fix doesn't affect other parts.
+
+---
+
+## Completion Checklist
+
+- [ ] Read all ticket content + comments
+- [ ] Reproduced the error before fixing
+- [ ] Traced the exact layer causing the error
+- [ ] Checked git blame to understand context
+- [ ] Root cause identified clearly
+- [ ] Fix is minimal — only modified necessary parts
+- [ ] Tests passed (unit + integration)
+- [ ] Impact analysis has been run

package/custom/skills/report-customer/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: report-customer
+description: Write an incident report for customers or customer service after a production bug fix. Non-technical, easy-to-understand language.
+keywords: report, incident, customer, customer service, CS
+---
+
+# Report Customer (Incident Report)
+
+## When to use
+
+- After fixing a bug that affects users/customers
+- Customer Service needs a report explaining the cause to customers
+- Need to document the incident for future reference
+
+---
+
+## Process
+
+### Step 1: Gather information
+
+Collect from `investigate-bug` results or developer descriptions:
+- Ticket ID and title
+- Discovery time / impact duration
+- Number of affected users / orders
+- Identified root cause
+- Deployment status
+
+### Step 2: Write the report
+
+Fill in the structure below. **Use simple language, avoiding technical jargon.**
+
+---
+
+## Standard Structure (English)
+
+```markdown
+## 📋 Incident Verification Report
+
+**Ticket ID:** [ID]
+**Assigned to:** [Dev Name]
+**Resolution Date:** [YYYY-MM-DD]
+**Status:** ✅ Resolved / 🔄 In Progress
+
+---
+
+### 1. Summary
+
+[1–2 sentences describing the issue in non-technical language.
+Example: "Between 14:00–15:30 on [Date], some 
+users were unable to complete order payments."]
+
+---
+
+### 2. Root Cause
+
+[Simple explanation, no code references.
+Example: "Due to a system update failing to correctly handle 
+slow connections with the payment gateway."]
+
+---
+
+### 3. Resolution
+
+[Steps taken by the technical team.
+Example: "Updated the timeout handling mechanism and deployed 
+the fix at 16:00 on [Date]."]
+
+---
+
+### 4. Data Impact
+
+- Was existing data affected? [Yes / No]
+- Data recovery status: [Update script run / Not necessary]
+
+---
+
+### 5. Expected Behavior
+
+[Actions the customer should take to verify normal operation.
+Example: "Customers can now attempt payment normally.
+If problems persist, please contact our support hotline..."]
+```
+
+---
+
+## Writing Rules
+
+- ✅ Simple language, avoid technical jargon
+- ✅ Honest about scope and duration of impact
+- ✅ Focus on **user impact**, not code details
+- ✅ Always include instructions for the customer to verify the fix
+- ❌ Do not blame third parties unless certain
+- ❌ Do not commit to specific deadlines unless certain
+
+Present clearly and professionally. Default is English unless otherwise requested.