Blueprint-Referenz

Dies ist die vollständige Feldreferenz für Blueprints. Eine Einführung in Blueprints und ihre Rolle in Devins Umgebung finden Sie unter Deklarative Umgebungskonfiguration.

Ein Blueprint definiert, wie Devins Umgebung konfiguriert wird: welche Tools installiert werden, wie Abhängigkeiten aktuell gehalten werden und welche Befehle Devin kennen soll.

Überblick

Ein Blueprint besteht aus drei grundlegenden Abschnitten auf oberster Ebene sowie aus einem Abschnitt post-build für Blueprints auf Org- und Enterprise-Ebene und optional aus einem Abschnitt clone für Blueprints auf Repo-Ebene:

initialize: ...   # Install tools and runtimes
maintenance: ...  # Install project dependencies
knowledge: ...    # Reference info for Devin (never executed)
post-build: ...   # (Nur für Org/Enterprise) Befehle, die nach dem gesamten Setup ausgeführt werden
clone: ...        # (Repo-level only) Override git-clone defaults

Abschnitt	Zweck	Ausgeführt?
`initialize`	System-Tools, Laufzeitumgebungen für Programmiersprachen und globale CLIs installieren	Bei vollständigen Builds und für von Grund auf neu aufgebaute Workspaces
`maintenance`	Projektabhängigkeiten installieren und aktualisieren	Ja, bei Builds. Dem Agenten zu Sitzungsbeginn als Kontext angezeigt (wird nicht automatisch ausgeführt).
`knowledge`	Devin Anweisungen zum Linten, Testen und Bauen sowie weitere projektspezifische Informationen geben	Nein, nur als Referenz
`post-build`	Befehle, die ausgeführt werden, nachdem alle Repo geklont und eingerichtet wurden (nur org/Enterprise)	Ja, bei Builds — ein Exit-Code ungleich null lässt den Build fehlschlagen
`clone`	Überschreibt, wie das Repository in den Snapshot geklont wird (nur auf Repo-Ebene)	Wird während des Clone-Schritts des Builds angewendet

Alle Abschnitte sind optional. Sie können jede beliebige Kombination verwenden. initialize wird bei vollständigen Builds und für Workspaces ausgeführt, die von Grund auf neu aufgebaut werden. Die Ergebnisse werden im Snapshot gespeichert. In einem differenziellen Build überspringen vererbte Workspaces initialize, ziehen den neuesten Code und führen nur maintenance aus. Schreiben Sie maintenance so, dass es in sich abgeschlossen ist und unabhängig auf dem vorhandenen Snapshot ausgeführt werden kann, ohne dass initialize unmittelbar zuvor ausgeführt werden muss oder auf Umgebungsvariablen angewiesen ist, die initialize zuvor in $ENVRC geschrieben hat. Zu Beginn jeder Sitzung werden maintenance-Befehle nicht automatisch ausgeführt — stattdessen werden sie dem Agenten als Kontext angezeigt, damit er weiß, welche Befehle für Abhängigkeiten bei Bedarf ausgeführt werden müssen (z. B. nach dem Abrufen des neuesten Codes). Die Befehle sollten weiterhin schnell und inkrementell sein. Builds werden automatisch ausgeführt, wenn sich Ihr Blueprint ändert, und außerdem regelmäßig (ca. alle 24 Stunden).

initialize

Verwende initialize, um Tools und Laufzeitumgebungen zu installieren, die nicht vom konkreten Zustand deines Codes abhängen: Laufzeitumgebungen für Programmiersprachen, Systempakete, globale CLIs.

Einfache Form

Für einfache Shell-Befehle verwenden Sie einen Blockskalar:

initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
  npm install -g pnpm

Strukturierte Form

Verwenden Sie für benannte Schritte, Umgebungsvariablen oder GitHub Actions eine Liste:

initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install system packages"
    run: |
      apt-get update
      apt-get install -y libpq-dev

  - name: "Install global tools"
    run: pip install uv
    env:
      PIP_BREAK_SYSTEM_PACKAGES: "1"

