Communitygithub.com

lguidolin/engineering-constitution

Verwenden Sie diese Fähigkeit, wenn Sie in einem Projekt, das der Engineering-Verfassung folgt, mit der Arbeit beginnen, sich mit deren Regeln vertraut machen oder entscheiden, welche Engineering-Praxis für eine Aufgabe anzuwenden ist – Spezifikationen, Commits, Tests, Sicherheit, Deployments, Datenbank- oder UI-Arbeit.

Was ist engineering-constitution?

Diese Fähigkeit dient als zentrales Inhaltsverzeichnis einer tragbaren Engineering-Verfassung, die in separate, fokussierte Kompetenzen unterteilt ist. Sie definiert acht unveränderliche Prinzipien wie "Verstehen vor dem Bauen", "Tests als Kontrollinstrument" und "YAGNI", die als ethische und praktische Leitplanken für die Softwareentwicklung dienen. Anhand dieser Prinzipien leitet die Fähigkeit den Nutzer zu der für seine aktuelle Aufgabe passenden spezifischen Kompetenz (z.B. Design, Tests, Deployment) und unterscheidet dabei zwischen universellen (Tier 1) und stack-spezifischen (Tier 2) Fähigkeiten. Das übergeordnete Ziel ist es, Softwareentwicklung als "Programmieren integriert über Zeit" zu optimieren, also für langlebige Systeme, deren Betrieb, sichere Änderungen und Wiederherstellbarkeit im Vordergrund stehen. Nutzer werden explizit angehalten, die relevante Kompetenz zu laden, bevor sie programmieren, committen oder deployen, um Standardgewohnheiten zu überschreiben und konsistent nach den Regeln der Verfassung zu handeln.

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

In Ihrer bevorzugten KI fragen

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

Dokumentation

Engineering-Verfassung

Überblick

Eine tragbare Grundsatzordnung für die Ingenieurspraxis, aufgeteilt in fokussierte Fähigkeiten. Diese Fähigkeit ist der Index: Sie legt die unveränderlichen Prinzipien dar und leitet Sie zu der für Ihre Aufgabe spezifischen Fähigkeit weiter. Die vollständige Begründung lebt in references/engineering-constitution.md, das zusammen mit dieser SKILL.md gebündelt ist, sodass die Verfassung überallhin mitreist, wo die Fähigkeit installiert ist.

Kernidee: Softwareentwicklung ist Programmieren, integriert über Zeit. Optimieren Sie für das langlebige System – seinen Betrieb, sichere Änderungen, Wiederherstellung bei Ausfällen – nicht für die erste Bereitstellung.

Die Acht Unveränderlichen Prinzipien

  1. Verstehen vor dem Bauen. Kein Code ohne genehmigtes Design.
  2. Jede Entscheidung mit ihrer Begründung aufzeichnen – und was Sie verworfen haben.
  3. Tests sind ein Kontrollinstrument, keine Formalität – und Verhaltensänderung erfolgt test-first. Ein fehlschlagender Test ist Information, wird niemals wegredigiert. Strukturelle Änderungen sind stattdessen durch das Bestehen der unveränderten Testsuite blockiert.
  4. YAGNI, kompromisslos.
  5. Automatisieren Sie das Wiederholbare.
  6. Softwareentwicklung ist Programmieren, integriert über Zeit.
  7. Eine nicht durchgesetzte Regel ist ein Vorschlag. Binden Sie Regeln an Werkzeuge oder kennzeichnen Sie sie als Prüfer-Entscheidung.
  8. Die ausdrücklichen Anweisungen des Benutzers haben Vorrang vor diesem Dokument. Rangfolge: Benutzer → Verfassung → Werkzeug-Standardwerte.

Welche Fähigkeit Benötige Ich?

Stufe 1 – universell (gilt für jedes Projekt):

Ihre AufgabeFähigkeit
Eine Funktion starten, eine Idee in eine Spezifikation/einen Plan umwandelndesigning-before-building
Eine Entscheidung wurde getroffen; sie aufschreiben (ADR, Index, verworfene Ideen)recording-decisions
Commiten, Commit-Nachrichten schreiben, automatisierte Releasesconventional-commits-and-releases
Tests schreiben/ändern; Berechtigungs-/Rollenregeln; ein Test ist bei einem Refactoring fehlgeschlagentests-as-a-control
Code schreiben oder refaktorisieren; eine Änderung strukturieren; DRY-Entscheidungenchange-hygiene-and-code-craft
UI, Komponenten, Styling, Barrierefreiheit baueninterface-craft-and-accessibility
CI, Pre-Push-Hooks, Task-Runner, Merge-Gatesmerge-gates-and-automation
Logging, Metriken, Tracing, Health Checks, SLOs, Alarmeobservability-and-slos
Nicht vertrauenswürdige Eingaben, Secrets, Authentifizierung, Abhängigkeiten, Bedrohungsmodellierungdefense-in-depth-security
Heiße Pfade, Paginierung, N+1, Listen-Endpunkte, öffentliche Schnittstellenperformance-and-scale
Planung eines Deployments, Rollbacks oder eines Incidents/Postmortemsresilience-and-deploy-safety

Stufe 2 – stack-spezifisch (nur laden, wenn das Werkzeug/Thema vorhanden ist):

Ihre AufgabeFähigkeit
PostgreSQL, PostGraphile, RLS, SQL-Dateien, den App→GraphQL→DB-Pfadpostgres-postgraphile-rls-and-sql
GraphQL-Abfragen, die zwischen UI und Tests geteilt werden; Route-/Schema-Vertragstestsgraphql-contract-testing
Schemaänderung mit Daten, die überleben müssen – Migrationen, Backfillszero-downtime-migrations
Deployment auf Kubernetes/AKS, Cloud-Secrets, progressive Rollouts, Umgebungen pro PRcloud-delivery-aks

Wie Diese Fähigkeiten auf Ein Neues Projekt Angewendet Werden

  • Stufe 1 bleibt unverändert. Jede Fähigkeit oberhalb der Linie gilt für jedes Projekt – Web-App, Pipeline, CLI, Bibliothek.
  • Stufe 2 ist austauschbar. Wenn der Stack abweicht, werden die Fähigkeiten der Stufe 2 nicht ausgelöst (ihre Beschreibungen sind stackspezifisch) und Sie ersetzen sie durch Äquivalente. Die Prinzipien, die sie umsetzen (ein Datenpfad, endgültige Durchsetzung niedrig, Vertragsschnittstellen, reversible Deployments), gelten weiterhin.
  • An den Lebenszyklus anpassen. Ein Projekt vor dem Start oder nur lokal wendet Zero-Downtime-Migrationen, Canary und formelle Incident-Prozesse als Regel jetzt schreiben, bei Auslöser aktivieren an. Geben Sie den Modus des Projekts in seinem ersten Entscheidungsprotokoll an.

Warnsignal

Wenn Sie im Begriff sind, Code zu schreiben, zu committen, zu deployen oder einen Test zu ändern und Sie nicht die relevante obige Fähigkeit konsultiert haben – halten Sie an und laden Sie sie zuerst. Die Verfassung überschreibt die Standardgewohnheit (Prinzip 7); die Gewohnheit ist es, die sie korrigiert.

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/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/recording-decisions

Use when a design or architecture decision has been made and needs to be captured — writing a decision record or ADR, updating a decision index, noting a deferred idea, or superseding a past decision. Keywords — ADR, decision record, rationale, rejected alternatives, dependency index.

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