@runecraft/grimoire 1.0.0

package/skills/linkedin-audit/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: linkedin-audit
+description: Audita o perfil do LinkedIn (notas 0-10 em 8 seções, diagnósticos diretos, reescritas sugeridas) e gera um dashboard HTML standalone com as cores do LinkedIn. Use when the user asks for LinkedIn profile analysis or audit, "avalia meu perfil", "melhora meu LinkedIn", "audita meu LinkedIn", "dashboard do LinkedIn", or provides LinkedIn data, exported resume, profile photo or cover photo. Do NOT use for writing standalone posts, feed content, prospecting or job search without a profile analysis request.
+license: CC-BY-4.0
+metadata:
+  author: runecraft
+  version: 1.0.0
+---
+
+# LinkedIn Audit
+
+Audita o perfil do LinkedIn do usuário contra o objetivo que ele declarar, produz um relatório de análise com notas 0-10 por seção e gera um dashboard HTML standalone (arquivo único, abre no navegador) com as cores oficiais do LinkedIn.
+
+## Fluxo
+
+1. **Coletar entradas** (se faltar algo, peça — nunca invente dados)
+2. **Ensinar a exportar do LinkedIn** (se o usuário ainda não tem os arquivos)
+3. **PARTE 1 — Análise** (notas, diagnósticos, reescritas)
+4. **PARTE 2 — Dashboard HTML** (arquivo salvo em disco)
+5. **Entregar** (resumo no chat + caminho do arquivo)
+
+## Passo 1: Coletar entradas
+
+Peça, em uma única mensagem clara:
+
+- **Objetivo no LinkedIn** — se o usuário não declarou, pergunte com exemplos: autoridade em IA, parcerias, clientes, emprego.
+- **Dados do perfil em qualquer formato** — texto colado, currículo exportado (PDF), arquivo, print ou URL. Se vier um PDF, extraia o texto antes de analisar. Se vier imagem, descreva o que conseguir ler.
+- **Foto de perfil e capa (opcional, mas sempre pedir)** — arquivos ou URLs. Sem elas o dashboard funciona, mas fica mais fraco.
+- **Número de seguidores** — se estiver nos dados, use; senão pergunte ou omita.
+
+Regras de entrada: nunca invente conquistas, números ou fatos que não estejam nos dados. Toda reescrita deve manter o tom e o contexto real do usuário.
+
+## Passo 2: Como exportar do LinkedIn (instruções para o usuário)
+
+Se o usuário não sabe como obter os arquivos, passe estas instruções:
+
+**Currículo exportado (mais rápido):** no perfil do LinkedIn, clique em "Mais..." → "Salvar em PDF". Isso baixa o currículo completo em PDF.
+
+**Exportação completa de dados:** clique em "Eu" → "Configurações e privacidade" → "Privacidade de dados" → "Obter uma cópia dos seus dados" → selecione ao menos "Perfil" (e "Conta" se quiser conexões) → "Solicitar arquivo". O LinkedIn envia um ZIP por e-mail; extraia e use o conteúdo da pasta.
+
+**Foto de perfil e capa:** clique na foto ou capa para ampliar → clique com o botão direito → "Salvar imagem como...". Prefira o arquivo original em vez de print.
+
+## Passo 3: PARTE 1 — Análise
+
+Avalie as 8 seções abaixo, cada uma com:
+
+- **Nota de 0 a 10** (inteira ou com meio ponto)
+- **Diagnóstico direto em 2 linhas** — o problema concreto, sem rodeios
+- **Reescrita sugerida quando a nota for abaixo de 7** — mantendo o tom e o contexto real do usuário, sem inventar fatos
+
+Seções e critérios (calibre tudo para o objetivo declarado):
+
+1. **Foto & Banner** — qualidade da imagem, presença de rosto, coerência visual, se o banner comunica o posicionamento
+2. **Headline** — clareza do posicionamento, keywords do objetivo, público-alvo reconhecível
+3. **About/Resumo** — narrativa com começo/meio/fim, keywords, prova ou resultados, chamada à ação
+4. **Experiências** — impacto e resultados quantificados, descrição orientada a resultados, keywords
+5. **Skills** — relevância ao objetivo, ordem das mais importantes, cobertura
+6. **Recomendações** — quantidade, qualidade e diversidade de autores
+7. **URL** — personalizada, limpa, fácil de citar, presente no perfil
+8. **Atividade** — frequência e qualidade dos posts, consistência, engajamento
+
+Score geral: média ponderada — peso 2 para as seções mais críticas ao objetivo (emprego → Experiências e Atividade; autoridade → Atividade e About; clientes/parcerias → Headline e About) e peso 1 para as demais. Arredonde para uma casa decimal e feche com um veredito em uma frase.
+
+Formato do relatório no chat: uma seção por bloco (nota, diagnóstico, reescrita quando aplicável), depois o score geral e as 3 prioridades mais urgentes.
+
+## Passo 4: PARTE 2 — Dashboard HTML
+
+Leia `references/dashboard-spec.md` e gere o arquivo HTML completo seguindo exatamente aquela especificação (cores, fontes, estrutura, radar chart, ano dinâmico). Salve o arquivo como `linkedin-dashboard.html` no diretório de trabalho atual (ou pergunte onde salvar) e confirme o caminho absoluto no chat. Se o usuário forneceu foto ou capa, converta para base64 e embuta no HTML para o arquivo ficar autocontido.
+
+## Passo 5: Entregar
+
+No chat, em português:
+
+- Score geral e veredito em uma frase
+- As 3 prioridades mais urgentes
+- Caminho absoluto do arquivo HTML e como abrir (duplo clique ou `open <caminho>`)
+
+## Exemplos
+
+### Exemplo 1: usuário cola o resumo e pede avaliação
+
+Usuário: "avalia meu LinkedIn, meu objetivo é autoridade em IA" + texto do resumo colado.
+Ações: pedir foto/capa e seguidores (se faltarem) → analisar as 8 seções com notas → gerar o dashboard.
+Resultado: relatório com notas no chat + `linkedin-dashboard.html` salvo.
+
+### Exemplo 2: usuário envia só o PDF do currículo
+
+Usuário: "meu objetivo é emprego, aqui está meu currículo exportado" + PDF.
+Ações: extrair o texto do PDF → analisar com o que existe e anotar as lacunas → gerar o dashboard.
+Resultado: análise honesta sobre os dados disponíveis, sem inventar.
+
+## Troubleshooting
+
+- **Usuário não informou o objetivo:** pergunte antes de analisar — a calibração muda notas e prioridades.
+- **Dados insuficientes (ex: sem experiências, sem atividade):** pontue com base no que existe, marque a seção como "sem dados" quando não der para avaliar e diga o que pedir.
+- **Só tem o PDF do currículo:** o PDF não traz foto, capa, URL personalizada nem atividade — avalie o que der e indique o que falta.
+- **Radar chart não aparece:** confirme que o canvas tem altura definida no CSS e que o JS roda depois do DOM (script no fim do body ou DOMContentLoaded).
+- **Fotos não abrem no navegador:** use base64 embutido em vez de caminho relativo — arquivo HTML local não carrega caminhos arbitrários de forma confiável.