Beide Formen können kombiniert werden. Die einfache Form entspricht einem einzelnen Schritt mit run.

Wann `initialize` statt `maintenance` verwenden

In `initialize`	In `maintenance` einfügen
Installation der Laufzeitumgebung für Programmiersprachen	`npm install` / `pip install`
Systempakete (`apt-get`)	`bundle install`
Globale CLI-Tools	`go mod download`
Einmalige Konfiguration	Updates des Abhängigkeits-Caches
GitHub Actions (`setup-python`, etc.)	Repo-spezifische Setup-Skripte

Beide Abschnitte werden bei vollständigen Builds ausgeführt. Bei differenziellen Builds überspringen vererbte Workspaces initialize und führen nach dem Abrufen des neuesten Codes nur maintenance aus. Tools und Laufzeitumgebungen für Programmiersprachen gehören in initialize; Abhängigkeitsbefehle, die sich an den Lock-Dateien Ihres Codes orientieren, gehören in maintenance.

maintenance

Verwenden Sie maintenance für die Installation von Abhängigkeiten und andere Befehle, die nach dem Klonen Ihres Codes ausgeführt werden sollen. Diese Befehle werden während Builds ausgeführt und dem Agenten zu Beginn der Sitzung angezeigt, damit er sie erneut ausführen kann, wenn sich Abhängigkeiten geändert haben. Hierhin gehören npm install, pip install, uv sync und ähnliche Befehle.

maintenance: |
  npm install
  pip install -r requirements.txt

Oder in strukturierter Form:

maintenance:
  - name: "Install npm dependencies"
    run: npm install

  - name: "Install Python dependencies"
    run: uv sync
    env:
      UV_CACHE_DIR: /tmp/uv-cache

Für Blueprints auf Repo-Ebene werden maintenance-Befehle im Root-Verzeichnis des Repos ausgeführt. Für Blueprints auf Org-Ebene werden sie im Home-Verzeichnis (~) ausgeführt.

knowledge

Der Abschnitt knowledge wird nicht ausgeführt. Er enthält Referenzinformationen, die Devin bei der Arbeit an Ihrem Projekt verwendet. Hier geben Sie Devin die richtigen Befehle für Linting, Tests, Builds und andere projektspezifische Workflows an.

knowledge:
  - name: lint
    contents: |
      Run linting with:
      npm run lint

      For auto-fix:
      npm run lint -- --fix

  - name: test
    contents: |
      Run the full test suite:
      npm test

      Run a single test file:
      npm test -- path/to/test.ts

  - name: build
    contents: |
      npm run build

      Build output goes to dist/

Jeder Knowledge-Eintrag hat:

Feld	Typ	Beschreibung
`name`	string	Bezeichner für diesen Knowledge-Eintrag (z. B. `lint`, `test`, `build`)
`contents`	string	Freitext mit Befehlen, Anweisungen oder Hinweisen

Das Feld name ist eine Bezeichnung. Üblicherweise sind lint, test und build die Standardnamen. Bei der Überprüfung seiner Arbeit greift Devin auf diese zurück. Sie können beliebige zusätzliche Knowledge-Einträge mit benutzerdefinierten Namen hinzufügen:

knowledge:
  - name: lint
    contents: ...
  - name: test
    contents: ...
  - name: build
    contents: ...
  - name: deploy
    contents: |
      Deploy to staging:
      npm run deploy:staging
  - name: database
    contents: |
      Run migrations:
      npm run db:migrate

      Seed test data:
      npm run db:seed

post-build

