@riligar/agents-kit 1.14.0 → 1.16.0

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 |

package/.agent/skills/riligar-dev-architecture/references/patterns-reference.md

@@ -1,50 +0,0 @@
-# Architecture Patterns Reference
-
-> Quick reference for common patterns with usage guidance.
-
-## Data Access Patterns
-
-| Pattern | When to Use | When NOT to Use | Complexity |
-|---------|-------------|-----------------|------------|
-| **Active Record** | Simple CRUD, rapid prototyping | Complex queries, multiple sources | Low |
-| **Repository** | Testing needed, multiple sources | Simple CRUD, single database | Medium |
-| **Unit of Work** | Complex transactions | Simple operations | High |
-| **Data Mapper** | Complex domain, performance | Simple CRUD, rapid dev | High |
-
-## Domain Logic Patterns
-
-| Pattern | When to Use | When NOT to Use | Complexity |
-|---------|-------------|-----------------|------------|
-| **Transaction Script** | Simple CRUD, procedural | Complex business rules | Low |
-| **Table Module** | Record-based logic | Rich behavior needed | Low |
-| **Domain Model** | Complex business logic | Simple CRUD | Medium |
-| **DDD (Full)** | Complex domain, domain experts | Simple domain, no experts | High |
-
-## Distributed System Patterns
-
-| Pattern | When to Use | When NOT to Use | Complexity |
-|---------|-------------|-----------------|------------|
-| **Modular Monolith** | Small teams, unclear boundaries | Clear contexts, different scales | Medium |
-| **Microservices** | Different scales, large teams | Small teams, simple domain | Very High |
-| **Event-Driven** | Real-time, loose coupling | Simple workflows, strong consistency | High |
-| **CQRS** | Read/write performance diverges | Simple CRUD, same model | High |
-| **Saga** | Distributed transactions | Single database, simple ACID | High |
-
-## API Patterns
-
-| Pattern | When to Use | When NOT to Use | Complexity |
-|---------|-------------|-----------------|------------|
-| **REST** | Standard CRUD, resources | Real-time, complex queries | Low |
-| **GraphQL** | Flexible queries, multiple clients | Simple CRUD, caching needs | Medium |
-| **gRPC** | Internal services, performance | Public APIs, browser clients | Medium |
-| **WebSocket** | Real-time updates | Simple request/response | Medium |
-
----
-
-## Simplicity Principle
-
-**"Start simple, add complexity only when proven necessary."**
-
-- You can always add patterns later
-- Removing complexity is MUCH harder than adding it
-- When in doubt, choose simpler option

package/.agent/skills/riligar-dev-architecture/references/trade-off-analysis.md

@@ -1,77 +0,0 @@
-# Trade-off Analysis & ADR
-
-> Document every architectural decision with trade-offs.
-
-## Decision Framework
-
-For EACH architectural component, document:
-
-```markdown
-## Architecture Decision Record
-
-### Context
-- **Problem**: [What problem are we solving?]
-- **Constraints**: [Team size, scale, timeline, budget]
-
-### Options Considered
-
-| Option | Pros | Cons | Complexity | When Valid |
-|--------|------|------|------------|-----------|
-| Option A | Benefit 1 | Cost 1 | Low | [Conditions] |
-| Option B | Benefit 2 | Cost 2 | High | [Conditions] |
-
-### Decision
-**Chosen**: [Option B]
-
-### Rationale
-1. [Reason 1 - tied to constraints]
-2. [Reason 2 - tied to requirements]
-
-### Trade-offs Accepted
-- [What we're giving up]
-- [Why this is acceptable]
-
-### Consequences
-- **Positive**: [Benefits we gain]
-- **Negative**: [Costs/risks we accept]
-- **Mitigation**: [How we'll address negatives]
-
-### Revisit Trigger
-- [When to reconsider this decision]
-```
-
-## ADR Template
-
-```markdown
-# ADR-[XXX]: [Decision Title]
-
-## Status
-Proposed | Accepted | Deprecated | Superseded by [ADR-YYY]
-
-## Context
-[What problem? What constraints?]
-
-## Decision
-[What we chose - be specific]
-
-## Rationale
-[Why - tie to requirements and constraints]
-
-## Trade-offs
-[What we're giving up - be honest]
-
-## Consequences
-- **Positive**: [Benefits]
-- **Negative**: [Costs]
-- **Mitigation**: [How to address]
-```
-
-## ADR Storage
-
-```
-docs/
-└── architecture/
-    ├── adr-001-use-nextjs.md
-    ├── adr-002-postgresql-over-mongodb.md
-    └── adr-003-adopt-repository-pattern.md
-```

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

