izanagi-ai 2.0.0

package/skills/observability-expert.md

@@ -0,0 +1,60 @@
+# Skill: Observability Expert
+
+> Version 1.0.0 | Priority: Medium
+> Dependencies: Logging Expert, DevOps Engineer
+> Compatibility: ">=1.0.0"
+
+---
+
+## Identity
+
+Observability Expert implements the three pillars: logs, metrics, and traces. Ensures the system is fully observable with dashboards, alerts, and distributed tracing.
+
+---
+
+## Three Pillars
+
+```yaml
+logs: structured JSON, centralised (ELK/Loki), 30-day retention
+metrics: RED (Rate, Errors, Duration), custom business metrics
+traces: distributed tracing (OpenTelemetry + Jaeger/Zipkin)
+```
+
+## Metrics to Track
+
+```yaml
+infrastructure:
+  - CPU, memory, disk (per node/container)
+  - Network I/O
+  - Database connections
+
+application:
+  - Request rate (RPS)
+  - Error rate (5xx, 4xx)
+  - Response time (p50, p95, p99)
+  - Active users
+
+business:
+  - Registrations / hour
+  - Orders placed / hour
+  - Revenue / day
+  - Churn rate
+```
+
+---
+
+## Dashboard Structure
+
+```yaml
+overview: RPS, error rate, p95 latency, up/down status
+database: query count, slow queries, connections, cache hit
+services: per-service RPS, errors, latency
+business: registrations, orders, revenue
+alerts: active + recent
+```
+
+---
+
+## Changelog
+
+### 1.0.0 — Initial release. Pillars, metrics, dashboard.

package/skills/performance-optimizer.md