Der Abschnitt post-build ist nur in Blueprints auf Organisations- und Enterprise-Ebene verfügbar (in Blueprints auf Repo-Ebene wird er nicht unterstützt). Seine Schritte werden während des Builds ausgeführt, nachdem alle Repositorys geklont wurden und ihre Schritte initialize und maintenance abgeschlossen sind, aber bevor die Integritätsprüfung durchgeführt und das Snapshot-Image erstellt wird. Damit ist dies der richtige Ort für Repository-übergreifende Validierungen und Integritätsprüfungen, die die vollständig aufgebaute Umgebung benötigen. Da er erst spät im Build ausgeführt wird, wenn die gesamte Umgebung bereitsteht, kann ein post-build-Schritt jedes geklonte Repo und jedes Tool sehen, das von den Enterprise-, Org- und Repo-Blueprints installiert wurde.

post-build: |
  # Überprüfe, ob die zusammengestellte Umgebung fehlerfrei ist
  node --version
  python --version
  test -d ~/repos/my-service

Oder in strukturierter Form:

post-build:
  - name: "Verify toolchain"
    run: |
      node --version
      uv --version

  - name: "Smoke-test the workspace"
    run: ~/repos/my-service/scripts/healthcheck.sh

post-build-Schritte lassen den Build bei einem Exit-Code ungleich null fehlschlagen. Wenn ein post-build-Schritt mit einem Exit-Code ungleich null beendet wird, wird der Build als fehlgeschlagen markiert und es wird kein Snapshot-Image erzeugt. Verwenden Sie dies, um Snapshots an Integritätsprüfungen zu knüpfen — stellen Sie aber sicher, dass die Befehle zuverlässig sind, damit ein instabiler Check Ihre Builds nicht blockiert.

post-build-Schritte verwenden dieselben Schritttypen wie initialize und maintenance (Shell-run-Befehle und GitHub-Actions-uses) und werden aus dem Home-Verzeichnis (~) ausgeführt.

clone

Für Blueprints auf Repo-Ebene überschreibt der optionale Abschnitt clone die Standardwerte, die Devin verwendet, wenn das Repository in den Snapshot geklont wird. Jedes Feld ist optional und greift andernfalls auf einen sinnvollen Standard zurück, der das aktuelle Verhalten beibehält.

clone:
  path: my-project        # Klonziel unter ~/repos/ (Standard: Kurzname des Repos)
  ref: develop            # Branch oder Tag zum Auschecken (Standard: Standard-Branch des Repos)
  depth: 1                # 0 = vollständige Historie, N = --depth N (Standard: 0)
  tags: false             # false übergibt --no-tags (Standard: true)
  submodules: recursive   # true / false / "recursive" (Standard: true)
  lfs: false              # false setzt GIT_LFS_SKIP_SMUDGE=1 beim Klonen (Standard: true)

Feld	Typ	Standard	Beschreibung
`path`	string	Repo-Kurzname	Überschreibt das Zielverzeichnis für den Klonvorgang unter `~/repos/`. Muss innerhalb desselben Snapshots repo-übergreifend eindeutig sein.
`ref`	string	Standard-Branch des Repo	Branch oder Tag, der nach dem Klonen ausgecheckt wird. Commit-SHAs werden hier nicht unterstützt.
`depth`	int	`0`	Klontiefe. `0` klont den vollständigen Verlauf; jeder positive Wert übergibt `--depth N` für einen Shallow Clone.
`tags`	bool	`true`	Wenn `false`, wird `--no-tags` übergeben, um das Abrufen von Git-Tags zu überspringen.
`submodules`	bool or `"recursive"`	`true`	`true` oder `"recursive"` übergibt `--recurse-submodules`. `false` überspringt Submodule vollständig.
`lfs`	bool	`true`	Wenn `false`, wird `GIT_LFS_SKIP_SMUDGE=1` gesetzt, um das Herunterladen von Git-LFS-Objekten beim Klonen zu überspringen.

clone gilt nur für auf Repo-Ebene Blueprints — es steuert, wie das jeweilige Repo in den Snapshot geklont wird. In Blueprints auf Org-Ebene oder enterprise-level hat es keine Wirkung.

Schritttypen

Jeder Schritt in initialize, maintenance oder post-build gehört zu einem von zwei Typen: Shell-Befehle (run) oder GitHub Actions (uses).

