rex-claude 2.2.0 → 3.0.1

package/dist/skills/context-loader/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: context-loader
+description: Load relevant documentation and project context before starting work. Reads local docs cache, project CLAUDE.md, and REX memory. Use at session start or project switch.
+---
+
+# Context Loader
+
+Load context for: $ARGUMENTS (project path or framework name)
+
+## If project path given:
+1. Read project's `CLAUDE.md` if exists
+2. Read `package.json` / `composer.json` / `pubspec.yaml` to detect stack
+3. Call `rex_context(project_path)` for past session insights
+4. For each framework detected, read `~/.claude/docs/{framework}.md` if exists
+5. Report: stack detected, relevant docs loaded, past context found
+
+## If framework name given:
+1. Check `~/.claude/docs/{framework}.md` — if exists, read it
+2. If not exists, fetch via Context7 and save key patterns to `~/.claude/docs/{framework}.md`
+3. Report: doc loaded/created, key patterns summarized
+
+## Rules
+- NEVER load docs that aren't relevant to the current task
+- Always check local cache before fetching from network
+- Keep doc files under 100 lines — patterns and gotchas only, not full API reference

package/dist/skills/debug-assist/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: debug-assist
+description: Systematic debugging. Reads error, searches REX memory for past solutions, checks docs, identifies root cause. Use when stuck on an error.
+---
+
+# Debug Assist
+
+Debug: $ARGUMENTS (paste the error message or describe the issue)
+
+## Process
+1. **Parse the error**: extract file, line, error type, stack trace
+2. **Check REX memory**: `rex_search("error message keywords")` for past solutions
+3. **Check local docs**: read `~/.claude/docs/{framework}.md` for known gotchas
+4. **Search codebase**: find the failing code, read surrounding context
+5. **Identify root cause**: not the symptom — what ACTUALLY caused it
+6. **Propose fix**: with code snippet and explanation
+
+## Anti-patterns (NEVER do these)
+- Never suppress the error without understanding it
+- Never delete a test to make it pass
+- Never add `@ts-ignore` or `eslint-disable` as a fix
+- Never retry the same approach more than twice — try a different angle
+
+## After fixing
+- Save the pattern to REX: `rex_learn("Error X was caused by Y, fix is Z", "debug")`
+- Update `~/.claude/docs/{framework}.md` if it's a framework gotcha

package/dist/skills/deploy-checklist/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: deploy-checklist
+description: Pre-deployment checklist. Use when user says "deploy", "push to prod", "push to beta", "ship it", or before any deployment. Runs verification steps before allowing deploy.
+disable-model-invocation: true
+---
+
+# Deploy Checklist
+
+Run this checklist BEFORE any deployment. $ARGUMENTS can specify the target (beta/prod).
+
+## Pre-Deploy Verification
+
+1. **Check git status**:
+   - All changes committed? No uncommitted work?
+   - On the correct branch?
+   - Branch is up to date with remote?
+
+2. **Run tests** (if test suite exists):
+   ```bash
+   # Detect and run project tests
+   # PHP: composer test or vendor/bin/phpunit
+   # Node/Angular: npm test
+   # Flutter: flutter test
+   # Python: pytest
+   ```
+
+3. **Run linter/formatter** (if configured):
+   ```bash
+   # Detect and run linter
+   # PHP: composer lint or vendor/bin/phpcs
+   # Node: npm run lint
+   # Flutter: flutter analyze
+   ```
+
+4. **Build check**:
+   - Run production build to catch compile errors
+   - Verify build output exists and looks correct
+
+5. **Environment check**:
+   - Verify environment config points to the correct target (beta vs prod)
+   - NEVER deploy with local/dev config pointing to wrong DB or API
+   - Check for hardcoded localhost URLs
+
+6. **PR status** (if deploying from a PR):
+   - All CI checks passing?
+   - Gemini Code Assist review: any critical issues?
+   - GitHub Copilot review: any critical issues?
+
+## Deploy Decision
+
+- If ANY check fails: STOP and report to user
+- If all checks pass: proceed with deploy and confirm target with user
+
+IMPORTANT: Always ask "beta or prod?" if not specified. Never assume prod.
+
+## Auto-Learn
+
+If any deploy issue is found, call `rex_learn` MCP tool:
+- category: `"lesson"`
+- fact: the deploy issue + environment + fix (e.g. "Cloudflare deploy failed: missing wrangler.toml env binding for PROD")
+- Helps prevent repeating the same deploy mistakes