@@ -1,59 +0,0 @@
----
-name: riligar-dev-autopilot
-description: Automação do ciclo de vida de desenvolvimento. Validação com Bun, Auto-correção, Commit Semântico e Deploy. Use para garantir código funcional e entregue em produção.
----
-
-# RiLiGar Dev-Autopilot Expert
-
-Você é responsável por garantir que cada interação do chat resulte em código funcional e entregue. Sua missão é fechar o ciclo entre o "escrever código" e o "código em produção".
-
-## 1. Filosofia do Loop
-
-- **Confiança:** O código não é considerado pronto até ser validado.
-- **Autonomia:** Corrigir erros triviais (lint, build, testes simples) sem onerar o usuário.
-- **Velocidade:** Uso intensivo do Bun para ciclos de feedback instantâneos.
-- **Transparência:** Commits claros que explicam a evolução da história/bug.
-
-## 2. Fluxo de Trabalho Obrigatório
-
-Toda vez que uma alteração de código for finalizada, você deve seguir este fluxo:
-
-### Passo 1: Validação (Bun)
-
-- **Check:** Executar `bun run lint` ou `bun x eslint .` para garantir padrões.
-    <!-- -   **Testes:** Rodar testes unitários/integração com `bun test`. -->
-    <!-- -   **Build:** Se for um projeto compilado (Vite), rodar `bun run build`. -->
-- **Auto-Correção:** Se houver erros, ANALISE a stack trace, CORRIJA o código e RE-VALIDE. Tente até 2 vezes antes de pedir ajuda ao usuário.
-
-### Passo 2: Versionamento (Commit Semântico)
-
-- Se a validação passar, gere uma mensagem de commit seguindo o padrão **Conventional Commits**:
-    - `feat:` para novas histórias.
-    - `fix:` para correções de bugs.
-    - `refactor:` para melhorias de código sem mudança de comportamento.
-    - `docs:` para documentação.
-
-### Passo 3: Publicação & Deploy
-
-- **Push:** Executar o comando `git-publish` (ou o atalho `gcp`).
-- **Deploy:**
-    - Se for infra Fly.io: Executar `fly deploy`.
-    - Se for via GitHub Actions: O push para a branch principal deve disparar o fluxo.
-
-## 3. Regras de Interface com o Usuário
-
-Ao concluir o loop com sucesso, apresente um resumo:
-
-- ✅ **Validado:** [Comando executado] (ex: `bun test` passou).
-- 📦 **Commit:** `[mensagem de commit]`
-- 🚀 **Status:** Deploy iniciado/concluído.
-
-Se falhar após as tentativas de auto-correção:
-
-- ❌ **Erro:** Explique detalhadamente o que falhou e mostre o log.
-- 💡 **Ação:** Pergunte como o usuário deseja proceder.
-
-## 4. Integração com Tech Stack
-
-- **Bun First:** Sempre prefira `bun` como gerenciador de pacotes e runtime.
-- **Mantine/React:** Verifique se as novas bibliotecas seguem o `riligar-design-system`.

package/.agent/skills/riligar-dev-code-review/SKILL.md

@@ -1,116 +0,0 @@
----
-name: riligar-dev-code-review
-description: Code review guidelines covering code quality, security, and best practices. Use when reviewing code or creating review checklists.
----
-
-# Code Review Checklist
-
-## Quick Review Checklist
-
-### Correctness
-
-- [ ] Code does what it's supposed to do
-- [ ] Edge cases handled
-- [ ] Error handling in place
-- [ ] No obvious bugs
-
-### Security
-
-- [ ] Input validated and sanitized
-- [ ] No SQL/NoSQL injection vulnerabilities
-- [ ] No XSS or CSRF vulnerabilities
-- [ ] No hardcoded secrets or sensitive credentials
-- [ ] **AI-Specific:** Protection against Prompt Injection (if applicable)
-- [ ] **AI-Specific:** Outputs are sanitized before being used in critical sinks
-
-### Performance
-
-- [ ] No N+1 queries
-- [ ] No unnecessary loops
-- [ ] Appropriate caching
-- [ ] Bundle size impact considered
-
-### Code Quality
-
-- [ ] Clear naming
-- [ ] DRY - no duplicate code
-- [ ] SOLID principles followed
-- [ ] Appropriate abstraction level
-
-### Testing
-
-- [ ] Unit tests for new code
-- [ ] Edge cases tested
-- [ ] Tests readable and maintainable
-
-### Documentation
-
-- [ ] Complex logic commented
-- [ ] Public APIs documented
-- [ ] README updated if needed
-
-## AI & LLM Review Patterns (2025)
-
-### Logic & Hallucinations
-
-- [ ] **Chain of Thought:** Does the logic follow a verifiable path?
-- [ ] **Edge Cases:** Did the AI account for empty states, timeouts, and partial failures?
-- [ ] **External State:** Is the code making safe assumptions about file systems or networks?
-
-### Prompt Engineering Review
-
-```markdown
-// ❌ Vague prompt in code
-const response = await ai.generate(userInput);
-
-// ✅ Structured & Safe prompt
-const response = await ai.generate({
-system: "You are a specialized parser...",
-input: sanitize(userInput),
-schema: ResponseSchema
-});
-```
-
-## Anti-Patterns to Flag
-
-```typescript
-// ❌ Magic numbers
-if (status === 3) { ... }
-
-// ✅ Named constants
-if (status === Status.ACTIVE) { ... }
-
-// ❌ Deep nesting
-if (a) { if (b) { if (c) { ... } } }
-
-// ✅ Early returns
-if (!a) return;
-if (!b) return;
-if (!c) return;
-// do work
-
-// ❌ Long functions (100+ lines)
-// ✅ Small, focused functions
-
-// ❌ any type
-const data: any = ...
-
-// ✅ Proper types
-const data: UserData = ...
-```
-
-## Review Comments Guide
-
-```
-// Blocking issues use 🔴
-🔴 BLOCKING: SQL injection vulnerability here
-
-// Important suggestions use 🟡
-🟡 SUGGESTION: Consider using useMemo for performance
-
-// Minor nits use 🟢
-🟢 NIT: Prefer const over let for immutable variable
-
-// Questions use ❓
-❓ QUESTION: What happens if user is null here?
-```

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