Shell-Befehle (`run`)

Führen Sie beliebige Shell-Befehle in Bash aus:

- name: "Install dependencies"
  run: |
    npm install
    pip install -r requirements.txt

Feld	Typ	Beschreibung
`name`	string (optional)	Menschenlesbare Bezeichnung für den Schritt
`run`	string	Auszuführende Shell-Befehle
`env`	map (optional)	Zusätzliche Umgebungsvariablen für diesen Schritt

Ausführungsdetails:

Befehle werden in bash ausgeführt. Wenn in einem mehrzeiligen Skript ein Befehl fehlschlägt, wird der gesamte Schritt sofort abgebrochen.
Blueprints auf Org-Ebene werden im Home-Verzeichnis (~) ausgeführt.
Blueprints auf Repo-Ebene werden im Root-Verzeichnis des geklonten Repositorys ausgeführt.
Jeder Schritt hat ein Timeout von 1 Stunde.
Secrets sind automatisch als Umgebungsvariablen verfügbar.

GitHub Actions (`uses`)

Führen Sie Node.js-basierte GitHub Actions direkt in Ihrem Blueprint aus:

- name: "Install Python"
  uses: github.com/actions/setup-python@v5
  with:
    python-version: "3.12"

Feld	Typ	Beschreibung
`name`	string (optional)	Menschenlesbare Bezeichnung für den Schritt
`uses`	string	Referenz auf eine GitHub Action
`with`	map (optional)	Eingabeparameter für die Action
`env`	map (optional)	Zusätzliche Umgebungsvariablen für diesen Schritt

Format der Action-Referenz:

github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>

Das Präfix github.com/ und das Suffix @<ref> sind beide erforderlich. Die Referenz ist in der Regel ein Versions-Tag wie v5. Häufig verwendete Actions:

Action	Zweck	Beispiel für `with`
`github.com/actions/setup-python@v5`	Python installieren	`python-version: "3.12"`
`github.com/actions/setup-node@v4`	Node.js installieren	`node-version: "20"`
`github.com/actions/setup-go@v5`	Go installieren	`go-version: "1.22"`
`github.com/actions/setup-java@v4`	Java/JDK installieren	`java-version: "21"`, `distribution: "temurin"`
`github.com/gradle/actions/setup-gradle@v4`	Gradle installieren	(keine)
`github.com/ruby/setup-ruby@v1`	Ruby installieren	`ruby-version: "3.3"`

Unterstützt werden nur Node.js-basierte GitHub Actions. Composite Actions und Docker-basierte Actions werden nicht unterstützt.

So funktionieren with-Werte: Werte, die über with übergeben werden, werden der Action als Eingaben übergeben und folgen dabei denselben Konventionen wie in GitHub-Actions-Workflows. Alle Werte werden in Zeichenfolgen umgewandelt.

with:
  python-version: "3.12"
  check-latest: true
  cache: "pip"

Wie Aktionen Änderungen weiterreichen: Aktionen können die Umgebung für nachfolgende Schritte ändern. Zum Beispiel fügt setup-python die Python-Binärdatei zu PATH hinzu, sodass sie in allen späteren Schritten und in maintenance verfügbar bleibt.

`run` vs. `uses`: wann Sie was verwenden sollten

`run` verwenden, wenn…	`uses` verwenden, wenn…
Systempakete installiert werden (`apt-get`)	Laufzeitumgebungen für Programmiersprachen eingerichtet werden (Python, Node, Go, Java, Ruby)
projektspezifische Skripte ausgeführt werden	es eine offizielle GitHub Action für Ihre Anforderungen gibt
Dateien oder die Umgebung konfiguriert werden	Sie automatische Versionsverwaltung und Caching nutzen möchten
der Befehl einfach und in sich abgeschlossen ist	Sie dieselbe Action in einem GitHub-Actions-Workflow verwenden würden

In der Praxis verwenden die meisten Konfigurationen uses für Laufzeitumgebungen von Programmiersprachen und run für alles andere.

