@riligar/agents-kit 1.14.0 → 1.15.0

package/.agent/{skills/riligar-dev-clean-code/SKILL.md → rules/clean-code.md}

@@ -1,25 +1,6 @@
----
-name: riligar-dev-clean-code
-description: Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments. CRITICAL skill that defines RiLiGar coding standards. Use when writing or reviewing any code.
----
+# Clean Code
 
-# Clean Code - RiLiGar Standards
-
-> **CRITICAL SKILL** - Be **concise, direct, and solution-focused**.
-
-## Rules Reference
-
-This skill builds on the foundational rules defined in `.agent/rules/`:
-
-| Rule File | Content |
-| --- | --- |
-| [code-style.md](../../rules/code-style.md) | Prettier formatting (4 spaces, no semi, single quotes) |
-| [javascript-only.md](../../rules/javascript-only.md) | ES6+ only, no TypeScript |
-| [naming-conventions.md](../../rules/naming-conventions.md) | PascalCase, camelCase, SCREAMING_SNAKE |
-| [conventional-commits.md](../../rules/conventional-commits.md) | Commit message format |
-| [pr-guidelines.md](../../rules/pr-guidelines.md) | Pull request standards |
-
----
+Pragmatic coding standards — concise, direct, no over-engineering.
 
 ## Core Principles
 
@@ -31,8 +12,6 @@ This skill builds on the foundational rules defined in `.agent/rules/`:
 | **YAGNI** | You Aren't Gonna Need It - don't build unused features |
 | **Boy Scout** | Leave code cleaner than you found it |
 
----
-
 ## Function Rules
 
 | Rule | Description |
@@ -44,8 +23,6 @@ This skill builds on the foundational rules defined in `.agent/rules/`:
 | **No Side Effects** | Don't mutate inputs unexpectedly |
 | **Async/Await** | Prefer `async/await` over `.then()` chains |
 
----
-
 ## Code Structure
 
 | Pattern | Apply |
@@ -55,8 +32,6 @@ This skill builds on the foundational rules defined in `.agent/rules/`:
 | **Composition** | Small functions composed together |
 | **Colocation** | Keep related code close |
 
----
-
 ## Component & Framework Rules (React/Elysia)
 
 | Situation | Action |
@@ -67,8 +42,6 @@ This skill builds on the foundational rules defined in `.agent/rules/`:
 | **API Endpoints** | Extract complex handler logic to `services/` |
 | **Early Returns** | Use Guard Clauses to avoid deep nesting |
 
----
-
 ## AI Coding Style
 
 | Situation | Action |
@@ -77,8 +50,6 @@ This skill builds on the foundational rules defined in `.agent/rules/`:
 | User reports bug | Fix it, don't explain |
 | No clear requirement | Ask, don't assume |
 
----
-
 ## Anti-Patterns (DON'T)
 
 | Pattern | Fix |
@@ -92,8 +63,6 @@ This skill builds on the foundational rules defined in `.agent/rules/`:
 | Magic numbers | Named constants |
 | God functions | Split by responsibility |
 
----
-
 ## Before Editing ANY File
 
 **Ask yourself:**
@@ -104,9 +73,7 @@ This skill builds on the foundational rules defined in `.agent/rules/`:
 | **What does this file import?** | Interface changes |
 | **Is this a shared component?** | Multiple places affected |
 
-> **Rule:** Edit the file + all dependent files in the SAME task.
-
----
+> Edit the file + all dependent files in the SAME task.
 
 ## Self-Check Before Completing (MANDATORY)
 
@@ -117,18 +84,3 @@ This skill builds on the foundational rules defined in `.agent/rules/`:
 | **Code works?** | Did I test/verify the change? |
 | **No TypeScript?** | Verified no `.ts` or type syntax? |
 | **Formatting?** | 4 spaces, no semi, single quotes? |
-
----
-
-## Summary
-
-| Do | Don't |
-| --- | --- |
-| Write code directly | Write tutorials |
-| Let code self-document | Add obvious comments |
-| Fix bugs immediately | Explain the fix first |
-| Inline small things | Create unnecessary files |
-| Name things clearly | Use abbreviations |
-| Keep functions small | Write 100+ line functions |
-
-> **Remember: The user wants working code, not a programming lesson.**

