# Skill Registry — sig-cm2
Generated: 2026-04-13

## User Skills

| Skill | Trigger |
|-------|---------|
| `sdd-init` | User says "sdd init", "iniciar sdd", "openspec init" |
| `sdd-explore` | Orchestrator launches exploration of a feature or codebase area |
| `sdd-propose` | Orchestrator launches proposal for a change |
| `sdd-spec` | Orchestrator launches spec writing for a change |
| `sdd-design` | Orchestrator launches technical design for a change |
| `sdd-tasks` | Orchestrator launches task breakdown for a change |
| `sdd-apply` | Orchestrator launches implementation of tasks |
| `sdd-verify` | Orchestrator launches verification of a completed change |
| `sdd-archive` | Orchestrator launches archival of a completed change |
| `sdd-onboard` | User wants a guided SDD walkthrough |
| `judgment-day` | User says "judgment day", "review adversarial", "doble review", "juzgar" |
| `go-testing` | Writing Go tests, using teatest, Bubbletea TUI testing |
| `skill-creator` | Creating a new AI agent skill |
| `branch-pr` | Creating a pull request, preparing changes for review |
| `issue-creation` | Creating a GitHub issue, bug report, or feature request |
| `skill-registry` | Update skill registry, "actualizar skills" |
| `obsidian-cli` | Interact with Obsidian vault via CLI |
| `obsidian-markdown` | Creating/editing Obsidian Flavored Markdown (.md files in vault) |
| `gitea-workflow` | Agile workflow for Gitea repos, "run the workflow", "what's next" |
| `find-skills` | "Find a skill for X", "how do I do X", discover capabilities |

## Project Conventions

| File | Role |
|------|------|
| `Obsidian/SPEC.md` | Source of truth — visión, módulos, tech stack |
| `Obsidian/STATUS.md` | Estado de UDTs — ÚNICO lugar para marcar tareas `[x]` |
| `Obsidian/INSTRUCCIONES_IA.md` | SOP del agente: bucle de ejecución, reglas de lectura |
| `Obsidian/02-ARQUITECTURA-y-TECH-STACK/` | UDTs por módulo con CMV (Contexto Mínimo Viable) |
| `Obsidian/04-DOMINIO-y-REGLAS-de-NEGOCIO/` | Reglas de negocio — consultar ante dudas |

## Compact Rules

### SIG-CM2 Development Rules
- Orden de implementación SIEMPRE: BD → Backend → Frontend
- Rama por UDT: `feature/UDT-XXX` (o VTA-XXX, TAS-XXX, INT-XXX, ADM-XXX)
- Commits: `tipo(módulo): descripción` — feat/fix/docs/refactor/test/chore/security
- NUNCA leer `Obsidian/07-RELEVAMIENTOS/` sin instrucción humana explícita
- Para dudas de negocio: consultar `04-DOMINIO-y-REGLAS-de-NEGOCIO/` o `SPEC.md`
- Antes de cada UDT: leer STATUS.md → leer UDT en carpeta 02 → cargar solo el CMV indicado

### Architecture
- Clean Architecture: SIGCM2.Api / SIGCM2.Application / SIGCM2.Domain / SIGCM2.Infrastructure
- Backend ORM: Dapper 2.x (NO Entity Framework — decisión arquitectural)
- Lógica crítica de negocio: Stored Procedures en SQL Server
- Frontend state: Zustand (global) + TanStack Query (server state)
- Frontend estructura: src/api, src/components/{ui,features}, src/features/*, src/hooks, src/layouts, src/pages, src/stores, src/utils

### Strict TDD Mode (ACTIVE)
- Tests ANTES del código de producción (Red → Green → Refactor)
- Backend: xUnit + NSubstitute — comando: `dotnet test`
- Frontend: Vitest + React Testing Library — comando: `vitest`
- Coverage backend: `dotnet test --collect:"XPlat Code Coverage"`
- Coverage frontend: `vitest --coverage`