Umgebungsvariablen und Secrets

Umgebungsvariablen pro Schritt

Jeder Schritt kann mit dem Feld env zusätzliche Umgebungsvariablen definieren:

- run: pip install -r requirements.txt
  env:
    PIP_INDEX_URL: "https://pypi.example.com/simple/"
    PIP_BREAK_SYSTEM_PACKAGES: "1"

Diese gelten nur für den jeweiligen Schritt und bleiben in nachfolgenden Schritten nicht erhalten.

Schrittübergreifende Umgebungsvariablen (`$ENVRC`)

Um Umgebungsvariablen über mehrere Schritte hinweg weiterzugeben, schreiben Sie sie in die Datei $ENVRC:

- name: "Set shared variables"
  run: |
    echo "DATABASE_URL=postgresql://localhost:5432/myapp" >> $ENVRC
    echo "APP_ENV=development" >> $ENVRC

In $ENVRC geschriebene Variablen werden automatisch exportiert und stehen in allen nachfolgenden Schritten sowie in der Devin-Sitzung zur Verfügung, die durch den aktuellen Build erzeugt wird. Das funktioniert ähnlich wie $GITHUB_ENV in GitHub Actions. Dies gilt auch für PATH. Wenn Sie ein Tool in einem nicht standardmäßigen Verzeichnis installieren (alles außerhalb von /usr/bin oder /usr/local/bin), fügen Sie den Pfad zu $ENVRC hinzu, damit nachfolgende Schritte und Blueprints auf Repo-Ebene die Binärdatei finden können:

- name: "Install latest direnv"
  run: |
    curl -sfL https://direnv.net/install.sh | bash
    echo 'export PATH="$HOME/.local/bin:$PATH"' >> $ENVRC

Ein einfaches export PATH=... innerhalb eines run:-Blocks gilt nur für die Shell dieses Schritts. Jeder Schritt startet einen neuen Shell-Prozess, sodass PATH-Änderungen, die nicht in $ENVRC geschrieben werden, verloren gehen.

uses:-Actions (z. B. actions/setup-node) übernehmen ihre PATH- Ergänzungen automatisch in $ENVRC — Sie müssen dies nur bei run:-Schritten manuell tun.

$ENVRC wird zu Beginn jedes Builds zurückgesetzt, einschließlich differenzieller Builds. Werte, die während eines Builds geschrieben werden, sind im nächsten Build nicht verfügbar. Insbesondere führt ein vererbter Workspace nur maintenance aus, sodass er sich nicht auf PATH oder andere Variablen verlassen kann, die initialize im übergeordneten Build in $ENVRC geschrieben hat. Konfigurieren Sie alle von maintenance benötigten Umgebungen innerhalb von maintenance selbst.

Secrets

In der Devin-Benutzeroberfläche konfigurierte Secrets (über den Secrets-Tab in jedem Blueprint-Editor) werden automatisch als Umgebungsvariablen eingefügt. Sie müssen sie nicht in Ihrem Blueprint deklarieren. Verweisen Sie einfach per Namen darauf (z. B. $MY_SECRET). Secrets werden vor jedem Schritt während Builds eingefügt und zu Beginn jeder Sitzung erneut eingefügt. Aus dem Snapshot-Image selbst werden sie entfernt, sodass Zugangsdaten niemals in gespeicherte Maschinenabbilder eingebettet sind.

Organisations-Secrets: Als Umgebungsvariablen in jedem Schritt aller Blueprints in der org verfügbar. Konfigurieren Sie diese im Secrets-Tab des Editors für das organisationsweite Blueprint.
Enterprise-Secrets: Werden mit org-Secrets zusammengeführt (bei Namenskonflikten haben org-Secrets Vorrang). In allen orgs im Enterprise verfügbar.
Repository-Secrets: Werden in eine Repo-spezifische Datei unter /run/repo_secrets/{owner/repo}/.env.secrets geschrieben. Während Builds werden Repo-Secrets automatisch geladen, bevor die Blueprint-Schritte dieses Repos ausgeführt werden. Während Sitzungen lädt Devin sie, wenn im Repo gearbeitet wird. Konfigurieren Sie diese im Secrets-Tab des Blueprint-Editors des Repositorys.