package/.agent/skills/riligar-dev-dashboard/SKILL.md

@@ -0,0 +1,252 @@
+---
+name: riligar-dev-dashboard
+description: Padrões React específicos do RiLiGar. Zustand, i18n, estrutura de arquivos, composição de componentes. Use quando construindo componentes, gerenciando estado ou implementando UI.
+---
+
+# Front-End — Padrões do RiLiGar
+
+> Regras concretas baseadas na arquitetura real dos projetos. Não são genéricas — são do código que existe.
+
+---
+
+## Referências obrigatórias
+
+> [!IMPORTANT]
+> Sempre respeite também:
+> - @[.agent/skills/riligar-design-system] — UI exclusivo via Mantine, zero CSS
+> - Rules em `.agent/rules/` — clean-code, naming-conventions, code-style, javascript-only
+
+---
+
+## 1. Estrutura de arquivos
+
+```
+src/
+├── components/          # Componentes reutilizáveis
+│   ├── Sidebar.jsx      # PascalCase (SEMPRE)
+│   ├── RichEditor.jsx
+│   └── MediaLibrary.jsx
+├── pages/               # Uma pasta por página/feature
+│   ├── home.jsx         # Arquivo raiz da página: kebab-case
+│   ├── editor/
+│   │   └── index.jsx
+│   └── feeds/
+│       ├── index.jsx
+│       └── FeedConfig.jsx   # Sub-componentes: PascalCase
+├── store/               # Zustand stores — um arquivo por domínio
+│   ├── auth-store.js
+│   ├── feed-store.js
+│   └── post-store.js
+├── services/            # Chamadas HTTP — um arquivo por domínio
+│   ├── api.js           # Instância base do cliente HTTP
+│   ├── feeds.js
+│   └── posts.js
+├── constants/           # Constantes estáticas do app
+├── i18n/                # Internacionalização
+│   ├── index.js
+│   └── locales/
+└── hooks/               # Custom hooks compartilhados
+```
+
+### Regras de naming de arquivos
+
+| Tipo | Convenção | Exemplo |
+|---|---|---|
+| Componentes (reutilizáveis) | PascalCase | `MediaLibrary.jsx` |
+| Página raiz | kebab-case | `home.jsx`, `index.jsx` |
+| Sub-componentes de página | PascalCase | `FeedConfig.jsx` |
+| Stores | kebab-case + sufixo `-store` | `feed-store.js` |
+| Services | kebab-case | `feeds.js` |
+| Hooks | camelCase com prefixo `use` | `useDebounce.js` |
+
+---
+
+## 2. Estado — Zustand (não é opcional)
+
+Estado global **sempre** Zustand. Sem Context para estado compartilhado. Sem Redux.
+
+### Padrão de store
+
+```javascript
+import { create } from 'zustand'
+import { feedsService } from '../services/feeds'
+
+const useFeedStore = create((set, get) => ({
+    feeds: [],
+    activeFeed: null,
+    isLoading: false,
+
+    fetchFeeds: async () => {
+        set({ isLoading: true })
+        const feeds = await feedsService.getAll()
+        set({ feeds, isLoading: false })
+    },
+
+    setActiveFeed: (feed) => set({ activeFeed: feed }),
+}))
+```
+
+### Regras
+
+- **Sem getters JavaScript** (`get isTrialing() {}`) — não são reativos no Zustand. Derive no componente ou use um selector.
+- **Persistência:** use `persist` middleware apenas quando necessário (ex: `activeFeed`).
+- **Sem lógica de UI** dentro do store. Stores são dados + chamadas de API.
+- **Selectors granulares:** `useStore((state) => state.feeds)` — não `useStore()` inteiro.
+
+### Errado vs Certo
+
+```javascript
+// ❌ Getter não-reativo — nunca vai atualizar o componente
+const useSubscriptionStore = create((set) => ({
+    subscription: null,
+    get isTrialing() { return this.subscription?.status === 'trialing' }
+}))
+
+// ✅ Derive no componente
+const subscription = useSubscriptionStore((s) => s.subscription)
+const isTrialing = subscription?.status === 'trialing'
+```
+
+---
+
+## 3. i18n — Todas as strings visíveis devem usar `t()`
+
+O projeto usa **i18next** com 3 idiomas (pt-BR, en, es). Nenhuma string visível ao usuário pode ser hardcoded.
+
+### Como usar
+
+```javascript
+import { useTranslation } from 'react-i18next'
+
+const MyComponent = () => {
+    const { t } = useTranslation()
+
+    return (
+        <Button onClick={handleSave}>{t('common.save')}</Button>
+    )
+}
+```
+
+### Regras
+
+- **Sempre importar `useTranslation`** antes de usar `t()`. Sem isso, crash em runtime.
+- Strings de UI: `t('namespace.key')` — nunca hardcode.
+- Strings técnicas (logs, variável interna): podem ser em inglês, não precisam de `t()`.
+- Chaves de namespace: domínio da feature (`feeds.`, `posts.`, `media.`) + `common.` para compartilhados.
+- Mensagens de erro da API já vêm traduzidas do backend — não duplique.
+
+### Errado
+
+```javascript
+// ❌ String hardcoded visível ao usuário
+<Button>Salvar Alterações</Button>
+<Text>Nenhuma mídia encontrada.</Text>
+
+// ❌ t() sem import — crash
+const handleSave = async () => {
+    showNotification({ title: t('common.success') }) // ReferenceError
+}
+```
+
+### Certo
+
+```javascript
+// ✅
+import { useTranslation } from 'react-i18next'
+
+const { t } = useTranslation()
+<Button>{t('common.save')}</Button>
+<Text>{t('media.empty')}</Text>
+```
+
+---
+
+## 4. Services — camada de HTTP
+
+Todas as chamadas de API vão por `services/`. Componentes e stores não chamam HTTP diretamente.
+
+### Padrão
+
+```javascript
+// services/feeds.js
+import { api } from './api'
+
+export const feedsService = {
+    getAll: () => api.get('feeds').json(),
+    getById: (id) => api.get(`feeds/${id}`).json(),
+    create: (data) => api.post('feeds', { json: data }).json(),
+    update: (id, data) => api.put(`feeds/${id}`, { json: data }).json(),
+    remove: (id) => api.delete(`feeds/${id}`).json(),
+}
+```
+
+- `api.js` tem a instância base com token de auth e tratamento de erro.
+- **Não duplique `API_URL`** — já está no `api.js`. Nunca redefina em outro arquivo.
+- Services são funções puras de chamada HTTP. Sem lógica de estado.
+
+---
+
+## 5. Componentes — regras práticas
+
+### Composição
+
+- Um componente, uma responsabilidade.
+- Se um componente ultrapassar ~100 linhas, divide.
+- Props down, events up. Sem drilling profundo — usa store.
+
+### Interação com usuário
+
+- **Confirmação de exclusão:** sempre usar `HoldButton` / `ButtonDelete` do `components/Buttons.jsx`. Nunca usar `confirm()` nativo.
+- **Hover/focus:** usar props do Mantine (`styles`, `withBorder`, hover via `&:hover` no `styles`). Nunca manipular DOM diretamente via `e.currentTarget.style`.
+
+```javascript
+// ❌ Manipulação direta de DOM
+onMouseEnter={(e) => e.currentTarget.style.background = '#eee'}
+
+// ✅ Mantine styles prop
+styles={{ root: { '&:hover': { backgroundColor: 'var(--mantine-color-dimmed)' } } }}
+```
+
+### Não redefina componentes do Mantine
+
+Se você precisa de um `Center`, `TextInput`, `Button` — use o do Mantine. Nunca crie um local com o mesmo nome, isso gera shadow e confusão.
+
+---
+
+## 6. Constantes e valores fixos
+
+- Strings de config (phone numbers, mensagens template, URLs externas) vão em `constants/` ou `.env`.
+- Nunca hardcode dentro de componentes.
+
+```javascript
+// ❌
+const message = `Olá, preciso de ajuda com meu plano.`
+
+// ✅ constants/whatsapp.js
+export const WHATSAPP_SUPPORT_NUMBER = '...'
+export const WHATSAPP_SUPPORT_MESSAGE = '...' // ou via i18n se traduzível
+```
+
+---
+
+## 7. Anti-patterns (do código real)
+
+| ❌ Problema real encontrado | ✅ Como resolver |
+|---|---|
+| `slugify` duplicado em 2 arquivos | Extrair para `utils/slugify.js` |
+| `stripHtml` duplicado em 2 arquivos | Extrair para `utils/stripHtml.js` |
+| `API_URL` redefinido fora do `api.js` | Importar do `services/api.js` |
+| `t()` usado sem `useTranslation` importado | Sempre verificar import |
+| Componente Mantine shadowed por local | Deletar o local, usar Mantine |
+| Código comentado espalhado | Deletar. Se precisa, usa git. |
+| `confirm()` misturado com HoldButton | Usa HoldButton sempre |
+| `<style>` tag com CSS raw | Usa `styles` prop do Mantine (exceção: libs externas como ProseMirror que precisam de CSS global) |
+| Getters no Zustand store | Derive no componente |
+| `onMouseEnter` manipulando style diretamente | Usa `styles` prop do Mantine |
+
+---
+
+## Related Skills
+
+- @[.agent/skills/riligar-design-system]
+- @[.agent/skills/riligar-dev-stack]