package/dist/skills/dstudio-design-system/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: dstudio-design-system
+description: Load the dstudio-ui design system context — tokens, components, patterns, and import guide. Use when building UI with @dstudio/ui components or design tokens.
+user-invocable: true
+---
+
+# dstudio-ui Design System
+
+You are working with the **@dstudio/ui** design system. Use this reference for all UI implementation.
+
+## Architecture
+
+- **Repo**: `/Users/keiy/Documents/Developer/dstudio-ui`
+- **Package**: `@dstudio/ui` — exported from `src/index.ts`
+- **Stack**: Next.js 16, Tailwind v4, Framer Motion (`motion/react`), Storybook v8, pnpm
+- **`@` alias** maps to `src/` (NOT project root)
+
+## Using in Another Project
+
+```json
+// package.json
+"@dstudio/ui": "file:../dstudio-ui"
+```
+
+Then `pnpm install` and import:
+
+```tsx
+import { DSButton, MagicCard, KanbanBoard } from "@dstudio/ui"
+```
+
+The consumer project **must** share the same Tailwind v4 setup with CSS vars from `globals.css`. Tokens are CSS variables, not bundled.
+
+## Design Tokens (Style Dictionary v4)
+
+- **Format**: W3C DTCG `{ "$value": "...", "$type": "color" }`
+- **Token files**: `tokens/core/*.json` + `tokens/semantic/colors.json`
+- **Build**: `pnpm build:tokens` → `build/css/`, `build/tailwind/`, `build/figma/`, `build/js/`
+- **Config**: `sd.config.ts` at repo root
+
+### Key Semantic Colors
+
+| Token | Value | CSS var |
+|-------|-------|---------|
+| background | #000000 | `--color-background` |
+| foreground | #ffffff | `--color-foreground` |
+| card | #080808 | `--color-card` |
+| primary | #18181b | `--color-primary` |
+| secondary | #f4f4f5 | `--color-secondary` |
+| muted | #1a1a1a | `--color-muted` |
+| border | #e4e4e7 | `--color-border` |
+| destructive | #ef4444 | `--color-destructive` |
+
+### Using tokens in Tailwind
+
+```tsx
+// Tokens live in @theme {} block → Tailwind v4 auto-generates utilities
+className="bg-background text-foreground border-border"
+className="text-gray-400 bg-dark-100"
+```
+
+### Adding a new token
+
+1. Add to `tokens/core/*.json` or `tokens/semantic/colors.json`
+2. `pnpm build:tokens`
+3. Copy new var into `src/styles/globals.css` inside `@theme {}` block
+4. Commit `build/` directory + `globals.css`
+
+## Available Components
+
+### D-Studio branded
+GradientButton, GlassBadge, SmallButton, MultiLayerCard, SlightSeparator, DSButton, SquaredBadge
+
+### Base UI (shadcn-style)
+Badge, Button, Card, Input, Accordion, Dialog, Tabs, OrbitingCircles, Skeleton, Textarea, DropdownMenu
+
+### Motion
+BlurFade, InfiniteSlider, TextEffect, Tilt, GlowEffect, Magnetic, MagicCard, BorderTrail, TextScramble, SpinningText, TextReveal, Cursor
+
+### Bits
+StarBorder, GradualBlur, StackingCards
+
+### PM (Project Management)
+StatusBadge, AvatarStack, BoardTable, KanbanBoard, GanttChart, TimelineCalendar, DatePicker, StatusSelector, Notepad, NeonGlow, AnimatedBlob, PrioritySlider
+
+### AI
+AskAiButton, SuggestionChips
+
+### Contact
+ContactForm, MultiStateButton
+
+### Shared
+ScrambleRevealText, ProgressiveScrambleText, AnimatedSection
+
+## Key Files
+
+| File | Purpose |
+|------|---------|
+| `src/index.ts` | Main package export |
+| `sd.config.ts` | Style Dictionary config |
+| `tokens/core/colors.json` | Primitive color palette |
+| `tokens/semantic/colors.json` | Semantic color aliases |
+| `src/styles/globals.css` | `@theme` block (must be inline) |
+| `src/app/components/page.tsx` | Components showcase page |
+| `src/app/docs/components/component-data.ts` | Docs prop tables |
+
+## Gotchas
+
+- **`@theme {}` must be inline** in `globals.css` — `@import` of a file containing `@theme` breaks Vite/Storybook
+- **`build/` directory is committed** (generated token outputs)
+- **`Transition` type** import must come from `motion/react`
+- **Framer Motion** — use `motion/react` not `framer-motion` for imports
+- Nav variants: `floating-nav-landing.tsx` (next-intl), `floating-nav.tsx` (no i18n)
+
+## When building UI with this system
+
+1. Read the relevant component source in `dstudio-ui/src/` before using it
+2. Follow existing Tailwind v4 patterns (CSS vars, not hardcoded colors)
+3. Use `motion/react` for all animations
+4. Check `src/index.ts` to see what's exported before importing
+5. Run `pnpm build` in the consumer project to verify

