Communitygithub.com

lguidolin/registro-decisiones

Úsalo cuando se haya tomado una decisión de diseño o arquitectura que deba capturarse: escribir un registro de decisión o ADR, actualizar un índice de decisiones, anotar una idea aplazada o reemplazar una decisión anterior. Palabras clave: ADR, registro de decisión, justificación, alternativas rechazadas, índice de dependencias.

¿Qué es registro-decisiones?

Esta skill está diseñada para capturar decisiones de arquitectura y diseño de manera estructurada y duradera, convirtiéndolas en registros (ADRs) que cualquier desarrollador o sistema pueda consultar. A diferencia de la memoria del chat o del historial, los registros de decisión son infraestructura permanente: se escriben una vez y evitan que el equipo tenga que reconstruir las razones detrás del código. La skill proporciona una plantilla fija con secciones obligatorias como 'Por qué' (justificación), 'Alternativas rechazadas' y 'Dependencias', junto con tres artefactos complementarios: un índice con seguimiento de dependencias, un documento de consideraciones futuras y un archivo de registros reemplazados. También incluye scripts de bash (`doc-archive.sh` e `index-rebuild.sh`) que automatizan la detección de especificaciones sin registro y la regeneración del índice, sin requerir herramientas externas como `jq` o `yq`. Está pensada para entornos como Claude Code, Cursor o Codex, donde la gestión del contexto es crítica: al resumir una especificación larga en ~30-50 líneas, se reduce el consumo de contexto y se mantiene accesible la información clave.

Compatible con✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lguidolin/agent-skills/tree/main/skills/recording-decisions

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Registro de Decisiones

Visión General

Las decisiones son infraestructura duradera; la memoria y el historial del chat no lo son. El costo de un registro se paga una vez; el costo de una decisión perdida se paga cada vez que alguien reconstruye la intención a partir del código.

La Estructura del Registro

Toda decisión no trivial produce un registro con una estructura fija, para que cualquier lector sepa dónde mirar:

SecciónContenido
ArquitecturaLa forma de la solución y los archivos clave
Modelo de DatosEntidades, campos, relaciones
Decisiones (con POR QUÉ)Cada elección acompañada de su justificación — por qué es obligatorio
InterfacesCómo otro código usa esto
RestriccionesLo que debe seguir siendo cierto
TrampasErrores no obvios para la siguiente persona
Alternativas RechazadasLo que se consideró y descartó, y por qué — evita reabrir debates ya cerrados

Los Tres Artefactos Complementarios

  • Un índice de todas las decisiones con seguimiento explícito de dependencias (cuál se basa en cuál) y una sección reemplazado. Convierte un montón de registros en un grafo navegable.
  • Un documento de "Consideraciones Futuras" — ideas aplazadas y preocupaciones conocidas, que se consulta al iniciar un nuevo trabajo para que nada quede olvidado en silencio. Las acciones pendientes de incidentes y las decisiones aplazadas con activador se colocan aquí.
  • Un archivo — los registros reemplazados se mueven aquí en lugar de eliminarse. La historia se preserva, no se sobrescribe.

Referencia Rápida

  • Convención de ubicación de registros: docs/superpowers/decisions/YYYY-MM-DD-<tema>.md con frontmatter YAML (title, date, component, status, supersedes, dependencies).
  • Consideraciones Futuras vive en docs/superpowers/future-considerations.md. Cada entrada lleva un estado (abierto / activado / hecho / descartado) y, cuando corresponda, el activador que debería reactivarla. Consúltalo al iniciar un nuevo trabajo.
  • El frontmatter alimenta el índice generado automáticamente — mantenlo preciso.
  • El por qué y las alternativas rechazadas son las dos secciones de mayor valor. Un registro sin ellas es una mina terrestre.
  • Escribe el registro en la etapa Registro del pipeline (ver diseñando-antes-de-construir), después de Ejecutar.

Herramientas Incluidas

Esta skill incluye sus propios scripts y plantilla, por lo que funcionan en cualquier repositorio donde se instale la skill. Se encuentran junto a SKILL.md:

recording-decisions/
  scripts/doc-archive.sh      encuentra especificaciones/planes sin registro de decisión
  scripts/index-rebuild.sh    regenera el índice a partir del frontmatter de los registros
  templates/decision-record.md

Ubícalos — la skill puede estar instalada por proyecto o globalmente:

for base in .claude/skills ~/.claude/skills; do
  d="$base/recording-decisions/scripts"
  [ -d "$d" ] && echo "$d" && break
done

doc-archive.sh [dir_especificaciones] [dir_planes] [dir_decisiones] [dir_archivo] Enumera las especificaciones sin un registro de decisión correspondiente e imprime un aviso de conversión basado en la plantilla. Los valores predeterminados son docs/superpowers/{specs,plans,decisions,archive}.

index-rebuild.sh [dir_decisiones] [archivo_salida] Reescribe docs/superpowers/index.md a partir del frontmatter de cada registro — una tabla Activa (componente, título, fecha, dependencias) y una tabla Reemplazada (componente, título, reemplazado por). Se regenera por completo, así que nunca lo edites manualmente.

Ambos son scripts bash sin dependencias externas: un proyecto que use esta skill no necesita yq, jq ni un gestor de tareas. Si los scripts faltan, los procedimientos anteriores son autocontenidos — realiza el trabajo directamente.

Por qué esto importa para el contexto

Las especificaciones y los planes son detallados a propósito; están escritos para un humano que sigue el razonamiento. Esa verbosidad se carga al contexto cada vez que Claude abre uno. Un registro de decisión conserva lo necesario para avanzar — decisiones, el por qué, interfaces, restricciones, trampas, alternativas rechazadas — en aproximadamente 30-50 líneas, mientras que la especificación original se mueve a archive/ donde sigue siendo legible para humanos y no cuesta nada hasta que se abre deliberadamente.