package/.agent/skills/{riligar-dev-stripe → riligar-infra-stripe}/SKILL.md

@@ -252,6 +252,6 @@ stripe trigger checkout.session.completed
 ## Related Skills
 
 - @[.agent/skills/riligar-dev-backend]
-- @[.agent/skills/riligar-dev-frontend]
+- @[.agent/skills/riligar-dev-dashboard]
 - @[.agent/skills/riligar-dev-auth-elysia]
 - @[.agent/skills/riligar-tech-stack]

package/.agent/skills/skill-creator/SKILL.md

@@ -78,7 +78,7 @@ Every skill must have a `type` field that categorizes it. This enables organizat
 
 - Directory name MUST match the `name` field in frontmatter
 - Use pattern: `riligar-{type}-{specific-name}`
-- Examples: `riligar-dev-frontend`, `riligar-marketing-copy`, `riligar-business-startup-analyst`
+- Examples: `riligar-dev-dashboard`, `riligar-marketing-copy`, `riligar-business-startup-analyst`
 
 #### SKILL.md (required)
 

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@riligar/agents-kit",
-    "version": "1.14.0",
+    "version": "1.15.0",
     "publishConfig": {
         "access": "public"
     },

package/.agent/skills/riligar-dev-architecture/SKILL.md

@@ -1,54 +0,0 @@
----
-name: riligar-dev-architecture
-description: Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
----
-
-# Architecture Decision Framework
-
-> "Requirements drive architecture. Trade-offs inform decisions. ADRs capture rationale."
-
-## 🎯 Selective Reading Rule
-
-**Read ONLY files relevant to the request!** Check the content map, find what you need.
-
-| File                                | Description                              | When to Read                 |
-| ----------------------------------- | ---------------------------------------- | ---------------------------- |
-| `references/context-discovery.md`   | Questions to ask, project classification | Starting architecture design |
-| `references/trade-off-analysis.md`  | ADR templates, trade-off framework       | Documenting decisions        |
-| `references/pattern-selection.md`   | Decision trees, anti-patterns            | Choosing patterns            |
-| `references/examples.md`            | MVP, SaaS, Enterprise examples           | Reference implementations    |
-| `references/patterns-reference.md`  | Quick lookup for patterns                | Pattern comparison           |
-
----
-
-## 🔗 Related Skills
-
-| Skill                             | Use For                 |
-| --------------------------------- | ----------------------- |
-| `@[skills/database-design]`       | Database schema design  |
-| `@[skills/api-patterns]`          | API design patterns     |
-| `@[skills/deployment-procedures]` | Deployment architecture |
-
----
-
-## Core Principle
-
-**"Simplicity is the ultimate sophistication."**
-
-- Start simple
-- Add complexity ONLY when proven necessary
-- You can always add patterns later
-- Removing complexity is MUCH harder than adding it
-
----
-
-## Validation Checklist
-
-Before finalizing architecture:
-
-- [ ] Requirements clearly understood
-- [ ] Constraints identified
-- [ ] Each decision has trade-off analysis
-- [ ] Simpler alternatives considered
-- [ ] ADRs written for significant decisions
-- [ ] Team expertise matches chosen patterns