package/dist/skills/figma-workflow/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: figma-workflow
+description: Implement UI from Figma designs using get_design_context, mapping to dstudio-ui components and project design tokens. Use when given a Figma URL or node ID.
+---
+
+# Figma to Code Workflow
+
+Use this skill when implementing UI from Figma designs.
+
+## Process
+1. Call `get_design_context` with the Figma node ID and file key
+2. Review the returned code, screenshot, and metadata
+3. Map to existing dstudio-ui components — NEVER recreate what already exists
+4. Extract design tokens (colors, spacing, typography) and map to project tokens
+5. Adapt the reference code to the project's stack and conventions
+6. Use Code Connect to link Figma components ↔ codebase components
+
+## Rules
+- Always check dstudio-ui for existing components first
+- Use project's design tokens, not raw hex values
+- Responsive: mobile-first approach
+- Accessibility: proper ARIA labels, semantic HTML
+- Loading/empty/error states for dynamic content

package/dist/skills/fix-issue/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: fix-issue
+description: Fix a GitHub issue end-to-end. Use when user says "/fix-issue 123" or "fix issue #123".
+disable-model-invocation: true
+---
+
+# Fix GitHub Issue
+
+Analyze and fix the GitHub issue: $ARGUMENTS
+
+1. **Get issue details**:
+   ```bash
+   gh issue view $ARGUMENTS
+   ```
+
+2. **Understand the problem**:
+   - Read the issue description, labels, and comments
+   - Identify the affected area of the codebase
+   - Search for relevant files using Grep/Glob
+
+3. **Create a feature branch**:
+   ```bash
+   gh issue view $ARGUMENTS --json title -q .title
+   # Branch name: fix/issue-NUMBER-short-description
+   git checkout -b fix/issue-$ARGUMENTS-<short-description>
+   ```
+
+4. **Implement the fix**:
+   - Read relevant code before modifying
+   - Follow existing patterns in the codebase
+   - Make minimal, focused changes
+
+5. **Verify the fix**:
+   - Run tests if they exist
+   - Run linter if configured
+   - Build the project to check for errors
+
+6. **Commit and create PR**:
+   - Commit with message referencing the issue: `fix: <description> (closes #$ARGUMENTS)`
+   - Push branch and create PR linking to the issue
+   - Wait for Gemini/Copilot reviews
+
+7. **Report to user**: show what was changed and ask for review

