javi-forge 0.1.0

package/ai-config/skills/workflow/obsidian-brain-workflow/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: obsidian-brain-workflow
+description: >
+  Guide for working with Obsidian Brain project memory: Kanban board, Dataview inline fields,
+  Templater templates, and wave integration.
+  Trigger: obsidian brain, kanban board, project memory, dataview, session tracking
+tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+metadata:
+  author: project-starter-framework
+  version: "1.0"
+  tags: [workflow, obsidian, kanban, dataview, memory, sessions]
+  updated: "2026-02"
+---
+
+# Obsidian Brain Workflow
+
+Manage project memory using Obsidian-compatible markdown with Kanban, Dataview, and Templater.
+
+## Session Start Checklist
+
+At the beginning of every session:
+
+1. **Read CONTEXT.md** - Current project state
+   ```bash
+   cat .project/Memory/CONTEXT.md
+   ```
+
+2. **Check KANBAN.md** - Active tasks and their lanes
+   ```bash
+   cat .project/Memory/KANBAN.md
+   ```
+
+3. **Review BLOCKERS.md** - Any open blockers
+   ```bash
+   grep "status:: open" .project/Memory/BLOCKERS.md
+   ```
+
+4. **Create session file** - Copy template or use Templater
+   ```bash
+   cp .project/Sessions/TEMPLATE.md .project/Sessions/$(date +%Y-%m-%d).md
+   ```
+
+## KANBAN.md Format
+
+The Kanban board uses Obsidian Kanban plugin format. Each lane is an H2 heading, each task is a checkbox item.
+
+```markdown
+---
+kanban-plugin: board
+---
+
+## Backlog
+- [ ] T-001 Setup monorepo #wave
+- [ ] T-005 Add monitoring
+
+## En Progreso
+- [ ] T-002 Configure CI #wave
+
+## Review
+- [ ] T-003 Add linters #wave
+
+## Completado
+- [x] T-000 Init project
+
+**Complete**
+```
+
+### Moving Tasks Between Lanes
+
+**Without Obsidian (AI CLI or manual edit):**
+- Cut the `- [ ]` line from one H2 section
+- Paste it under the target H2 section
+- When completing: change `- [ ]` to `- [x]`
+
+**With Obsidian:**
+- Drag and drop cards between lanes
+
+### Tags
+
+- `#wave` - Part of current wave
+- `#blocker` - Has an associated blocker
+- `#review` - Needs review
+
+## Dataview Inline Fields
+
+Memory files use Dataview inline fields for automatic queries. Format: `key:: value`
+
+### Required Fields Reference
+
+| File | Required Fields | Notes |
+|------|----------------|-------|
+| DECISIONS.md (ADRs) | `type:: adr`, `status::`, `date::` | Without these, DASHBOARD queries return empty |
+| BLOCKERS.md | `type:: blocker`, `status::`, `impact::`, `date::` | `impact` values: `alto`, `medio`, `bajo` |
+| Sessions/*.md | frontmatter `type: session`, `date`, `phase`, `wave` | Use YAML frontmatter, not inline fields |
+
+### ADR Fields (DECISIONS.md)
+
+```markdown
+## ADR-002: Use PostgreSQL
+
+type:: adr
+status:: aceptada
+date:: 2026-01-15
+```
+
+### Blocker Fields (BLOCKERS.md)
+
+```markdown
+### BLOCKER-003: Docker build fails
+
+type:: blocker
+status:: open
+impact:: alto
+date:: 2026-01-20
+```
+
+### Valid Status Values
+
+| File | Valid Statuses |
+|------|---------------|
+| ADRs | `pendiente`, `aceptada`, `rechazada`, `deprecada` |
+| Blockers | `open`, `investigating`, `resolved`, `workaround` |
+
+### Resolving a Blocker
+
+When resolving, update both the inline field and the content:
+
+```markdown
+### BLOCKER-003: Docker build fails
+
+type:: blocker
+status:: resolved
+impact:: alto
+date:: 2026-01-20
+
+**Solucion:**
+Changed base image from alpine to debian-slim.
+```
+
+## Wave + Kanban Integration
+
+KANBAN.md is for day-to-day task tracking. WAVES.md is the historical record.
+
+### Creating a Wave
+
+1. Add tasks to KANBAN.md Backlog with `#wave` tag
+2. Run `./scripts/new-wave.sh "T-001 T-002 T-003"`
+3. Move tagged tasks to "En Progreso" in KANBAN.md
+
+### Completing a Wave
+
+1. Move all wave tasks to "Completado" in KANBAN.md
+2. Run `./scripts/new-wave.sh --complete`
+3. Remove `#wave` tags from completed tasks
+
+## Templates
+
+### Manual (without Templater)
+
+Copy the template file and fill in placeholders:
+
+```bash
+# New session
+cp .project/Sessions/TEMPLATE.md .project/Sessions/2026-01-15.md
+
+# New ADR - append to DECISIONS.md using the template at the bottom
+# New Blocker - append to BLOCKERS.md using the template at the bottom
+```
+
+### With Templater (Obsidian)
+
+Use Ctrl+T (or Cmd+T) to insert templates that auto-fill dates and prompt for values:
+
+- `Session.md` - Creates session with current date, prompts for phase/wave/branch
+- `ADR.md` - Creates ADR entry, prompts for number/title/context/decision
+- `Blocker.md` - Creates blocker entry, prompts for number/title/impact
+
+## Session End Checklist
+
+At the end of every session:
+
+1. **Update CONTEXT.md** - Reflect current state
+2. **Update KANBAN.md** - Move tasks to correct lanes
+3. **Complete session file** - Fill summary section
+4. **Record blockers** - If any new ones appeared
+5. **Record decisions** - If any ADRs were made
+
+## Dashboard
+
+DASHBOARD.md contains Dataview queries that auto-update in Obsidian:
+- Recent decisions
+- Active blockers
+- Recent sessions
+
+Without Obsidian, it shows as code blocks (read-only reference).

package/ai-config/skills/workflow/using-git-worktrees/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: using-git-worktrees
+description: >
+  Gestiona múltiples branches en paralelo con Git worktrees para mantener contextos separados.
+  Trigger: worktree, trabajo en paralelo, hotfix mientras desarrollás, múltiples branches simultáneos
+tools:
+  - Bash
+  - Read
+metadata:
+  author: project-starter-framework
+  version: "1.0"
+  tags: [git, workflow, branches, parallel]
+  updated: "2026-02"
+---
+
+# Git Worktrees Skill
+
+## ¿Qué son los Worktrees?
+
+Git worktrees permiten tener múltiples branches del mismo repositorio checked out simultáneamente en directorios separados. Ideal para:
+
+- Hacer un hotfix urgente sin perder el trabajo en progreso
+- Revisar otro branch sin stashing
+- Correr tests de dos versiones en paralelo
+
+## Comandos Esenciales
+
+```bash
+# Ver worktrees actuales
+git worktree list
+
+# Crear worktree para branch existente
+git worktree add ../proyecto-hotfix hotfix/critical-bug
+
+# Crear worktree con nuevo branch desde main
+git worktree add -b feature/nueva ../proyecto-nueva main
+
+# Eliminar worktree
+git worktree remove ../proyecto-hotfix
+
+# Limpiar referencias huérfanas
+git worktree prune
+```
+
+## Flujo de Trabajo
+
+### Hotfix Urgente Durante Feature Development
+
+```bash
+# Situación: trabajando en feature/dashboard, llega bug urgente
+
+# 1. Crear worktree para el hotfix (sin afectar tu trabajo)
+git worktree add ../mi-proyecto-hotfix -b hotfix/login-crash main
+
+# 2. Ir al worktree del hotfix
+cd ../mi-proyecto-hotfix
+
+# 3. Hacer el fix, testear, commitear
+git commit -m "fix(auth): prevent crash on empty session"
+git push origin hotfix/login-crash
+
+# 4. Volver a tu feature
+cd ../mi-proyecto
+
+# 5. Limpiar después del merge
+git worktree remove ../mi-proyecto-hotfix
+```
+
+### Comparar Implementaciones
+
+```bash
+# Tener la versión actual y la refactorizada corriendo en paralelo
+git worktree add ../proyecto-v2 refactor/new-arch
+
+# Terminal 1: cd ../mi-proyecto && go run . -port 8080
+# Terminal 2: cd ../proyecto-v2 && go run . -port 8081
+# Comparar comportamiento
+```
+
+## Convenciones de Naming
+
+Usar directorios hermanos al repo principal:
+
+```
+~/projects/
+  mi-proyecto/          # repo principal
+  mi-proyecto-hotfix/   # worktree hotfix
+  mi-proyecto-review/   # worktree para revisar PR
+```
+
+## Limitaciones
+
+- No podés hacer checkout del mismo branch en dos worktrees
+- Los stashes son compartidos (cuidado al usar `git stash`)
+- Algunos IDEs no detectan múltiples worktrees automáticamente
+
+## Related Skills
+
+- git-github
+- git-workflow

package/ai-config/skills/workflow/verification-before-completion/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: verification-before-completion
+description: >
+  Ejecuta un checklist de verificación estándar antes de marcar una tarea como completa.
+  Trigger: antes de terminar, marcar como done, cerrar tarea, completar feature, verification checklist
+tools:
+  - Bash
+  - Read
+metadata:
+  author: project-starter-framework
+  version: "1.0"
+  tags: [workflow, quality, checklist, done]
+  updated: "2026-02"
+---
+
+# Verification Before Completion Skill
+
+## Propósito
+
+Antes de declarar una tarea como completa, ejecutar un checklist sistemático para garantizar calidad y evitar regresiones.
+
+## Checklist Universal
+
+### 1. Tests
+- [ ] Los tests unitarios pasan: `npm test` / `go test ./...` / `pytest`
+- [ ] Los tests de integración pasan (si existen)
+- [ ] No hay tests nuevos saltados o deshabilitados sin justificación
+- [ ] La cobertura no decreció significativamente
+
+### 2. Código
+- [ ] El linter no reporta errores nuevos
+- [ ] No hay `console.log`, `print()` o `fmt.Println` de debug sin remover
+- [ ] No hay código comentado innecesario (está en git history)
+- [ ] No hay TODOs sin resolver relacionados a esta tarea
+
+### 3. Git
+- [ ] Los cambios están en el branch correcto
+- [ ] El branch está actualizado con el base branch (`git pull --rebase origin main`)
+- [ ] No hay archivos staged innecesarios (`.env`, archivos generados)
+- [ ] Los mensajes de commit siguen Conventional Commits
+
+### 4. Funcionalidad
+- [ ] La feature funciona en el happy path
+- [ ] Los edge cases identificados están manejados
+- [ ] El error handling es apropiado
+- [ ] El comportamiento es consistent con los requerimientos
+
+### 5. Documentación
+- [ ] El README está actualizado si cambiaron instrucciones de setup
+- [ ] Los cambios de API están documentados
+- [ ] Los comentarios en código son correctos y útiles
+
+## Comandos de Verificación Rápida
+
+```bash
+# Verificación completa en un solo bloque
+git status && \
+git diff --stat origin/main...HEAD && \
+go test ./... 2>&1 | tail -5 && \
+echo "=== VERIFICATION COMPLETE ==="
+```
+
+## Cuándo NO completar
+
+- Si algún item del checklist falla → resolverlo primero
+- Si hay dudas sobre el comportamiento → consultar antes de marcar done
+- Si hay deuda técnica significativa introducida → crear issue para tracking
+
+## Related Skills
+
+- git-github
+- git-workflow
+- finishing-a-development-branch

package/ai-config/skills/workflow/wave-workflow/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: wave-workflow
+description: >
+  Guide for executing parallel task waves using VibeKanban integration.
+  Trigger: parallel execution, task waves, oleadas, multiple tasks, wave planning
+tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+metadata:
+  author: project-starter-framework
+  version: "2.0"
+  tags: [workflow, parallel, vibekanban, tasks, oleadas]
+  updated: "2026-02"
+---
+
+# Wave Workflow (Oleadas)
+
+Execute tasks in parallel waves based on dependency analysis.
+
+## Concept
+
+```
+Oleada 1: [T-001] [T-002] [T-003]  ← No dependencies, run in parallel
+              ↓ merge all → develop
+Oleada 2: [T-004] [T-005]          ← Depend on Oleada 1
+              ↓ merge all → develop
+Release: develop → main
+```
+
+## Quick Commands
+
+```bash
+# View current wave status
+./scripts/new-wave.sh --list
+
+# Create new wave with tasks
+./scripts/new-wave.sh "T-001 T-002 T-003"
+
+# Create branches for all tasks
+./scripts/new-wave.sh --create-branches
+
+# Mark wave as complete
+./scripts/new-wave.sh --complete
+```
+
+## Workflow Steps
+
+### 1. Analyze Dependencies
+Before creating a wave, identify which tasks can run in parallel:
+- Tasks with NO dependencies on each other → Same wave
+- Tasks that depend on others → Next wave
+
+### 2. Create Wave
+```bash
+./scripts/new-wave.sh "T-001 T-002 T-003"
+```
+
+This:
+- Creates entry in `.project/Memory/WAVES.md`
+- Records start timestamp
+- Sets wave status to "in-progress"
+
+### 3. Create Branches
+```bash
+./scripts/new-wave.sh --create-branches
+```
+
+Creates:
+- `feature/t-001-description`
+- `feature/t-002-description`
+- `feature/t-003-description`
+
+### 4. Work on Tasks (Parallel)
+Each task can be worked on independently:
+
+```bash
+# Terminal 1
+git checkout feature/t-001
+# ... work ...
+git commit -m "feat(scope): implement T-001"
+git push
+
+# Terminal 2
+git checkout feature/t-002
+# ... work ...
+git commit -m "feat(scope): implement T-002"
+git push
+```
+
+### 5. Create PRs
+For each task, create PR to `develop`:
+```bash
+gh pr create --base develop --title "feat: T-001 description"
+```
+
+### 6. Merge Wave
+Once ALL tasks in wave are complete and PRs approved:
+```bash
+# Merge all PRs to develop
+gh pr merge <pr-number> --merge
+```
+
+### 7. Complete Wave
+```bash
+./scripts/new-wave.sh --complete
+```
+
+This:
+- Updates `.project/Memory/WAVES.md`
+- Records completion timestamp
+- Deletes merged branches (optional)
+
+### 8. Next Wave
+Repeat for the next wave of tasks.
+
+## Best Practices
+
+### Dependency Analysis
+- Draw a simple dependency graph
+- Group independent tasks
+- Never exceed ~15 parallel tasks (cognitive limit)
+
+### Branch Naming
+- `feature/t-xxx-short-description`
+- `fix/t-xxx-bug-description`
+- Keep descriptions short (max 3-4 words)
+
+### PR Strategy
+- One PR per task
+- Base all PRs on `develop`
+- Review in batches when possible
+
+### Merge Order
+- Merge in any order if truly independent
+- If hidden dependencies found, pause and re-analyze
+
+## Integration with VibeKanban
+
+Tasks come from VibeKanban:
+1. List tasks: `mcp__vibe_kanban__list_tasks`
+2. Get details: `mcp__vibe_kanban__get_task`
+3. Update status: `mcp__vibe_kanban__update_task`
+
+### Sync Workflow
+```
+VibeKanban (todo) → Wave created → Work → PR merged → VibeKanban (done)
+```
+
+## Example Session
+
+```bash
+# Morning: Analyze and plan
+./scripts/new-wave.sh --list
+
+# Create Oleada 3
+./scripts/new-wave.sh "T-010 T-011 T-012 T-013"
+
+# Create branches
+./scripts/new-wave.sh --create-branches
+
+# Work through the day...
+# Each dev takes 1-2 tasks
+
+# End of day: All merged
+./scripts/new-wave.sh --complete
+
+# Check what's next
+./scripts/new-wave.sh --list
+```
+
+## Memory Files
+
+Wave progress is tracked in:
+- `.project/Memory/WAVES.md` - All waves history
+- `.project/Memory/CONTEXT.md` - Current state summary
+- `.project/Memory/KANBAN.md` - Visual task board (Obsidian Brain)

package/ci-local/README.md

@@ -0,0 +1,170 @@
+# CI-Local: Universal CI Simulation
+
+Reproduce tu CI/CD localmente antes de push. Si pasa local → pasa en GitHub Actions/GitLab CI.
+
+## Stack Soportados (auto-detectados)
+
+| Stack | Build Tool | Lint | Test |
+|-------|------------|------|------|
+| Java | Gradle | spotlessCheck | ./gradlew test |
+| Java | Maven | spotless:check | ./mvnw test |
+| Node.js | npm/yarn/pnpm | lint | test |
+| Python | pip/poetry | ruff/pylint | pytest |
+| Go | go | golangci-lint | go test |
+| Rust | cargo | clippy | cargo test |
+
+## Instalación (30 segundos)
+
+### Copiar a un proyecto nuevo
+
+```bash
+# Copiar CI-Local y su dependencia lib/
+cp -r .ci-local /path/to/new-project/
+cp -r lib /path/to/new-project/
+
+# En el nuevo proyecto
+cd /path/to/new-project
+./.ci-local/install.sh      # Linux/Mac
+# o
+.\.ci-local\install.ps1     # Windows
+```
+
+> **Importante:** CI-Local depende de `lib/common.sh` (funciones compartidas). Copiar siempre ambos directorios.
+
+### Dependencias opcionales
+
+```bash
+# Semgrep (análisis de seguridad, muy recomendado)
+# Si Semgrep no está instalado localmente, CI-Local hace fallback automático
+# a una imagen Docker de Semgrep cuando Docker está disponible.
+pip install semgrep
+
+# Docker (requerido para CI simulation y fallback de Semgrep)
+# Instalar Docker Desktop
+```
+
+## Uso
+
+### Automático (hooks)
+
+```bash
+git commit -m "..."   # → pre-commit: AI check + lint + security (~30s)
+                      # → commit-msg: valida mensaje sin AI attribution
+git push              # → pre-push: CI completo en Docker (~3min)
+```
+
+### AI Attribution Blocker
+
+Los hooks bloquean automáticamente:
+- `Co-authored-by: Claude`, `Co-authored-by: GPT`, etc.
+- `Made by Claude`, `Generated by AI`, `Written by GPT`
+- Referencias a `@anthropic.com`, `@openai.com`
+- Nombres de modelos: `claude opus`, `gpt-4`, `chatgpt`, etc.
+
+**Tú eres el único autor de tu código.**
+
+### Manual
+
+```bash
+# Windows
+.\.ci-local\ci-local.ps1 quick    # Lint + compile
+.\.ci-local\ci-local.ps1 full     # CI completo
+.\.ci-local\ci-local.ps1 shell    # Shell en entorno CI
+.\.ci-local\ci-local.ps1 detect   # Ver stack detectado
+
+# Linux/Mac
+./.ci-local/ci-local.sh quick
+./.ci-local/ci-local.sh full
+./.ci-local/ci-local.sh shell
+./.ci-local/ci-local.sh detect
+```
+
+### Skipear hooks (emergencia)
+
+```bash
+git commit --no-verify
+git push --no-verify
+```
+
+## Como Funciona
+
+```
+Developer workflow:
+
+1. Editar codigo
+2. git add .
+3. git commit -m "feat: add feature"
+     |
+     pre-commit hook:
+     - [1/3] Verificar atribucion AI (BLOQUEADO si encuentra)
+     - [2/3] Scan de seguridad Semgrep (reglas locales)
+     - [3/3] Compile check rapido
+     |
+     commit-msg hook:
+     - Validar formato conventional commit
+     |
+4. git push
+     |
+     pre-push hook:
+     - Detectar stack (Java/Node/Python/Go/Rust)
+     - Generar Dockerfile para el stack
+     - Construir imagen Docker (con cache de hash)
+     - Ejecutar test suite completo en contenedor
+     |
+5. Push exitoso → CI remoto pasara
+```
+
+## Estructura
+
+```
+.ci-local/
+├── ci-local.ps1      # Script principal (Windows)
+├── ci-local.sh       # Script principal (Linux/Mac)
+├── install.ps1       # Instalador Windows
+├── install.sh        # Instalador Linux/Mac
+├── semgrep.yml       # Reglas de seguridad
+├── README.md         # Esta guía
+├── hooks/
+│   ├── pre-commit    # AI check + lint + security
+│   ├── commit-msg    # Valida mensaje sin AI attribution
+│   └── pre-push      # CI simulation en Docker
+└── docker/
+    └── *.Dockerfile  # Se generan automáticamente
+
+lib/                  # Dependencia requerida (copiar junto con .ci-local/)
+├── common.sh         # Funciones compartidas (Bash)
+└── Common.psm1       # Funciones compartidas (PowerShell)
+```
+
+## Personalización
+
+### Agregar reglas Semgrep específicas
+
+Editar `.ci-local/semgrep.yml` o crear `.semgrep.yml` en la raíz.
+
+### Cambiar comandos de lint/test
+
+Editar `lib/common.sh` (detección de stack) o `setup_ci_commands()` en `ci-local.sh` (comandos CI).
+
+### Docker image custom
+
+Editar los Dockerfiles en `.ci-local/docker/` después de la primera ejecución.
+
+## FAQ
+
+**¿Por qué falla en CI pero no en ci-local?**
+- Verifica que Docker esté corriendo con la misma imagen
+- Usa `ci-local.sh shell` para debug interactivo
+
+**¿Cómo acelerar el pre-push?**
+- Usa Docker image cache para evitar rebuilds innecesarios
+- Usa `--no-verify` si estás seguro (no recomendado)
+
+**¿Funciona sin Docker?**
+- Los hooks de pre-commit funcionan sin Docker
+- El pre-push requiere Docker para simular CI real
+
+**¿Qué pasa si Semgrep no está instalado?**
+- CI-Local detecta si Semgrep está disponible localmente
+- Si no está instalado pero Docker está corriendo, usa la imagen `semgrep/semgrep` como fallback automático
+- Si ni Semgrep ni Docker están disponibles, el scan de seguridad se omite con advertencia