Nur-Build-Secrets: Secrets, die als “build only” markiert sind, sind während Snapshot-Builds verfügbar, werden aber entfernt, bevor der Snapshot gespeichert wird. Verwenden Sie diese für Zugangsdaten, die nur während des Builds benötigt werden (z. B. zum Herunterladen privater Artefakte während initialize).

maintenance wird während Builds ausgeführt. Zu Beginn einer Sitzung werden maintenance-Befehle dem Agent angezeigt (nicht automatisch ausgeführt), sodass der Agent sie bei Bedarf erneut ausführen kann. Wenn ein maintenance-Schritt Secrets in Konfigurationsdateien schreibt (z. B. ~/.m2/settings.xml, ~/.npmrc), werden diese Dateien in den Snapshot eingebettet. Platzieren Sie Schritte, die Zugangsdaten schreiben, in maintenance (nicht in initialize), damit sie während periodischer Builds aktualisiert werden. Beachten Sie aber, dass die geschriebenen Dateien im Image erhalten bleiben. Für maximale Sicherheit sollten Sie Umgebungsvariablen oder $ENVRC verwenden, anstatt Zugangsdaten auf den Datenträger zu schreiben.

Dateianhänge

Sie können Dateien (wie .npmrc, settings.xml oder Konfigurationsdateien) über den Blueprint-Editor hochladen. Hochgeladene Dateien werden unter ~/.files/ abgelegt, und es wird eine Umgebungsvariable gesetzt, die auf den Pfad der jeweiligen Datei verweist:

$FILE_SETTINGS_XML    -> /home/ubuntu/.files/settings.xml
$FILE_NPMRC           -> /home/ubuntu/.files/.npmrc

Der Variablenname wird vom Dateinamen abgeleitet: in Großbuchstaben, wobei nicht alphanumerische Zeichen durch Unterstriche ersetzt und mit dem Präfix FILE_ versehen werden. Verwenden Sie Dateianhänge in Ihren Blueprint-Schritten:

maintenance:
  - name: "Configure Maven"
    run: |
      mkdir -p ~/.m2
      cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml

Git-gestützte Blueprints

Sie können Blueprints als .devin/blueprint.yaml-Dateien direkt in Ihrem Repository speichern und anschließend über die API oder die UI synchronisieren. Weitere Informationen und Anweisungen zum Setup finden Sie unter Git-gestützte Blueprints.

Vollständiges Beispiel

Informationen dazu, wie Blueprints über verschiedene Ebenen hinweg zusammenwirken (enterprise → org → repo), zu Build-Status, Repository-Zuständen und dazu, was einen erneuten Build auslöst, finden Sie unter Builds und Sitzungen auf der Seite zur deklarativen Konfiguration.

Organisationsweites Blueprint

Gemeinsam genutzte Tools, die jedes Repo in der Org benötigt. Dieses Blueprint wird zuerst ausgeführt (nach einem etwaigen Enterprise-Blueprint), und zwar im Home-Verzeichnis.

initialize:
  - name: "Install Node.js 20"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install Python 3.12 and uv"
    run: |
      curl -LsSf https://astral.sh/uv/install.sh | sh

  - name: "Install shared tools"
    run: |
      npm install -g pnpm turbo
      apt-get update && apt-get install -y jq ripgrep

  - name: "Configure private registry"
    run: |
      echo "//npm.corp.example.com/:_authToken=$NPM_REGISTRY_TOKEN" >> ~/.npmrc

Blueprint auf Repo-Ebene

Projektspezifische Einrichtung für ein Node.js- und Python-Monorepo. Sie wird nach dem organisationsweiten Blueprint im Repository-Verzeichnis ausgeführt.