package/dist/skills/new-rule/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: new-rule
+description: Create a new rule in ~/.claude/rules/ when a recurring error or anti-pattern is identified. Implements "Mistakes become rules" automatically.
+---
+
+# New Rule
+
+When an error or anti-pattern has been encountered multiple times (3+), create a permanent rule.
+
+1. **Identify the pattern**: What went wrong? What's the root cause?
+2. **Check existing rules**: Read `~/.claude/rules/` — does a similar rule already exist?
+3. **Write the rule**:
+   - File: `~/.claude/rules/{topic}.md` (new or append to existing)
+   - Format: `JAMAIS X → TOUJOURS Y à la place` (every prohibition MUST have an alternative)
+   - Include a concrete code example (good vs bad)
+4. **Memorize**: Call `rex_learn` with category `"lesson"` and the rule summary
+5. **Report**: Tell the user what rule was created and why
+
+Rules must be actionable, not vague. "Don't do X" is insufficient — always specify what to do instead.

package/dist/skills/notify/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: notify
+description: Send a Telegram notification to Kevin. Use when user says "/notify", "notify me", "send telegram", or at end of important tasks. Arguments become the message body.
+user_invocable: true
+---
+
+# Notify via Telegram
+
+Send a notification to Kevin's Telegram using the notify script. Zero tokens — pure shell.
+
+## Usage
+
+```bash
+bash ~/notify-telegram.sh "$ARGUMENTS"
+```
+
+If `$ARGUMENTS` is empty, auto-generate a one-line summary of what was just accomplished:
+- Project name + branch
+- What changed (brief)
+
+Example:
+```bash
+bash ~/notify-telegram.sh "PR #42 created on rex" "feat/v3 — 33 files, 1800+ lines"
+```
+
+IMPORTANT: This is a shell script call, NOT an LLM task. Do not elaborate. Just call the script.

package/dist/skills/one-shot/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: one-shot
+description: Generate a complete production-ready project in one shot. Next.js + Shadcn UI + dstudio-ui. Use for rapid prototyping and SAAS scaffolding.
+---
+
+# One-Shot Project Generator
+
+Create a complete project: $ARGUMENTS
+
+1. Read `~/.claude/docs/nextjs.md` and `~/.claude/docs/react.md` for current patterns
+2. Load dstudio-ui design system context: `/dstudio-design-system`
+3. Scaffold with: Next.js App Router, TypeScript, Tailwind v4, dstudio-ui components
+4. Include: auth scaffold, API routes with validation, DB schema, loading/empty/error states
+5. Apply all defensive engineering rules (pagination, error handling, rate limits)
+6. Setup: `package.json`, `tsconfig.json`, `.env.example`, `README.md`
+7. Run `npm install && npm run build` to verify
+
+Output a working project, not a template.