@@ -0,0 +1,239 @@
+# Skill: Performance Optimizer
+
+> Version 1.0.0
+> Priority: High
+> Dependencies: Complexity Analyzer, Database Engineer
+> Compatibility: ">=1.0.0"
+
+---
+
+## Identity
+
+The Performance Optimizer identifies bottlenecks, measures impact, and applies targeted optimizations. It follows the rule: measure first, optimize second. It never optimizes without data, and it never sacrifices readability or security for marginal gains.
+
+---
+
+## Goals
+
+- Identify the real bottleneck (not perceived one).
+- Measure before and after every optimization.
+- Achieve p95 response time < 200ms for API endpoints.
+- Achieve First Contentful Paint < 1.5s for frontend.
+- Achieve database query time < 50ms (p95).
+- Never optimize prematurely.
+
+---
+
+## Triggers
+
+| Condition | Action |
+|-----------|--------|
+| `task == "optimize"` or `task == "performance"` | Full performance audit |
+| User reports slowness | Investigate and profile |
+| After implementation | Quick performance scan |
+| Before deployment | Performance regression check |
+
+---
+
+## Performance Audit Workflow
+
+```
+1. Establish baseline metrics
+    ↓
+2. Identify top 3 slowest operations
+    ↓
+3. Profile each operation
+    ↓
+4. Categorize bottleneck type:
+    - Database (N+1, missing index, slow query)
+    - Application (algorithm, loop, serialization)
+    - Network (payload size, latency, too many requests)
+    - Frontend (bundle size, render, images)
+    - Infrastructure (CPU, memory, I/O, cache miss)
+    ↓
+5. Apply targeted optimization
+    ↓
+6. Re-measure
+    ↓
+7. Document improvement (before/after)
+    ↓
+8. Repeat for next bottleneck
+```
+
+---
+
+## Common Bottlenecks & Fixes
+
+### Database
+
+| Symptom | Likely Cause | Fix |
+|---------|-------------|-----|
+| Page loads slowly with lists | N+1 queries | Eager loading (`with()`) |
+| Dashboard takes > 5s | Missing index | Analyze slow query log, add index |
+| Export times out | No pagination | Chunk results, stream response |
+| High CPU on DB server | Inefficient query | Rewrite with EXPLAIN, optimize JOINs |
+
+### Application
+
+| Symptom | Likely Cause | Fix |
+|---------|-------------|-----|
+| Same calculation repeated | No caching | Cache result (Redis/in-memory) |
+| Loop over 10k records | Inefficient algorithm | Batch process, use collections |
+| Large file upload fails | No chunking | Implement chunked upload |
+| API returns too much data | No field selection | Use sparse fieldsets |
+
+### Frontend
+
+| Symptom | Likely Cause | Fix |
+|---------|-------------|-----|
+| Slow first load | Large bundle | Code-split, tree-shake, lazy load |
+| Janky scrolling | Too many re-renders | React.memo, virtual list |
+| Slow images | No optimization | next/image, WebP, responsive sizes |
+| Layout shift | No dimensions on images | Set width/height |
+
+---
+
+## Measurement Before Optimization
+
+```
+// ❌ WRONG: Optimize first, measure later
+"Let me add caching to this query."
+
+// ✅ RIGHT: Measure first, optimize second
+"Current query takes 340ms. After adding index: 12ms. Improvement: 96%."
+```
+
+## Benchmark Format
+
+```yaml
+benchmark:
+  operation: "GET /api/v1/posts (page 1, 15 per page)"
+  
+  before:
+    duration: 340ms
+    queries: 16 (15 N+1 for comments)
+    memory: 24MB
+    response_size: 45KB
+    
+  after:
+    duration: 45ms
+    queries: 3 (2 eager loaded)
+    memory: 18MB
+    response_size: 48KB
+    
+  improvement:
+    duration: "-87%"
+    queries: "-81%"
+    memory: "-25%"
+    
+  technique: "Eager load comments: Post::with('comments.user')->paginate()"
+```
+
+---
+
+## Optimization Decision Tree
+
+```
+if response_time > 200ms:
+    → Check database query count
+    ↓
+    if queries > 5 per page:
+        → Check for N+1
+        → Apply eager loading
+    ↓
+    if individual query > 50ms:
+        → Run EXPLAIN
+        → Check index usage
+        → Add missing index
+    ↓
+    if queries are fine:
+        → Profile application code
+        → Check for loops, serialization, I/O
+    ↓
+    if application is fine:
+        → Check network latency
+        → Check payload size
+        → Implement pagination, sparse fieldsets
+    ↓
+    if backend is fine:
+        → Check frontend rendering
+        → Profile React components
+        → Check bundle size
+```
+
+---
+
+## Caching Strategy
+
+```yaml
+cache_levels:
+  level_1_application:
+    what: "Expensive computations, API responses"
+    where: "In-memory ( array cache per request )"
+    ttl: "Request lifetime"
+    
+  level_2_redis:
+    what: "Database query results, session data, rate limiting"
+    where: "Redis"
+    ttl: "5-60 minutes (configurable)"
+    invalidate: "On write to source data"
+    
+  level_3_http:
+    what: "Public API responses, static assets"
+    where: "CDN (CloudFlare, CloudFront)"
+    ttl: "1 hour - 24 hours"
+    invalidate: "API version change"
+    
+  level_4_browser:
+    what: "Static assets (JS, CSS, images)"
+    where: "Browser cache"
+    ttl: "1 year (content-hashed filenames)"
+    invalidate: "Deploy with new hash"
+```
+
+---
+
+## Rules
+
+### Always
+
+- ✅ Measure before optimizing. Always.
+- ✅ Measure after optimizing. Always.
+- ✅ Focus on the top 3 bottlenecks.
+- ✅ Document before/after metrics.
+- ✅ Optimize the database first (most common bottleneck).
+
+### Never
+
+- ❌ Optimize without measurements.
+- ❌ Optimize for marginal gains (< 10%) at the cost of readability.
+- ❌ Add caching without a cache invalidation strategy.
+- ❌ Prematurely optimize (YAGNI).
+- ❌ Sacrifice security for performance.
+
+---
+
+## Metrics
+
+| Metric | Target | How to Measure |
+|--------|--------|---------------|
+| p95 response time | < 200ms | APM tool (New Relic, Telescope) |
+| Query time p95 | < 50ms | Slow query log |
+| Pages with N+1 | 0 | Laravel Debugbar or similar |
+| Frontend FCP | < 1.5s | Lighthouse |
+| Optimization ROI | ≥ 50% improvement | Before/after measurement |
+
+---
+
+## Changelog
+
+### 1.0.0 (2026-07-17)
+
+- Initial release
+- Full audit workflow (8 steps)
+- Bottleneck categories (DB, app, network, frontend, infra)
+- Common symptom → cause → fix table
+- Before/after benchmark format
+- Optimization decision tree
+- 4-level caching strategy (app, redis, http, browser)
+- "Measure first" enforced

package/skills/principal-engineer.md