package/.agent/skills/riligar-dev-architecture/references/context-discovery.md

@@ -1,43 +0,0 @@
-# Context Discovery
-
-> Before suggesting any architecture, gather context.
-
-## Question Hierarchy (Ask User FIRST)
-
-1. **Scale**
-   - How many users? (10, 1K, 100K, 1M+)
-   - Data volume? (MB, GB, TB)
-   - Transaction rate? (per second/minute)
-
-2. **Team**
-   - Solo developer or team?
-   - Team size and expertise?
-   - Distributed or co-located?
-
-3. **Timeline**
-   - MVP/Prototype or long-term product?
-   - Time to market pressure?
-
-4. **Domain**
-   - CRUD-heavy or business logic complex?
-   - Real-time requirements?
-   - Compliance/regulations?
-
-5. **Constraints**
-   - Budget limitations?
-   - Legacy systems to integrate?
-   - Technology stack preferences?
-
-## Project Classification Matrix
-
-```
-                    MVP              SaaS           Enterprise
-┌─────────────────────────────────────────────────────────────┐
-│ Scale        │ <1K           │ 1K-100K      │ 100K+        │
-│ Team         │ Solo          │ 2-10         │ 10+          │
-│ Timeline     │ Fast (weeks)  │ Medium (months)│ Long (years)│
-│ Architecture │ Simple        │ Modular      │ Distributed  │
-│ Patterns     │ Minimal       │ Selective    │ Comprehensive│
-│ Example      │ Next.js API   │ NestJS       │ Microservices│
-└─────────────────────────────────────────────────────────────┘
-```