Cuándo NO usarlo

Los cambios triviales y evidentes no necesitan un registro. La prueba: ¿alguien preguntaría luego "por qué se hizo así"? Si la respuesta es sí, regístralo.

Justificación completa: Artículo II de la constitución, incluido en engineering-constitution/references/engineering-constitution.md.

Individual skills in this repo

This repo contains 18 individual skills — each has its own dedicated page.

lguidolin/change-hygiene-and-code-craft

Use when writing or refactoring code, structuring a commit or PR, or deciding whether to abstract duplication. Symptoms — mixing reorg with logic changes, a PR doing several things at once, a file growing large, the second copy of similar code, or unsure whether to DRY something up.

lguidolin/cloud-delivery-aks

Use when deploying to Kubernetes or Azure Kubernetes Service (AKS), configuring cloud secrets, setting up progressive rollout/canary, per-PR ephemeral environments, or k8s health probes. Keywords — Kubernetes, AKS, Key Vault, Argo Rollouts, Flagger, canary, blue-green, liveness, readiness, PodDisruptionBudget, HPA, rollback, GHCR.

lguidolin/commit-history-rewrite

Use when an existing repository has messy commit history that needs to conform to conventional commits before adopting release-please, or when intermediate WIP/fixup/merge commits need to be cleaned up.

lguidolin/conventional-commits-and-releases

Use when committing, writing a commit message, opening a PR that will be squash-merged, or configuring automated versioning/changelogs. Keywords — conventional commits, release-please, semver, feat/fix/chore, breaking change, changelog.

lguidolin/defense-in-depth-security

Use when handling untrusted input, secrets, authentication/authorization, or dependencies — or threat-modeling a new surface. Keywords — STRIDE, threat model, least privilege, secrets management, supply chain, dependency scanning, input validation, audit log, defense in depth.

lguidolin/designing-before-building

Use when starting a feature, fixing a non-trivial bug, or about to write implementation code — before any code exists. Symptoms you need this: "this is simple, I'll just code it", reaching for the editor before a design is approved, or an idea that hasn't been turned into a spec and plan.

lguidolin/engineering-constitution

Use when starting work in a project that follows the engineering constitution, orienting to its rules, or deciding which engineering practice applies to a task — spec writing, commits, testing, security, deploys, database, or UI work.

lguidolin/graphql-contract-testing

Use when writing a GraphQL query/mutation that the UI and a test will share, or building route/schema contract or smoke tests. Symptoms — copying a query into a test, a test asserting on query text, schema change that didn't break the UI build, or RLS/permission drift. Keywords — graphql-codegen, typed document, contract test, route smoke test.

lguidolin/init-repo-CI

Use when setting up a new repository with conventional commits, release-please, and CI automation, or when retrofitting an existing repository that lacks automated versioning and PR validation workflows.

lguidolin/interface-craft-and-accessibility

Use when building or styling UI — components, layouts, forms, design tokens — or making accessibility decisions. Keywords — a11y, WCAG, keyboard navigation, focus state, contrast, design system, minimalist UI, component reuse, ARIA, semantic HTML.

lguidolin/merge-gates-and-automation

Use when setting up or changing CI, pre-push hooks, or a task runner, or deciding what must pass before merge. Symptoms — tempted to put authoritative checks only in a local hook, skip CI, bypass with --no-verify, or unsure what gates a merge vs. runs locally.

lguidolin/observability-and-slos

Use when adding logging, metrics, tracing, health checks, SLOs, or alerting — or when building a service surface that needs to be operable and debuggable. Keywords — structured logs, OpenTelemetry, correlation id, RED metrics, liveness, readiness, SLI, SLO, error budget, alerting.

lguidolin/performance-and-scale

Use when working on hot paths, list endpoints, pagination, data-access in loops, or public interfaces/schemas. Symptoms — unbounded queries, N+1 access, no latency budget, optimizing without measuring, or changing an interface many consumers depend on. Keywords — pagination, N+1, Hyrum's Law, performance budget, bundle size.

lguidolin/postgres-postgraphile-rls-and-sql

Use when writing PostgreSQL, PostGraphile config, Row-Level Security policies, SQL schema files, or working on the Browser→App→PostGraphile→Postgres data path. Keywords — RLS, SECURITY DEFINER, search_path, pgSettings, grants, roles, GraphQL depth limit, query cost, statement_timeout, SQL file organization.

lguidolin/resilience-and-deploy-safety

Use when planning a deploy, designing a rollback, or responding to an incident or writing a postmortem. Keywords — deploy safety, rollback, immutable artifact, progressive delivery, canary, blast radius, incident response, blameless postmortem, error budget.

lguidolin/ship-it

Use when the user wants to ship work — push, PR, archive decision records, merge, and clean up. Handles the full lifecycle from committing final changes through post-merge cleanup including converting specs/plans to compact decision records.

lguidolin/tests-as-a-control

Use when writing or modifying tests, when a test breaks during a refactor, or when testing permission/role rules. Symptoms — tempted to edit a test to make it pass, testing only the happy path, a deny-test that started passing, flaky tests, or unsure what to assert.

lguidolin/zero-downtime-migrations

Use when changing a database schema where data must survive the change — adding/removing/renaming columns, constraints, indexes, or backfilling. Symptoms — a destructive migration bundled with a code deploy, a NOT NULL column with a backfill, a table-locking UPDATE, or a rename. Keywords — expand/contract, parallel change, backfill, NOT VALID, CREATE INDEX CONCURRENTLY, graphile-migrate.

Skills relacionados