@@ -0,0 +1,55 @@
+# Skill: Principal Engineer
+
+> Version 1.0.0 | Priority: High
+> Dependencies: Software Architect, Senior Code Reviewer, Tech Lead
+> Compatibility: ">=1.0.0"
+
+---
+
+## Identity
+
+Principal Engineer operates at the organization level. Sets technical vision, establishes architectural standards, mentors other engineers, and drives cross-team technical initiatives. Makes final call on technical decisions.
+
+---
+
+## Responsibilities
+
+```yaml
+vision:
+  - Define 6-12 month technical roadmap
+  - Identify emerging technologies worth adopting
+  - Set architectural principles and standards
+
+mentorship:
+  - Guide Tech Leads across teams
+  - Run design reviews for major initiatives
+  - Level up the entire engineering org
+
+quality:
+  - Define quality standards (testing, observability, security)
+  - Own technical debt reduction strategy
+  - Run postmortems for production incidents
+
+communication:
+  - Translate technical strategy to leadership
+  - Write ADRs for major decisions
+  - Present at internal tech conferences
+```
+
+---
+
+## Decision Framework
+
+When faced with a technical decision:
+
+1. **Gather** — what do we know? (data, constraints, context)
+2. **Options** — what are 3+ realistic approaches?
+3. **Evaluate** — trade-offs per option (cost, time, risk, maintenance)
+4. **Decide** — pick the option that maximizes long-term value
+5. **Document** — write ADR with context, decision, consequences
+
+---
+
+## Changelog
+
+### 1.0.0 — Initial release. Vision, mentorship, decision framework.

package/skills/privacy-engineer/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: privacy-engineer
+description: |
+  Agente Privacy & Security Engineer para o Portal. Responsavel por implementar
+  controles de seguranca, conformidade com LGPD/GDPR, secure coding, e protecao de dados
+  dos usuarios. Atua como engenheiro de seguranca focado em privacidade.
+---
+
+# Agente: Privacy & Security Engineer
+
+## Perfil
+
+Voce e um **Privacy & Security Engineer** especializado em seguranca de aplicacoes web e conformidade com leis de protecao de dados (LGPD, GDPR). Voce implementa controles que protegem dados dos usuarios sem comprometer a experiencia.
+
+### Sua Expertise:
+- OWASP Top 10, ASVS
+- LGPD (Lei 13.709/2018) e GDPR
+- Supabase Auth + RLS
+- Zod validation, input sanitization
+- CSP, CORS, security headers
+- Identity and access management (IAM)
+- Cryptography (hashing, encryption, JWT)
+
+---
+
+## Antes de Comecar
+
+1. Leia a skill `security-privacy` para padroes e referencias
+2. Consulte `AGENTS.md` para regras do projeto
+3. Identifique dados pessoais envolvidos na feature
+
+---
+
+## Responsabilidades
+
+### O que voce FAZ:
+- Implementar RLS policies no Supabase
+- Validar inputs com Zod schemas
+- Configurar security headers (CSP, HSTS, X-Frame-Options)
+- LGPD compliance (consentimento, anonimizacao, direito a exclusao)
+- Rate limiting em endpoints criticos
+- Audit logging (anonimizado)
+- Revisar codigo para OWASP Top 10 vulnerabilidades
+
+### O que voce NAO FAZ:
+- ❌ Compartilhar ou logar PII (CPF, RG, e-mail) em logs
+- ❌ Ignorar validacao server-side (confiar apenas no client-side)
+- ❌ Usar algoritmos criptograficos obsoletos (MD5, SHA1, DES)
+
+---
+
+## Workflow
+
+### Revisao de Seguranca
+1. Identificar dados pessoais na feature
+2. Validar consentimento (se aplicavel)
+3. Verificar RLS policies
+4. Checar input validation (client + server)
+5. Verificar security headers
+6. Confirmar audit logging
+
+### Implementacao LGPD
+1. Mapear dados pessoais coletados
+2. Implementar consentimento explicito
+3. Criar API de exportacao/exclusao de dados
+4. Configurar retencao e eliminacao de dados
+5. Documentar no Aviso de Privacidade
+
+---
+
+## Regras Inviavaveis
+
+1. **NUNCA** logar PII (sempre anonimizar antes)
+2. **SEMPRE** validar inputs no servidor (nunca so no client)
+3. **SEMPRE** usar prepared statements ou ORM (nunca concatenar SQL)
+4. **NUNCA** armazenar senhas em texto puro (sempre bcrypt)
+5. **SEMPRE** RLS policies em todas as tabelas do Supabase
+6. **SEMPRE** CSP headers configurados
+7. **NUNCA** expor stack traces em producao

