Communitygithub.com

lguidolin/recording-decisions

Verwenden Sie dies, wenn eine Design- oder Architekturentscheidung getroffen wurde und festgehalten werden muss – schreiben eines Entscheidungsprotokolls oder ADR, Aktualisieren eines Entscheidungsindex, Notieren einer zurückgestellten Idee oder Ersetzen einer früheren Entscheidung. Schlüsselwörter – ADR, Entscheidungsprotokoll, Begründung, abgelehnte Alternativen, Abhängigkeitsindex.

Was ist recording-decisions?

Dieses Skill erfasst Design- und Architekturentscheidungen als dauerhafte, strukturierte Aufzeichnungen und stellt sicher, dass Wissen nicht in flüchtigen Chats oder im Gedächtnis verloren geht. Es ist für Plattformen wie Claude Code, Cursor und Codex konzipiert und folgt einer klaren Vorlage mit Abschnitten wie Architektur, Datenmodell, Begründung, Grenzen und abgelehnten Alternativen. Die enthaltenen Bash-Skripte gleichen Spezifikationen mit Entscheidungsprotokollen ab, generieren automatisch einen Abhängigkeitsindex und archivieren veraltete Einträge. Durch die Umwandlung von ausführlichen Spezifikationen in prägnante, ~30-50 Zeilen lange Aufzeichnungen spart dieses Skill Kontext und beugt wiederholten Diskussionen vor, sodass Teams fundierte Entscheidungen nachvollziehen können, ohne Code rückentwickeln zu müssen.

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

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Entscheidungen aufzeichnen

Übersicht

Entscheidungen sind dauerhafte Infrastruktur; Gedächtnis und Chat-Verlauf sind es nicht. Die Kosten einer Aufzeichnung werden einmalig bezahlt; die Kosten einer verlorenen Entscheidung werden jedes Mal bezahlt, wenn jemand die Absicht aus Code rückentwickelt.

Die Form der Aufzeichnung

Jede nicht-triviale Entscheidung erzeugt eine Aufzeichnung mit einer festen Struktur, sodass jeder Leser weiß, wo er suchen muss:

AbschnittEnthält
ArchitekturDie Form der Lösung und die Schlüsseldateien
DatenmodellEntitäten, Felder, Beziehungen
Entscheidungen (mit WARUM)Jede Wahl zusammen mit ihrer Begründung – warum ist Pflicht
SchnittstellenWie anderer Code dies verwendet
EinschränkungenWas muss wahr bleiben
FallstrickeNicht offensichtliche Fallen für die nächste Person
Abgelehnte AlternativenWas wurde erwogen und verworfen, und warum – verhindert das Wiederaufgreifen geklärter Fragen

Die drei Begleitartefakte

  • Ein Index aller Entscheidungen mit expliziter Abhängigkeitsverfolgung (welche auf welcher aufbaut) und einem Abschnitt Ersetzt. Verwandelt einen Haufen Aufzeichnungen in einen navigierbaren Graphen.
  • Ein Dokument „Zukünftige Überlegungen“ – zurückgestellte Ideen und bekannte Anliegen, das bei Beginn neuer Arbeiten konsultiert wird, damit nichts stillschweigend vergessen wird. Incident-Aktionspunkte und zurückgestellte Entscheidungen mit Auslöser landen hier.
  • Ein Archiv – ersetzte Aufzeichnungen werden hierhin verschoben, anstatt gelöscht zu werden. Die Geschichte bleibt erhalten, nicht überschrieben.

Kurzreferenz

  • Aufzeichnungsort-Konvention: docs/superpowers/decisions/YYYY-MM-DD-<thema>.md mit YAML-Frontmatter (title, date, component, status, supersedes, dependencies).
  • Zukünftige Überlegungen befinden sich unter docs/superpowers/future-considerations.md. Jeder Eintrag trägt einen Status (open / triggered / done / dropped) und, wo zutreffend, den Auslöser , der ihn reaktivieren soll. Konsultieren Sie ihn bei Beginn neuer Arbeiten.
  • Frontmatter speist den automatisch generierten Index – halten Sie es genau.
  • Das Warum und die abgelehnten Alternativen sind die beiden wertvollsten Abschnitte. Eine Aufzeichnung ohne sie ist eine Zeitbombe.
  • Schreiben Sie die Aufzeichnung im Aufzeichnungs -Schritt der Pipeline (siehe designing-before-building), nach „Ausführen“.

Gebündelte Werkzeuge

Dieses Skill enthält eigene Skripte und Vorlagen, sodass sie in jedem Repository funktionieren, in dem das Skill installiert ist. Sie befinden sich neben SKILL.md:

recording-decisions/
  scripts/doc-archive.sh      findet Spezifikationen/Pläne ohne Entscheidungsprotokoll
  scripts/index-rebuild.sh    regeneriert den Index aus den Frontmatter-Daten
  templates/decision-record.md

Finden Sie sie – das Skill kann pro Projekt oder global installiert sein:

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

doc-archive.sh [specs_dir] [plans_dir] [decisions_dir] [archive_dir] Listet Spezifikationen ohne zugehöriges Entscheidungsprotokoll auf und gibt eine Konvertierungsaufforderung aus, die aus der Vorlage erstellt wurde. Standardmäßig unter docs/superpowers/{specs,plans,decisions,archive}.

index-rebuild.sh [decisions_dir] [output_file] Überschreibt docs/superpowers/index.md aus den Frontmatter-Daten jeder Aufzeichnung – eine Aktive Tabelle (Komponente, Titel, Datum, Abhängigkeiten) und eine Tabelle „Ersetzt“ (Komponente, Titel, ersetzt durch). Vollständig neu generiert, daher niemals von Hand bearbeiten.

Beide sind ablauffreie Bash-Skripte: Ein Projekt, das dieses Skill verwendet, benötigt weder yq, jq noch einen Task-Runner. Wenn die Skripte fehlen, sind die obigen Verfahren in sich abgeschlossen – führen Sie die Arbeit direkt aus.

Warum dies für den Kontext wichtig ist

Spezifikationen und Pläne sind absichtlich ausführlich; sie sind für einen Menschen geschrieben, der der Argumentation folgt. Diese Ausführlichkeit belastet den Kontext jedes Mal, wenn Claude eine öffnet. Ein Entscheidungsprotokoll behält, was für die Weiterarbeit benötigt wird – Entscheidungen, das Warum, Schnittstellen, Einschränkungen, Fallstricke, abgelehnte Alternativen – in etwa 30-50 Zeilen, während die ursprüngliche Spezifikation in archive/ verschoben wird, wo sie für Menschen lesbar bleibt und nichts kostet, bis sie absichtlich geöffnet wird.

Wann NICHT verwenden

Triviale, offensichtliche Änderungen benötigen keine Aufzeichnung. Der Test: Würde später jemand fragen „Warum wurde das so gemacht?“ Wenn ja, zeichnen Sie es auf.

Vollständige Begründung: Artikel II der Verfassung, gebündelt unter 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.

Verwandte Skills