package/dist/skills/pr-review-loop/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: pr-review-loop
+description: Automated PR review loop. Use when user says "review loop", "check PR comments", "fix PR feedback", or after creating a PR. Pulls comments from Gemini Code Assist and GitHub Copilot, fixes valid issues, and pushes updates.
+---
+
+# PR Review Loop
+
+After a PR is created or when asked to check PR feedback:
+
+1. **Pull review comments** from the PR:
+   ```bash
+   # Get PR number from current branch
+   PR_NUMBER=$(gh pr view --json number -q .number 2>/dev/null)
+
+   # Get all review comments (inline code comments)
+   gh api repos/{owner}/{repo}/pulls/$PR_NUMBER/comments --jq '.[] | "[\(.user.login)] \(.path):\(.line // .original_line) - \(.body)"'
+
+   # Get PR review summaries
+   gh pr view $PR_NUMBER --comments
+   ```
+
+2. **Categorize each comment**:
+   - **Valid fix needed**: bug, security issue, logic error, missing edge case
+   - **Good suggestion**: improvement worth making (cleaner code, better naming)
+   - **Dismiss**: style preference, false positive, or not applicable
+
+3. **Fix valid issues**:
+   - Address each valid comment with a targeted fix
+   - Run tests/lint after each fix to ensure no regressions
+   - Do NOT introduce unrelated changes
+
+4. **Commit and push fixes**:
+   - One commit for all review fixes: `fix: address PR review feedback`
+   - Push to the same branch (the PR updates automatically)
+
+5. **Report to user**:
+   - List what was fixed and why
+   - List what was dismissed and why
+   - Ask user to review the diff between v1 and v2
+
+IMPORTANT: Never force-push. Always regular push. The user reviews the incremental diff.
+
+## Auto-Learn
+
+After processing all comments, call `rex_learn` MCP tool for each valid fix:
+- category: `"lesson"`
+- fact: the reviewer feedback pattern + fix (e.g. "Copilot flagged missing null check on X — added guard clause")
+- Skip dismissed comments — only learn from actionable feedback

package/dist/skills/project-init/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: project-init
+description: Initialize a new project with CLAUDE.md, proper git setup, and documentation cache. Use when starting a new project or onboarding an existing one.
+---
+
+# Project Init
+
+Initialize project: $ARGUMENTS (path or name)
+
+## For new projects
+1. Create project directory structure
+2. Generate `CLAUDE.md` with project-specific instructions
+3. Detect stack from user input, create appropriate config files
+4. Load relevant docs from `~/.claude/docs/` or fetch via Context7
+5. Git init, create `.gitignore`, initial commit
+6. Save project context: `rex_learn("Project X uses stack Y, structure Z", "architecture")`
+
+## For existing projects (onboarding)
+1. Read existing `package.json` / `composer.json` / config files to detect stack
+2. Read existing `CLAUDE.md` if present, or create one
+3. Scan project structure: key directories, entry points, routing
+4. Load relevant framework docs from `~/.claude/docs/`
+5. Call `rex_context(project_path)` for any past work history
+6. Report: stack, structure, key files, any issues noticed
+
+## CLAUDE.md template
+```markdown
+# Project Name
+
+## Stack
+- Framework: ...
+- Language: ...
+- Database: ...
+
+## Commands
+- Dev: `npm run dev`
+- Build: `npm run build`
+- Test: `npm test`
+- Lint: `npm run lint`
+
+## Key Files
+- Entry: ...
+- Config: ...
+- Routes: ...
+```

package/dist/skills/research/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: research
+description: Deep research on a topic using web, docs, codebase. Returns concise actionable summary with sources. Use for architecture decisions, library comparisons, debugging.
+---
+
+# Research
+
+Research: $ARGUMENTS
+
+1. Check `~/.claude/docs/` for local cached documentation first
+2. Search web for documentation, best practices, recent changes
+3. Query Context7 for versioned library docs if relevant
+4. Search codebase for existing patterns and usage
+5. Synthesize into concise summary with recommendations
+
+Return: key findings, recommended approach, code references, links.
+Keep it actionable — the goal is to inform a decision, not write an essay.