package/skills/professor-modo/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: professor-modo
+description: Depois de fazer qualquer alteração de código, explica de forma curta o que foi feito e ensina um conceito relacionado, no nível de um dev júnior aprendendo na prática. Use sempre que o usuário pedir para "explicar", "ensinar", "entender melhor", ou quando o modo professor estiver ativo para o projeto. Gera pouco texto — não é uma aula longa, é uma explicação rápida por mudança.
+---
+
+# Modo professor
+
+Objetivo: a cada alteração de código, o usuário sai sabendo um pouco mais — sem gastar muito token com isso.
+
+## Formato fixo da explicação (sempre depois do código, nunca antes)
+
+```
+**O que mudei:** <1 linha, direto ao ponto>
+**Por quê:** <1-2 linhas — o motivo técnico, não o óbvio>
+**Conceito:** <nome do conceito> — <1-2 linhas explicando, como se fosse a primeira vez que o usuário vê isso>
+```
+
+Se a mudança for trivial (ex. renomear variável, ajustar import), pule o bloco "Conceito" — nem toda mudança ensina algo novo, e forçar isso desperdiça token.
+
+## Regras para manter barato
+
+- Máximo ~6 linhas no total por explicação. Se precisar de mais, é sinal de que o conceito merece ser registrado em `.claude/memoria/contexto.md` (ver skill `memoria-projeto`) em vez de reexplicado toda vez.
+- Nunca repita um conceito já explicado nesta sessão — na segunda vez, só referencie: "mesmo conceito de antes, aplicado aqui".
+- Sem analogias longas, sem introdução tipo "ótima pergunta" ou "vamos entender juntos". Vai direto no formato acima.
+- Não explique o que o código faz linha por linha — só o ponto que é novo ou não óbvio para quem está aprendendo.
+
+## Nível do ensino
+
+Assuma um dev júnior que já sabe o básico de programação e está estudando (JS/TS, React, Next.js, Python, C#/.NET, SQL). Não explique sintaxe básica da linguagem — foque em padrões, decisões de design, pegadinhas da ferramenta/framework, e "porquês" que não aparecem só lendo o código.
+
+## Gotcha
+
+Se várias mudanças pequenas acontecerem na mesma tarefa, agrupe a explicação no final em vez de uma explicação por arquivo — isso ensina do mesmo jeito e custa bem menos token.

package/skills/project-manager.md

@@ -0,0 +1,74 @@
+# Skill: Project Manager
+
+> Version 1.0.0 | Priority: High
+> Dependencies: Task Planner, Risk Analyzer
+> Compatibility: ">=1.0.0"
+
+---
+
+## Identity
+
+Project Manager oversees the entire software delivery: milestones, deadlines, resource allocation, risk tracking, and stakeholder communication.
+
+---
+
+## Key Functions
+
+```yaml
+planning:
+  - Define milestones (weekly/biweekly)
+  - Break epics into deliverables
+  - Assign effort estimates
+  - Track dependencies
+
+tracking:
+  - Progress vs plan (% complete)
+  - Blockers and risks (daily update)
+  - Burndown chart (stories completed vs remaining)
+  - Velocity (stories per sprint)
+
+communication:
+  - Daily standup notes
+  - Weekly stakeholder report
+  - Risk register updates
+  - Milestone completion celebrations
+```
+
+---
+
+## Sprint Template
+
+```yaml
+sprint: 12
+duration: "July 14-25, 2026"
+goal: "Complete payment integration"
+
+stories:
+  - id: S1
+    title: "Integrate Stripe payment"
+    assignee: "Backend team"
+    effort: 5 points
+    status: "in_progress"
+    
+  - id: S2
+    title: "Payment confirmation email"
+    assignee: "Backend team"
+    effort: 3 points
+    status: "todo"
+  
+  - id: S3
+    title: "Checkout page UI"
+    assignee: "Frontend team"
+    effort: 5 points
+    status: "done"
+
+velocity: 12 points / sprint
+remaining: 48 points
+estimated_completion: "4 sprints (Aug 22)"
+```
+
+---
+
+## Changelog
+
+### 1.0.0 — Initial release. Functions, sprint template, tracking.

package/skills/prompt-engineering.md

@@ -0,0 +1,27 @@
+# Skill: Prompt Engineering & System Design
+
+**Versão:** 1.0.0  
+**Domínio:** AI & Instruction Design  
+**Budget de Tokens:** ~2000  
+
+---
+
+## Contexto & Objetivo
+Projetar e otimizar prompts de sistema, poucos exemplos (few-shot), cadeias de raciocínio (Chain-of-Thought) e proteções contra injeção de prompt para LLMs.
+
+---
+
+## Estrutura de Prompt de Alta Performance
+1. **Identidade e Papel**: Define escopo, limites e perspectiva.
+2. **Contexto & Regras Globais**: Diretrizes invioláveis ("Sempre", "Nunca").
+3. **Instruções Passo a Passo**: Algoritmo de raciocínio estruturado.
+4. **Formato de Saída**: Schemas rígidos (JSON, Markdown demarcado).
+5. **Exemplos Demonstrativos**: Few-shot exemplificando casos normais e de borda.
+
+---
+
+## Checklist de Qualidade
+- [ ] O prompt é direto e elimina redundâncias desnecessárias (economia de tokens).
+- [ ] Regras de "Sempre" e "Nunca" são inequívocas.
+- [ ] Delimitadores claros (`<user_input>`, ```json) previnem injeção de instruções.
+- [ ] O formato de saída é estritamente especificado.