@@ -1,51 +0,0 @@
----
-name: riligar-dev-database
-description: Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases. Use when designing schemas or optimizing database performance.
----
-
-# Database Design
-
-> **Learn to THINK, not copy SQL patterns.**
-
-## 🎯 Selective Reading Rule
-
-**Read ONLY files relevant to the request!** Check the content map, find what you need.
-
-| File                              | Description                           | When to Read       |
-| --------------------------------- | ------------------------------------- | ------------------ |
-| `references/database-selection.md`| PostgreSQL vs Neon vs Turso vs SQLite | Choosing database  |
-| `references/orm-selection.md`     | Drizzle vs Prisma vs Kysely           | Choosing ORM       |
-| `references/schema-design.md`     | Normalization, PKs, relationships     | Designing schema   |
-| `references/indexing.md`          | Index types, composite indexes        | Performance tuning |
-| `references/optimization.md`      | N+1, EXPLAIN ANALYZE                  | Query optimization |
-| `references/migrations.md`        | Safe migrations, serverless DBs       | Schema changes     |
-
----
-
-## ⚠️ Core Principle
-
-- ASK user for database preferences when unclear
-- Choose database/ORM based on CONTEXT
-- Don't default to PostgreSQL for everything
-
----
-
-## Decision Checklist
-
-Before designing schema:
-
-- [ ] Asked user about database preference?
-- [ ] Chosen database for THIS context?
-- [ ] Considered deployment environment?
-- [ ] Planned index strategy?
-- [ ] Defined relationship types?
-
----
-
-## Anti-Patterns
-
-❌ Default to PostgreSQL for simple apps (SQLite may suffice)
-❌ Skip indexing
-❌ Use SELECT \* in production
-❌ Store JSON when structured data is better
-❌ Ignore N+1 queries

package/.agent/skills/riligar-dev-database/references/database-selection.md

@@ -1,43 +0,0 @@
-# Database Selection (2025)
-
-> Choose database based on context, not default.
-
-## Decision Tree
-
-```
-What are your requirements?
-│
-├── Full relational features needed
-│   ├── Self-hosted → PostgreSQL
-│   └── Serverless → Neon, Supabase
-│
-├── Edge deployment / Ultra-low latency
-│   └── Turso (edge SQLite)
-│
-├── AI / Vector search
-│   └── PostgreSQL + pgvector
-│
-├── Simple / Embedded / Local
-│   └── SQLite
-│
-└── Global distribution
-    └── PlanetScale, CockroachDB, Turso
-```
-
-## Comparison
-
-| Database | Best For | Trade-offs |
-|----------|----------|------------|
-| **PostgreSQL** | Full features, complex queries | Needs hosting |
-| **Neon** | Serverless PG, branching | PG complexity |
-| **Turso** | Edge, low latency | SQLite limitations |
-| **SQLite** | Simple, embedded, local | Single-writer |
-| **PlanetScale** | MySQL, global scale | No foreign keys |
-
-## Questions to Ask
-
-1. What's the deployment environment?
-2. How complex are the queries?
-3. Is edge/serverless important?
-4. Vector search needed?
-5. Global distribution required?