javi-forge 1.2.0 → 1.4.0

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

@@ -1,199 +0,0 @@
----
-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

@@ -1,100 +0,0 @@
----
-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

@@ -1,73 +0,0 @@
----
-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

@@ -1,178 +0,0 @@
----
-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/dist/commands/analyze.test.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=analyze.test.d.ts.map

package/dist/commands/doctor.test.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=doctor.test.d.ts.map

package/dist/commands/init.test.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=init.test.d.ts.map

package/dist/commands/llmstxt.test.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=llmstxt.test.d.ts.map

package/dist/commands/plugin.test.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=plugin.test.d.ts.map

package/dist/commands/sync.d.ts

@@ -1,8 +0,0 @@
-import type { SyncOptions, InitStep } from '../types/index.js';
-type StepCallback = (step: InitStep) => void;
-/**
- * Sync AI config to a project directory, generating CLI-specific config files.
- */
-export declare function syncAIConfig(options: SyncOptions, onStep: StepCallback): Promise<void>;
-export {};
-//# sourceMappingURL=sync.d.ts.map