package/skills/linkedin-audit/references/dashboard-spec.md

@@ -0,0 +1,43 @@
+# Especificação do dashboard HTML do LinkedIn Audit
+
+Gere UM arquivo HTML completo, standalone: CSS e JS inline, sem bibliotecas externas. Única exceção: fontes Google (Inter + DM Mono). O arquivo deve abrir direto no navegador via `file://` sem erros.
+
+## Paleta (usar exatamente estes valores)
+
+- Azul principal: `#0A66C2`
+- Azul escuro: `#004182`
+- Fundo claro: `#F3F2EF`
+- Superfície branca: `#FFFFFF`
+- Texto principal: `#1C1C1C`
+- Texto secundário: `#666666`
+- Verde (notas ≥ 8): `#057642`
+- Amarelo (notas 5–7): `#E8A400`
+- Vermelho (notas < 5): `#CC1016`
+
+Faixas de cor da nota na lógica JS: `nota >= 8 ? verde : nota >= 5 ? amarelo : vermelho`.
+
+## Fontes
+
+Google Fonts: `Inter` (texto) + `DM Mono` (números, notas e destaques). Inclua o `<link>` no head com fallback `sans-serif` / `monospace`.
+
+## Estrutura obrigatória
+
+1. **Header** — nome do usuário, objetivo declarado e número de seguidores; foto de perfil quando fornecida (embutida em base64, redonda); o ano atual gerado dinamicamente com `new Date().getFullYear()` — NUNCA ano fixo no código.
+2. **Banner de score geral** — nota em um círculo (cor conforme a faixa) e veredito em uma frase.
+3. **Grid de cards, um por seção (8)** — cada card com:
+   - Nome da seção + ícone emoji
+   - Nota colorida conforme a faixa
+   - Barra de progresso animada na cor correspondente (anima de 0 até a nota ao carregar, via CSS transition ou animação JS)
+   - Diagnóstico curto
+   - Box "Reescrita sugerida" com borda esquerda azul `#0A66C2` — SOMENTE quando a nota < 7
+4. **Radar chart (canvas)** — com as 8 dimensões, desenhado em JS puro (sem bibliotecas): eixos, grades, polígono preenchido com leve transparência, rótulos das dimensões e valores das notas. O canvas precisa de altura definida (ex: 320–380px) para renderizar.
+5. **Footer** — as 3 prioridades mais urgentes em destaque.
+
+## Regras de implementação
+
+- Título da aba: `LinkedIn Audit — <nome>`.
+- Layout responsivo: grid com `auto-fit minmax(280px, 1fr)` ou equivalente; header empilha em telas estreitas.
+- Radar chart: normalizar notas para o raio (0–10 → 0–100%); desenhar com `Math.cos`/`Math.sin`; fundo `#FFFFFF`, grade e texto em `#666666`, polígono em `#0A66C2` com preenchimento `rgba(10,102,194,0.25)`.
+- Imagens (foto de perfil, capa): base64 embutido; sem imagens, omitir o elemento sem quebrar o layout.
+- Não usar ano fixo em lugar nenhum do HTML/JS.
+- Todo o conteúdo (nomes, notas, diagnósticos, reescritas, prioridades) vem da análise do Passo 3 da SKILL.md — nunca gere conteúdo aleatório ou inventado.

