> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# ブループリント リファレンス

> ブループリントの完全なフィールドリファレンス: セクション、ステップの種類、GitHub Actions、環境変数、シークレット、ファイルの添付。

<Info>
  これはブループリントの完全なフィールドリファレンスです。ブループリントの概要と、Devin の環境内でどのように機能するかについては、[宣言的
  環境設定](/ja/onboard-devin/environment/blueprints)を参照してください。
</Info>

ブループリントは、Devin の環境をどのように構成するかを定義します。具体的には、どのツールをインストールするか、依存関係をどのように最新の状態に保つか、そして Devin が認識しておくべきコマンドを定めます。

<div id="overview">
  ## 概要
</div>

ブループリントは、次の 3 つの主要なトップレベルセクションに加え、org レベルおよび Enterprise レベルのブループリント向けの `post-build` セクションと、リポジトリレベルのブループリントで任意に追加できる `clone` セクションで構成されています。

```yaml theme={null}
initialize: ...   # Install tools and runtimes
maintenance: ...  # Install project dependencies
knowledge: ...    # Reference info for Devin (never executed)
post-build: ...   # （Org/Enterpriseのみ）すべてのセットアップ後に実行されるコマンド
clone: ...        # (Repo-level only) Override git-clone defaults
```

| Section       | 目的                                                           | 実行されるか                                               |
| ------------- | ------------------------------------------------------------ | ---------------------------------------------------- |
| `initialize`  | システムツール、言語ランタイム、グローバル CLI をインストールする                          | フルビルド時および再構築されたワークスペースに対して実行されます                     |
| `maintenance` | プロジェクトの依存関係をインストールし、更新する                                     | はい。ビルド時に実行されます。セッション開始時にエージェントに提示されます (自動実行はされません) 。 |
| `knowledge`   | lint、test、build の方法や、その他のプロジェクト固有の情報を Devin に伝える             | いいえ。参照情報として提供されます                                    |
| `post-build`  | すべてのリポジトリが clone され、セットアップされた後に実行されるコマンド (org/enterprise のみ) | はい。ビルド時に実行されます — 終了コードが 0 以外の場合、ビルドは失敗します            |
| `clone`       | リポジトリをスナップショットに clone する方法をオーバーライドする (リポジトリレベルのみ)            | ビルドの clone ステップ中に適用されます                              |

すべてのセクションは任意です。任意の組み合わせで含めることができます。

`initialize` はフルビルド時およびゼロから再構築されるワークスペースに対して実行されます。結果はスナップショットに保存されます。[差分ビルド](/ja/onboard-devin/environment/differential-builds) では、継承されたワークスペースは `initialize` を skip し、最新のコードを pull して、`maintenance` のみを実行します。`maintenance` は、それ単体で完結し、既存のスナップショット上で独立して実行できるように記述してください。直前に `initialize` の実行が必要にならないようにし、`initialize` が以前に `$ENVRC` に書き込んだ environment variables に依存しないようにしてください。各セッションの開始時には、`maintenance` コマンドは **自動実行されません**。代わりに、必要に応じて (たとえば最新のコードを pull した後に) どの依存関係コマンドを実行すべきかをエージェントが把握できるよう、前提情報として提示されます。コマンドは高速で、差分的に実行できるものにしてください。ビルドは ブループリント が変更されたときと、定期的 (約 24 時間ごと) に自動実行されます。

<div id="initialize">
  ## initialize
</div>

`initialize` は、コードの特定の状態に依存しないツールやランタイム (言語ランタイム、システムパッケージ、グローバル CLI など) をインストールする際に利用します。

<div id="simple-form">
  ### シンプルな形式
</div>

単純なシェルコマンドには、ブロックスカラーを利用します:

```yaml theme={null}
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
  npm install -g pnpm
```

<div id="structured-form">
  ### 構造化された形式
</div>

名前付きステップ、環境変数、または GitHub Actions には、リスト形式を利用します:

```yaml theme={null}
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"
```

両方の形式は混在させて使用できます。シンプルな形式は、`run` を含む 1 つのステップと同等です。

<div id="when-to-use-initialize-vs-maintenance">
  ### initialize と maintenance の使い分け
</div>

| `initialize` に入れるもの                | `maintenance` に入れるもの          |
| ---------------------------------- | ----------------------------- |
| 言語ランタイムのインストール                     | `npm install` / `pip install` |
| システムパッケージ (`apt-get`)              | `bundle install`              |
| グローバル CLI ツール                      | `go mod download`             |
| 1回限りの設定                            | 依存関係キャッシュの更新                  |
| GitHub Actions (`setup-python` など) | リポジトリ固有のセットアップスクリプト           |