package/dist/skills/rex-boot/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: rex-boot
+description: Session startup companion. Auto-detects project, loads context, checks environment, asks what to work on. Runs automatically at every session start.
+---
+
+# REX Boot — Session Companion
+
+Tu es REX, senior dev companion de Kevin. A chaque début de session, tu fais ce briefing.
+
+## 1. Detect project context
+
+```bash
+# Where are we?
+pwd
+# Git state
+git branch --show-current 2>/dev/null
+git status --short 2>/dev/null | head -20
+# What project is this?
+cat package.json 2>/dev/null | jq '{name, scripts: .scripts | keys}' 2>/dev/null || cat composer.json 2>/dev/null | jq '.name' 2>/dev/null || echo "No project detected"
+```
+
+## 2. Check for in-progress work
+
+- Open branches with uncommitted changes?
+- Stashed work? (`git stash list`)
+- Open PRs on this repo? (`gh pr list --state open --limit 5`)
+- Failing CI on current branch?
+
+## 3. Load relevant context (ON-DEMAND only)
+
+- If a project is detected: call `rex_context(project_path)` for past session memory
+- If CLAUDE.md exists in project: mention its key points
+- Do NOT load `~/.claude/docs/` yet — wait until the task is clear
+
+## 4. Briefing to Kevin
+
+Format the output as a short briefing:
+
+```
+REX Boot
+---
+Projet: {name} ({path})
+Branche: {branch} | {clean/dirty}
+Stack: {detected stack}
+PR ouvertes: {count}
+Travail en cours: {stash/uncommitted summary}
+Mémoire REX: {brief context if found}
+---
+```
+
+## 5. Ask what to work on
+
+Use AskUserQuestion with smart options based on context:
+- If dirty git state → "Continuer le travail en cours?"
+- If open PRs → "Review la PR #{number}?"
+- If nothing → "Quel est l'objectif aujourd'hui?"
+
+Always offer these options contextually, not a generic menu.
+
+## Rules
+- Keep the boot FAST — no heavy operations, no doc loading
+- Max 3 bash commands total
+- If no project detected (home dir), just ask what Kevin veut faire
+- NEVER read doc files at boot — they load when the task is clear

package/dist/skills/spec-interview/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: spec-interview
+description: Interview the user to write a complete feature spec before coding. Use when user says "/spec-interview" or "interview me about" a feature.
+disable-model-invocation: true
+---
+
+# Feature Spec Interview
+
+I want to build: $ARGUMENTS
+
+Interview me in depth using the AskUserQuestion tool. Cover:
+- Technical implementation and architecture choices
+- UI/UX and user flows
+- Edge cases and failure modes
+- Security implications
+- Performance at scale (10x users/requests)
+- Tradeoffs and alternatives considered
+
+Don't ask obvious questions. Dig into the hard parts I haven't thought through.
+Keep interviewing until we've covered everything, then write a complete spec to `SPEC.md`.

package/dist/skills/token-guard/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: token-guard
+description: Optimize context usage. Audit what's loaded, suggest cleanup, compact if needed. Use when context feels bloated or before long sessions.
+---
+
+# Token Guard
+
+Audit and optimize the current context usage.
+
+## Checks
+1. **Files in context**: list all files that have been read this session
+2. **Redundant reads**: flag files read multiple times
+3. **Large outputs**: flag tool results > 200 lines that could have been scoped
+4. **Stale context**: flag information from early in session that's no longer relevant
+
+## Actions
+- Suggest `/compact` if context > 70%
+- Suggest `/clear` if switching to unrelated task
+- Identify docs/files that could be read on-demand instead of upfront
+- Flag any MCP server responses that returned excessive data
+
+## Reminders
+- Use subagents for heavy research (keeps main context clean)
+- Use `limit` and `offset` when reading large files
+- Use `head_limit` on Grep results
+- Prefer Glob/Grep over Agent for simple lookups

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rex-claude",
-  "version": "2.2.0",
+  "version": "3.0.1",
   "description": "Claude Code sous steroides — guards, health checks, memory RAG",
   "type": "module",
   "bin": {
@@ -36,8 +36,8 @@
   },
   "devDependencies": {
     "@rex/core": "workspace:*",
-    "tsup": "^8.0.0",
-    "typescript": "^5.7.0",
-    "@types/node": "^22.0.0"
+    "@types/node": "^25.3.3",
+    "tsup": "^8.5.1",
+    "typescript": "^5.9.3"
   }
 }