package/skills/memory-management/README.md

@@ -0,0 +1,13 @@
+# memory-management
+
+Lightweight agent memory for non-Guild projects. Maintains project decisions and error patterns in a flat `.agent-memory/` directory.
+
+| Field | Value |
+|-------|-------|
+| Version | 1.0.0 |
+| Trigger | `/memory`, "agent memory", "project memory", "remember this", "record decision", "capture learning" |
+| PT trigger | `/memória`, "memória do agente", "memória do projeto", "lembrar disso", "registrar decisão", "capturar aprendizado" |
+
+**Do not use for** Guild projects (use guild-commit-learning), large knowledge bases, or replacing a proper wiki.
+
+See [SKILL.md](SKILL.md) for the full process.

package/skills/memory-management/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: memory-management
+description: >
+  Lightweight agent memory for non-Guild projects. Maintains project decisions
+  and error patterns in a flat .agent-memory/ directory so future sessions
+  can learn from past work.
+  EN triggers: /memory, agent memory, project memory, remember this, record decision, capture learning.
+  PT triggers: /memória, memória do agente, memória do projeto, lembrar disso, registrar decisão, capturar aprendizado.
+  Do NOT use for: Guild projects (use guild-commit-learning), large knowledge bases, or replacing a proper wiki.
+license: CC-BY-4.0
+---
+
+# memory-management
+
+Lightweight agent memory for non-Guild projects. Maintains project decisions and error patterns in a flat `.agent-memory/` directory.
+
+```
+DECIDE → SELECT FILE → FORMAT ENTRY → WRITE → VERIFY
+```
+
+---
+
+## Overview
+
+This skill maintains two flat files in `.agent-memory/` so AI agents can persist learnings across sessions. It is intentionally simpler than Guild's `guild-commit-learning` — designed for solo developers and small teams that do not run the full Guild orchestration system.
+
+No archive subfolder, no promotion rules, no index maintenance. Two files, one directory, one format.
+
+---
+
+## Directory Structure
+
+```
+.agent-memory/
+├── project_decisions.md    # Architectural decisions, conventions, rationale
+└── error_patterns.md       # Bugs encountered, root causes, fixes applied
+```
+
+Create the directory and both files on first use. Do not create any subdirectories or additional files.
+
+---
+
+## When to Use
+
+Write to `.agent-memory/` when:
+
+- A feature is complete and the decisions behind it are not obvious from code
+- A tricky bug was fixed and the root-cause discovery is worth preserving
+- An architectural choice was made (library selection, pattern adoption, API design)
+- A convention was established that future sessions should follow
+- You want the next agent session to know what you learned
+
+Do not write when:
+
+- The change is trivial and self-evident from the code
+- The information duplicates what is already in ADRs, README, or docs
+- You are on a Guild project (use `guild-commit-learning` instead)
+
+---
+
+## Process
+
+### Step 1: Decide
+
+Ask: Is this worth remembering?
+
+- Does it have cross-session value?
+- Is it not obvious from reading the code?
+- Would knowing this save future time?
+
+If the answer to all three is yes, proceed.
+
+### Step 2: Select the Right File
+
+| If the entry is about... | Write to... |
+|--------------------------|-------------|
+| Architectural decisions, library choices, pattern adoption, API design, conventions, rationale for a technical choice | `project_decisions.md` |
+| Bugs encountered, root causes, fixes applied, symptoms, how to prevent recurrence | `error_patterns.md` |
+
+When in doubt, prefer `project_decisions.md` for anything structural and `error_patterns.md` for anything reactive (discovered through failure).
+
+### Step 3: Format the Entry
+
+Use one consistent format for both files. Append new entries at the top so the most recent learning appears first.
+
+```markdown
+## [Title] (YYYY-MM-DD)
+
+**Context**: [what was happening — the situation, the task, the system state]
+
+**Decision/Discovery**: [what was decided or found — the thing worth remembering]
+
+**Rationale**: [why this matters — alternatives considered, future impact, prevention]
+```
+
+Rules for good entries:
+
+- **Title** is specific and searchable. Prefer "Why the auth service uses RS256 instead of HS256" over "Auth decision".
+- **Context** gives enough background to understand the entry without reading the full codebase.
+- **Decision/Discovery** states the conclusion clearly. One entry = one idea.
+- **Rationale** explains the why. An entry without rationale is just a fact; with rationale it is a lesson.
+- **No secrets.** Never capture API keys, tokens, passwords, or internal URLs.
+
+### Step 4: Write
+
+Read the target file first. Append the new entry at the top, leaving one blank line before the previous entry.
+
+```bash
+# Create directory and files if they do not exist
+mkdir -p .agent-memory
+[ ! -f .agent-memory/project_decisions.md ] && echo "# Project Decisions\n" > .agent-memory/project_decisions.md
+[ ! -f .agent-memory/error_patterns.md ] && echo "# Error Patterns\n" > .agent-memory/error_patterns.md
+```
+
+### Step 5: Keep It Current
+
+When re-reading entries for context:
+
+- **Update** entries that have changed (e.g., a decision was revisited and reversed). Add a note like *(Updated: YYYY-MM-DD)* and describe what changed.
+- **Remove** entries that are no longer relevant (e.g., a bug fixed by a library upgrade).
+- **Merge** entries that cover the same topic. Prefer one good entry over two partial ones.
+
+---
+
+## Example Entries
+
+### project_decisions.md
+
+```markdown
+## Adopted Zod v4 for runtime validation (2026-07-15)
+
+**Context**: Evaluating validation libraries for the new API layer. Needed runtime type checking with TypeScript inference.
+
+**Decision/Discovery**: Chose Zod v4 over Yup and io-ts. Zod's TypeScript integration is tighter, the API is simpler, and v4 adds string formats and better error messages.
+
+**Rationale**: Yup has more plugins but weaker TypeScript inference. io-ts is powerful but harder to teach. Zod v4 strikes the right balance for a team that values type safety but not functional programming purity.
+```
+
+```markdown
+## REST over GraphQL for internal services (2026-07-10)
+
+**Context**: Designing inter-service communication for the new orders platform.
+
+**Decision/Discovery**: REST with OpenAPI schemas, not GraphQL. Internal services need simple request/response contracts; GraphQL adds query complexity without benefit for machine-to-machine calls.
+
+**Rationale**: GraphQL excels when a single client needs flexible data shapes. Our internal consumers are other services with fixed needs. REST + OpenAPI gives us contract generation and simpler caching.
+```
+
+### error_patterns.md
+
+```markdown
+## SQLite "database is locked" under concurrent writes (2026-07-16)
+
+**Context**: Integration tests started failing with SQLITE_BUSY after adding parallel test workers.
+
+**Decision/Discovery**: Root cause was multiple workers opening write transactions on the same SQLite file. SQLite serializes writes — concurrent writers get "database is locked".
+
+**Rationale**: Fix was setting `busyTimeout` to 5000ms and adding `WAL` journal mode. For future: if write concurrency grows, switch to a client-server database. SQLite is fine for reads but serializes writes by design.
+```
+
+```markdown
+## Environment variable leak in CI logs (2026-07-14)
+
+**Context**: CI logs were printing full environment variables when a build script failed, exposing DATABASE_URL and API keys.
+
+**Decision/Discovery**: The build script used `console.log(process.env)` in its error handler. Secrets appeared in plaintext in the CI job output.
+
+**Rationale**: Removed the full env dump. Replaced with a filtered log that redacts values matching known secret key patterns. Added a pre-commit hook that scans for `process.env` in logging statements.
+```
+
+---
+
+## Verification
+
+After writing to `.agent-memory/`:
+
+- [ ] Both `.agent-memory/project_decisions.md` and `.agent-memory/error_patterns.md` exist
+- [ ] New entry is at the top of the correct file
+- [ ] Entry has a dated title, Context, Decision/Discovery, and Rationale sections
+- [ ] Entry has enough context to be useful standalone — a new session can understand it without reading the full codebase
+- [ ] No secrets, tokens, passwords, or internal URLs captured
+- [ ] Entry does not duplicate information already in ADRs, README, or docs
+
+---
+
+## When Not to Use This Skill
+
+- **Guild projects.** Use `guild-commit-learning` instead — it integrates with Guild's orchestration, analytics, and knowledge graph.
+- **Large knowledge bases.** Two flat files do not scale to team-wide knowledge management. When you outgrow this, consider a wiki, Notion, or Guild.
+- **Replacing proper documentation.** `.agent-memory/` complements ADRs and READMEs — it does not replace them. Decisions that affect the team or public API still belong in ADRs.
+
+---
+
+## See Also
+
+- `guild-commit-learning` — Full Guild-integrated memory system with archive, promotion rules, and index maintenance
+- `spec-driven` — Feature workflow that produces specs worth recording as decisions
+- `code-review-and-quality` — Reviews that surface bugs worth capturing in `error_patterns.md`

package/skills/security-and-hardening/README.md

@@ -0,0 +1,13 @@
+# security-and-hardening
+
+Harden code against vulnerabilities with the OWASP Top 10 and a three-tier boundary system (input, processing, output).
+
+| Field | Value |
+|-------|-------|
+| Version | 1.1.0 |
+| Trigger | `/security`, "security audit", "OWASP", "three-tier boundary", "least privilege" |
+| PT trigger | `/segurança`, "auditoria de segurança", "privilégio mínimo" |
+
+**Do not use for** non-security performance work (use `/review`'s performance axis) or dependency updates with no security exposure.
+
+See [SKILL.md](SKILL.md) for the full process.