どちらのセクションもフルビルド中に実行されます。差分ビルドでは、継承されたワークスペースは最新のコードを取得した後、`initialize` をスキップし、`maintenance` のみを実行します。ツールやランタイムは `initialize` に、コードのロックファイルに追従する依存関係コマンドは `maintenance` に入れます。

<div id="maintenance">
  ## maintenance
</div>

`maintenance` は、コードのクローン後に実行する依存関係のインストールやその他のコマンドに利用します。これらのコマンドはビルド中に実行され、セッション開始時にエージェントにも共有されるため、依存関係が変更された場合はエージェントが再実行できます。`npm install`、`pip install`、`uv sync` などのコマンドはここに含めます。

```yaml theme={null}
maintenance: |
  npm install
  pip install -r requirements.txt
```

あるいは、構造化された形式では次のとおりです:

```yaml theme={null}
maintenance:
  - name: "Install npm dependencies"
    run: npm install

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

<Info>リポジトリレベルのブループリントでは、`maintenance` コマンドはリポジトリのルートディレクトリで実行されます。org レベルのブループリントでは、ホームディレクトリ (`~`) で実行されます。</Info>

<div id="knowledge">
  ## knowledge
</div>

`knowledge` セクションは**実行されません**。これは、Devin がプロジェクトで作業する際に参照する情報です。ここでは、lint、テスト、ビルド、その他のプロジェクト固有のワークフローで使用する正しいコマンドを Devin に伝えます。

```yaml theme={null}
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/
```

各 Knowledge アイテムには、以下のフィールドがあります。

| Field      | Type   | Description                                      |
| ---------- | ------ | ------------------------------------------------ |
| `name`     | string | この Knowledge アイテムの識別子 (例: `lint`、`test`、`build`) |
| `contents` | string | コマンド、指示、またはメモを自由形式のテキストで記述                       |

`name` フィールドはラベルです。慣例として、`lint`、`test`、`build` が標準的な名前です。Devin は自身の作業を検証する際に、これらを参照します。任意のカスタム名で、追加の Knowledge アイテムを作成できます。

```yaml theme={null}
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
```

<div id="post-build">
  ## post-build
</div>

`post-build` セクションは、**org レベルおよび Enterprise レベルのブループリントでのみ**利用できます (リポジトリレベルのブループリントではサポートされていません) 。このセクションのステップは、ビルド中に**すべてのリポジトリのクローンと、それらの `initialize` ステップおよび `maintenance` ステップの完了後**、ヘルスチェックとスナップショットイメージの作成より前に実行されます。そのため、環境全体が組み上がった状態を必要とする、リポジトリ横断の検証やヘルスチェックに適しています。

環境全体がそろった状態でビルドの後半に実行されるため、`post-build` ステップでは、クローンされたすべてのリポジトリと、Enterprise、組織、repo の各ブループリントによってインストールされたすべてのツールを参照できます。

```yaml theme={null}
post-build: |
  # 構築済みのEnvironmentが正常であることを確認する
  node --version
  python --version
  test -d ~/repos/my-service
```

また、構造化すると次のようになります：

```yaml theme={null}
post-build:
  - name: "Verify toolchain"
    run: |
      node --version
      uv --version

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

<Warning>
  `post-build` ステップは、**終了コードが 0 以外だとビルドを失敗にします**。`post-build` ステップが 0 以外で終了すると、ビルドは失敗として扱われ、スナップショットイメージは生成されません。これを利用すれば、ヘルスチェックを通過した場合にのみスナップショットを作成できます。ただし、不安定なチェックでビルドが止まらないよう、コマンドは確実に動作するものにしてください。
</Warning>