package/.agent/skills/riligar-dev-architecture/references/examples.md

@@ -1,94 +0,0 @@
-# Architecture Examples
-
-> Real-world architecture decisions by project type.
-
----
-
-## Example 1: MVP E-commerce (Solo Developer)
-
-```yaml
-Requirements:
-  - <1000 users initially
-  - Solo developer
-  - Fast to market (8 weeks)
-  - Budget-conscious
-
-Architecture Decisions:
-  App Structure: Monolith (simpler for solo)
-  Framework: Next.js (full-stack, fast)
-  Data Layer: Prisma direct (no over-abstraction)
-  Authentication: JWT (simpler than OAuth)
-  Payment: Stripe (hosted solution)
-  Database: PostgreSQL (ACID for orders)
-
-Trade-offs Accepted:
-  - Monolith → Can't scale independently (team doesn't justify it)
-  - No Repository → Less testable (simple CRUD doesn't need it)
-  - JWT → No social login initially (can add later)
-
-Future Migration Path:
-  - Users > 10K → Extract payment service
-  - Team > 3 → Add Repository pattern
-  - Social login requested → Add OAuth
-```
-
----
-
-## Example 2: SaaS Product (5-10 Developers)
-
-```yaml
-Requirements:
-  - 1K-100K users
-  - 5-10 developers
-  - Long-term (12+ months)
-  - Multiple domains (billing, users, core)
-
-Architecture Decisions:
-  App Structure: Modular Monolith (team size optimal)
-  Framework: NestJS (modular by design)
-  Data Layer: Repository pattern (testing, flexibility)
-  Domain Model: Partial DDD (rich entities)
-  Authentication: OAuth + JWT
-  Caching: Redis
-  Database: PostgreSQL
-
-Trade-offs Accepted:
-  - Modular Monolith → Some module coupling (microservices not justified)
-  - Partial DDD → No full aggregates (no domain experts)
-  - RabbitMQ later → Initial synchronous (add when proven needed)
-
-Migration Path:
-  - Team > 10 → Consider microservices
-  - Domains conflict → Extract bounded contexts
-  - Read performance issues → Add CQRS
-```
-
----
-
-## Example 3: Enterprise (100K+ Users)
-
-```yaml
-Requirements:
-  - 100K+ users
-  - 10+ developers
-  - Multiple business domains
-  - Different scaling needs
-  - 24/7 availability
-
-Architecture Decisions:
-  App Structure: Microservices (independent scale)
-  API Gateway: Kong/AWS API GW
-  Domain Model: Full DDD
-  Consistency: Event-driven (eventual OK)
-  Message Bus: Kafka
-  Authentication: OAuth + SAML (enterprise SSO)
-  Database: Polyglot (right tool per job)
-  CQRS: Selected services
-
-Operational Requirements:
-  - Service mesh (Istio/Linkerd)
-  - Distributed tracing (Jaeger/Tempo)
-  - Centralized logging (ELK/Loki)
-  - Circuit breakers (Resilience4j)
-  - Kubernetes/Helm
-```