initialize:
  - name: "Install Playwright browsers"
    run: npx playwright install --with-deps chromium

  - name: "Set up project environment variables"
    run: |
      echo "DATABASE_URL=postgresql://localhost:5432/myapp_dev" >> $ENVRC
      echo "REDIS_URL=redis://localhost:6379" >> $ENVRC
      echo "APP_ENV=development" >> $ENVRC

maintenance:
  - name: "Install frontend dependencies"
    run: |
      cd frontend
      pnpm install

  - name: "Install backend dependencies"
    run: |
      cd backend
      uv sync

  - name: "Run database migrations"
    run: |
      cd backend
      uv run alembic upgrade head
    env:
      DATABASE_URL: "postgresql://localhost:5432/myapp_dev"

knowledge:
  - name: lint
    contents: |
      Frontend:
      cd frontend && pnpm lint

      Backend:
      cd backend && uv run ruff check .

      Auto-fix:
      cd frontend && pnpm lint --fix
      cd backend && uv run ruff check --fix .

  - name: test
    contents: |
      Frontend unit tests:
      cd frontend && pnpm test

      Backend unit tests:
      cd backend && uv run pytest

      E2E tests (requires dev server running):
      cd frontend && pnpm test:e2e

  - name: build
    contents: |
      Frontend:
      cd frontend && pnpm build

      Backend:
      cd backend && uv run python -m build

  - name: dev-server
    contents: |
      Start the full development stack:
      cd backend && uv run uvicorn main:app --reload &
      cd frontend && pnpm dev

      Frontend: http://localhost:3000
      Backend API: http://localhost:8000
      API docs: http://localhost:8000/docs

  - name: database
    contents: |
      Run migrations:
      cd backend && uv run alembic upgrade head

      Create a new migration:
      cd backend && uv run alembic revision --autogenerate -m "description"

      Reset the database:
      cd backend && uv run alembic downgrade base && uv run alembic upgrade head

Devin Desktop

Agent Command Center

Releases

Windsurf Plugins

Accounts

Security

Überblick

initialize

Einfache Form

Strukturierte Form

Wann `initialize` statt `maintenance` verwenden

maintenance

knowledge

post-build

clone

Schritttypen

Shell-Befehle (`run`)

GitHub Actions (`uses`)

`run` vs. `uses`: wann Sie was verwenden sollten

Umgebungsvariablen und Secrets

Umgebungsvariablen pro Schritt

Schrittübergreifende Umgebungsvariablen (`$ENVRC`)

Secrets

Dateianhänge

Git-gestützte Blueprints

Vollständiges Beispiel

Organisationsweites Blueprint

Blueprint auf Repo-Ebene

​Überblick

​initialize

​Einfache Form

​Strukturierte Form

​Wann initialize statt maintenance verwenden

​maintenance

​knowledge

​post-build

​clone

​Schritttypen

​Shell-Befehle (run)

​GitHub Actions (uses)

​run vs. uses: wann Sie was verwenden sollten

​Umgebungsvariablen und Secrets

​Umgebungsvariablen pro Schritt

​Schrittübergreifende Umgebungsvariablen ($ENVRC)

​Secrets

​Dateianhänge

​Git-gestützte Blueprints

​Vollständiges Beispiel

​Organisationsweites Blueprint

​Blueprint auf Repo-Ebene

Überblick

initialize

Einfache Form

Strukturierte Form

Wann `initialize` statt `maintenance` verwenden

maintenance

knowledge

post-build

clone

Schritttypen

Shell-Befehle (`run`)

GitHub Actions (`uses`)

`run` vs. `uses`: wann Sie was verwenden sollten

Umgebungsvariablen und Secrets

Umgebungsvariablen pro Schritt

Schrittübergreifende Umgebungsvariablen (`$ENVRC`)

Secrets

Dateianhänge

Git-gestützte Blueprints

Vollständiges Beispiel

Organisationsweites Blueprint

Blueprint auf Repo-Ebene