<Info>
  `post-build` ステップでは、`initialize` や `maintenance` と同じ [step types](#step-types) (シェルの `run` コマンドと GitHub Actions の `uses`) を使用し、ホームディレクトリ (`~`) から実行されます。
</Info>

<div id="clone">
  ## clone
</div>

**リポジトリレベルのブループリント**では、省略可能な`clone`セクションで、Devin がリポジトリをスナップショットにクローンする際に使われるデフォルト設定を上書きできます。すべてのフィールドは省略可能で、指定しない場合は現在の動作を維持する適切なデフォルト設定が適用されます。

```yaml theme={null}
clone:
  path: my-project        # ~/repos/ 以下のクローン先（デフォルト: リポジトリの短縮名）
  ref: develop            # チェックアウトするブランチまたはタグ（デフォルト: リポジトリのデフォルトブランチ）
  depth: 1                # 0 = 全履歴、N = --depth N（デフォルト: 0）
  tags: false             # false の場合 --no-tags を渡す（デフォルト: true）
  submodules: recursive   # true / false / "recursive"（デフォルト: true）
  lfs: false              # false の場合、クローン時に GIT_LFS_SKIP_SMUDGE=1 を設定（デフォルト: true）
```

| フィールド        | 型                     | デフォルト           | 説明                                                                                          |
| ------------ | --------------------- | --------------- | ------------------------------------------------------------------------------------------- |
| `path`       | string                | リポジトリの短縮名       | `~/repos/` 配下の既定のクローン先ディレクトリを上書きします。同じ snapshot 内のリポジトリ全体で一意である必要があります。                     |
| `ref`        | string                | repo のデフォルトブランチ | クローン後にチェックアウトするブランチまたはタグです。ここではコミット SHA はサポートされていません。                                       |
| `depth`      | int                   | `0`             | クローンの深さです。`0` は完全な履歴をクローンします。正の値を指定すると、浅いクローンのために `--depth N` が渡されます。                       |
| `tags`       | bool                  | `true`          | `false` の場合、Git タグの取得をスキップするために `--no-tags` が渡されます。                                         |
| `submodules` | bool or `"recursive"` | `true`          | `true` または `"recursive"` の場合、`--recurse-submodules` が渡されます。`false` の場合、サブモジュールは完全にスキップされます。 |
| `lfs`        | bool                  | `true`          | `false` の場合、クローン中の Git LFS オブジェクトのダウンロードをスキップするために `GIT_LFS_SKIP_SMUDGE=1` が設定されます。         |

<Info>
  `clone` は **リポジトリレベル** ブループリントでのみ有効です。これは、その特定の repo を snapshot にどのようにクローンするかを制御します。org レベル または enterprise-level のブループリントでは効果はありません。
</Info>

<div id="step-types">
  ## step types
</div>

`initialize`、`maintenance`、または `post-build` の各ステップでは、シェルコマンド (`run`) または GitHub Actions (`uses`) の 2 種類のいずれかを利用します。

<div id="shell-commands-run">
  ### シェルコマンド (`run`)
</div>

bash で任意のシェルコマンドを実行します。

```yaml theme={null}
- name: "Install dependencies"
  run: |
    npm install
    pip install -r requirements.txt
```

| フィールド  | 型                 | 説明                 |
| ------ | ----------------- | ------------------ |
| `name` | string (optional) | ステップ用の、人が読んでわかるラベル |
| `run`  | string            | 実行するシェルコマンド        |
| `env`  | map (optional)    | このステップ用の追加の環境変数    |

**実行の詳細:**

* コマンドは bash で実行されます。複数行スクリプト内のいずれかのコマンドが失敗すると、そのステップ全体が直ちに停止します。
* org レベルのブループリントはホームディレクトリ (`~`) で実行されます。
* リポジトリレベルのブループリントは、クローンされたリポジトリのルートディレクトリで実行されます。
* 各ステップのタイムアウトは 1 時間です。
* シークレットは自動的に環境変数として利用できます。

<div id="github-actions-uses">
  ### GitHub Actions (`uses`)
</div>

Node.js ベースの GitHub Actions をブループリント内で直接実行できます:

```yaml theme={null}
- name: "Install Python"
  uses: github.com/actions/setup-python@v5
  with:
    python-version: "3.12"
```

| Field  | Type              | 説明                 |
| ------ | ----------------- | ------------------ |
| `name` | string (optional) | ステップの表示名           |
| `uses` | string            | GitHub Action の参照先 |
| `with` | map (optional)    | アクションの入力パラメータ      |
| `env`  | map (optional)    | このステップ用の追加の環境変数    |

**Action 参照形式:**

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

`github.com/` プレフィックスと `@<ref>` サフィックスは、どちらも必須です。ref は通常、`v5` のようなバージョンタグです。

**よく利用されるアクション:**

| Action                                      | 目的               | 例 `with`                                        |
| ------------------------------------------- | ---------------- | ----------------------------------------------- |
| `github.com/actions/setup-python@v5`        | Python をインストール   | `python-version: "3.12"`                        |
| `github.com/actions/setup-node@v4`          | Node.js をインストール  | `node-version: "20"`                            |
| `github.com/actions/setup-go@v5`            | Go をインストール       | `go-version: "1.22"`                            |
| `github.com/actions/setup-java@v4`          | Java/JDK をインストール | `java-version: "21"`, `distribution: "temurin"` |
| `github.com/gradle/actions/setup-gradle@v4` | Gradle をインストール   | (なし)                                            |
| `github.com/ruby/setup-ruby@v1`             | Ruby をインストール     | `ruby-version: "3.3"`                           |

<Warning>サポートされているのは **Node.js ベース** の GitHub Actions のみです。Composite アクションと Docker ベースのアクションはサポートされていません。</Warning>

**`with` の値の仕組み:**

`with` で渡した値は、GitHub Actions のワークフローと同じ規則に従って、アクションへの入力として与えられます。すべての値は文字列に変換されます。

```yaml theme={null}
with:
  python-version: "3.12"
  check-latest: true
  cache: "pip"
```

**アクションによる変更の伝播方法：**

アクションは、後続のステップで使用される環境を変更できます。たとえば、`setup-python` は Python の実行ファイルを `PATH` に追加するため、それ以降のすべてのステップと `maintenance` で引き続き利用できます。

<div id="run-vs-uses-which-to-use">
  ### run と uses: どちらを使うべきか
</div>

| `run` を使うのはこんな場合...              | `uses` を使うのはこんな場合...                           |
| -------------------------------- | ---------------------------------------------- |
| システムパッケージをインストールする場合 (`apt-get`) | 言語ランタイム (Python、Node、Go、Java、Ruby) をセットアップする場合 |
| プロジェクト固有のスクリプトを実行する場合            | 必要な処理に対応する公式の GitHub Action がある場合              |
| ファイルや環境を設定する場合                   | バージョン管理やキャッシュを自動で処理したい場合                       |
| コマンドがシンプルで自己完結している場合             | GitHub Actions のワークフローでも同じ Action を使う場合        |

実際には、ほとんどの設定で、言語ランタイムには `uses` を使い、それ以外には `run` を使います。

<div id="environment-variables-and-secrets">
  ## 環境変数とシークレット
</div>

<div id="step-level-environment-variables">
  ### ステップごとの環境変数
</div>

どのステップでも、`env` フィールドを使って追加の環境変数を定義できます。

```yaml theme={null}
- run: pip install -r requirements.txt
  env:
    PIP_INDEX_URL: "https://pypi.example.com/simple/"
    PIP_BREAK_SYSTEM_PACKAGES: "1"
```

これらはそのステップ内でのみ有効で、後続のステップには引き継がれません。

<div id="cross-step-environment-variables-envrc">
  ### ステップ間の環境変数 (`$ENVRC`)
</div>

ステップ間で環境変数を引き継ぐには、`$ENVRC` ファイルに書き込みます。

```yaml theme={null}
- name: "Set shared variables"
  run: |
    echo "DATABASE_URL=postgresql://localhost:5432/myapp" >> $ENVRC
    echo "APP_ENV=development" >> $ENVRC
```

`$ENVRC` に書き込まれた変数は自動的にエクスポートされ、後続のすべての
ステップおよび現在のビルドで生成された Devin セッションで利用できます。これは、
GitHub Actions の `$GITHUB_ENV` と同様の仕組みです。

これは `PATH` にも当てはまります。標準的でないディレクトリにツールをインストールした場合
(`/usr/bin` または `/usr/local/bin` 以外の場所) 、後続のステップやリポジトリレベルのブループリントが
そのバイナリを見つけられるよう、`$ENVRC` に追記してください。

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

`run:` ブロック内で単に `export PATH=...` を実行しても、影響するのはそのステップのシェルだけです。
各ステップは新しいシェルプロセスを開始するため、`$ENVRC` に書き込まれない
`PATH` の変更は失われます。

<Info>
  `uses:` actions (例: `actions/setup-node`) は、追加した `PATH` を自動的に `$ENVRC`
  に反映します — これを手動で行う必要があるのは `run:` ステップだけです。
</Info>

`$ENVRC` は、差分ビルド を含むすべてのビルドの開始時にリセットされます。
あるビルド中に書き込まれた値は、次のビルドでは利用できません。特に、
継承された ワークスペース は `maintenance` のみを実行するため、親
ビルドで `initialize` が `$ENVRC` に書き込んだ `PATH` やその他の変数は利用
できません。`maintenance` に必要な環境は、
`maintenance` 自体の中で設定してください。

<script src="/anchor-scroll-fix.js" />

<div id="secrets">
  ### シークレット
</div>

Devin UI (各ブループリントエディタの **Secrets** タブから) で設定したシークレットは、自動的に環境変数として注入されます。ブループリント で宣言する必要はありません。名前で参照するだけです (例: `$MY_SECRET`) 。

シークレットは、ビルド中に各ステップが実行される前に毎回注入され、**さらに** 各セッションの開始時にも再度注入されます。シークレット自体はスナップショットイメージから除去されるため、認証情報が保存済みのマシンイメージに埋め込まれることはありません。

* **組織のシークレット**: 組織内のすべての ブループリント にあるすべてのステップで、環境変数として利用できます。これらは組織全体のブループリントエディタの **Secrets** タブで設定します。
* **Enterprise のシークレット**: 組織のシークレットとマージされます (同名のシークレットが競合した場合は、組織のシークレットが優先されます) 。Enterprise 内のすべての組織で利用できます。
* **リポジトリのシークレット**: リポジトリごとのファイル `/run/repo_secrets/{owner/repo}/.env.secrets` に書き込まれます。ビルド中は、そのリポジトリの ブループリント のステップが実行される前に、リポジトリのシークレットが自動的に `source` されます。セッション時には、Devin がそのリポジトリで作業するときにそれらを `source` します。これらは、リポジトリのブループリントエディタの **Secrets** タブで設定します。

<Info>
  **ビルド専用のシークレット**: 「build only」としてマークされたシークレットは、スナップショットのビルド中は利用できますが、スナップショットが保存される前に削除されます。これは、ビルド時にのみ必要な認証情報 (例: `initialize` 中に非公開アーティファクトをダウンロードする場合) に利用してください。
</Info>

<Warning>
  `maintenance` はビルド中に実行されます。セッション開始時には、`maintenance` コマンドがエージェントに提示され (自動実行はされません) 、必要に応じてエージェントが再実行することがあります。`maintenance` ステップが設定ファイル (例: `~/.m2/settings.xml`, `~/.npmrc`) にシークレットを書き込むと、それらのファイルはスナップショットに組み込まれます。認証情報を書き込むステップは、定期的なビルド中に更新されるよう `initialize` ではなく `maintenance` に配置してください。ただし、書き込まれたファイルはイメージ内に保持される点に注意してください。最大限の安全性を確保するには、認証情報をディスクに書き込む代わりに、環境変数または `$ENVRC` を利用してください。
</Warning>

<div id="file-attachments">
  ### ファイルの添付
</div>

ブループリント エディタから、ファイル (`.npmrc`、`settings.xml`、設定ファイルなど) をアップロードできます。アップロードされたファイルは `~/.files/` に書き込まれ、各ファイルのパスを指す環境変数が設定されます。

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

変数名はファイル名に由来し、英数字以外の文字はアンダースコアに置き換えられ、先頭に `FILE_` が付きます。

ブループリントのステップでファイルを添付する:

```yaml theme={null}
maintenance:
  - name: "Configure Maven"
    run: |
      mkdir -p ~/.m2
      cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml
```

<div id="git-backed-blueprints">
  ## Git連携のブループリント
</div>

ブループリントは、リポジトリ内に `.devin/blueprint.yaml` ファイルとして直接保存し、API または UI から同期できます。セットアップ手順と詳細については、[Git連携のブループリント](/ja/onboard-devin/environment/git-backed-blueprints) を参照してください。

<div id="complete-example">
  ## 完全な例
</div>

<Info>
  ブループリントが階層 (enterprise → org → repo) をまたいでどのように組み合わされるか、ビルド ステータス、リポジトリの状態、再ビルドのトリガーになる条件については、宣言的構成ページの[ビルドと
  セッション](/ja/onboard-devin/environment/blueprints#builds-and-sessions)を参照してください。
</Info>

<div id="org-wide-blueprint">
  ### 組織全体のブループリント
</div>

組織内のすべてのリポジトリで必要となる共有ツールです。これは最初に (Enterprise ブループリントがある場合はその後に) 、ホームディレクトリで実行されます。

```yaml theme={null}
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
```

<div id="repo-level-blueprint">
  ### リポジトリレベルのブループリント
</div>

Node.js + Python のモノレポ向けの、プロジェクト固有のセットアップです。これは組織全体向けのブループリントの後に、リポジトリディレクトリ内で実行されます。

```yaml theme={null}
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
```