package/.agent/skills/riligar-dev-architecture/references/pattern-selection.md

@@ -1,68 +0,0 @@
-# Pattern Selection Guidelines
-
-> Decision trees for choosing architectural patterns.
-
-## Main Decision Tree
-
-```
-START: What's your MAIN concern?
-
-┌─ Data Access Complexity?
-│  ├─ HIGH (complex queries, testing needed)
-│  │  → Repository Pattern + Unit of Work
-│  │  VALIDATE: Will data source change frequently?
-│  │     ├─ YES → Repository worth the indirection
-│  │     └─ NO  → Consider simpler ORM direct access
-│  └─ LOW (simple CRUD, single database)
-│     → ORM directly (Prisma, Drizzle)
-│     Simpler = Better, Faster
-│
-├─ Business Rules Complexity?
-│  ├─ HIGH (domain logic, rules vary by context)
-│  │  → Domain-Driven Design
-│  │  VALIDATE: Do you have domain experts on team?
-│  │     ├─ YES → Full DDD (Aggregates, Value Objects)
-│  │     └─ NO  → Partial DDD (rich entities, clear boundaries)
-│  └─ LOW (mostly CRUD, simple validation)
-│     → Transaction Script pattern
-│     Simpler = Better, Faster
-│
-├─ Independent Scaling Needed?
-│  ├─ YES (different components scale differently)
-│  │  → Microservices WORTH the complexity
-│  │  REQUIREMENTS (ALL must be true):
-│  │    - Clear domain boundaries
-│  │    - Team > 10 developers
-│  │    - Different scaling needs per service
-│  │  IF NOT ALL MET → Modular Monolith instead
-│  └─ NO (everything scales together)
-│     → Modular Monolith
-│     Can extract services later when proven needed
-│
-└─ Real-time Requirements?
-   ├─ HIGH (immediate updates, multi-user sync)
-   │  → Event-Driven Architecture
-   │  → Message Queue (RabbitMQ, Redis, Kafka)
-   │  VALIDATE: Can you handle eventual consistency?
-   │     ├─ YES → Event-driven valid
-   │     └─ NO  → Synchronous with polling
-   └─ LOW (eventual consistency acceptable)
-      → Synchronous (REST/GraphQL)
-      Simpler = Better, Faster
-```
-
-## The 3 Questions (Before ANY Pattern)
-
-1. **Problem Solved**: What SPECIFIC problem does this pattern solve?
-2. **Simpler Alternative**: Is there a simpler solution?
-3. **Deferred Complexity**: Can we add this LATER when needed?
-
-## Red Flags (Anti-patterns)
-
-| Pattern | Anti-pattern | Simpler Alternative |
-|---------|-------------|-------------------|
-| Microservices | Premature splitting | Start monolith, extract later |
-| Clean/Hexagonal | Over-abstraction | Concrete first, interfaces later |
-| Event Sourcing | Over-engineering | Append-only audit log |
-| CQRS | Unnecessary complexity | Single model |
-| Repository | YAGNI for simple CRUD | ORM direct access |