Communitygithub.com

lenneTech/lt-cli リファレンス

lenne.tech CLI（`lt`）のリファレンス：`lt fullstack init/update/convert-mode`、`lt git`、`lt server`、`lt deployment`、`lt dev`（Caddyによる並列プロジェクト管理）。`lt`サブコマンド、「lenne.tech CLI」、「--noConfirm」、「convert-mode」、「npm mode」/「vendor mode」、または「Caddy tunnel」でアクティブ化。NestJSモジュールやプロパティの手書き作成には使用しません（`generating-nest-servers`を使用）。Vue/Nuxtコードには使用しません（`developing-lt-frontend`を使用）。

lt-cli リファレンス とは？

このスキルは、lenne.tech CLI（`lt`）の包括的なリファレンスを提供します。主に`lt fullstack init`、`lt git`、`lt dev`、`lt server`、`lt deployment`、`lt ticket`などの主要コマンドをカバーしており、Claude Codeや同様のAIエージェントがこれらのコマンドを安全かつ効果的に使用するための注意点や落とし穴を詳細に解説しています。特に、`lt fullstack init`で`--noConfirm`を忘れるとプロンプトがブロックされる問題や、`--api-link`がシンボリックリンクを作成する挙動、`lt git reset`の破壊性など、AIエージェントが遭遇しやすいトラブルを事前に回避できます。このスキルは、`lt`コマンドが使用されるあらゆるシナリオで自動的にアクティブ化され、デベロッパーとAIエージェントの両方が正しいコマンド構文と期待される動作を理解できるようにします。`--next`フラグの使用時には、互換性のないコマンドや生成物が発生する可能性があるため、明確な境界線が定義されています。`lt dev`コマンドは、Caddyを介してプロジェクトごとに独立したHTTPS URLとポートを提供し、複数のプロジェクトを並行して実行できるようにします。このスキルはmacOSとLinuxの両方をサポートしており、macOSの長い`$TMPDIR`によるNuxt SSRのクラッシュやHMR WebSocketポートの競合など、OS固有の注意点も詳述しています。

対応✓Claude Code~Codex CLI~Cursor
Part ofDesign & UI
npx skills add https://github.com/lenneTech/claude-code/tree/HEAD/plugins/lt-dev/skills/using-lt-cli
オリジナルを見る→すべてのスキルを見る

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

ドキュメント

LT CLI リファレンス

注意点（Gotchas）

  • lt fullstack init を --noConfirm なしで実行すると、Claude Codeが永久にブロックされる — インタラクティブなプロンプト（プロジェクト名、git init、テンプレート選択）が標準入力の入力を待ちます。Claude Codeはそれらに応答できず、セッションは「Unfurling...」のままトークンを消費しません。Claude Codeからlt CLIを呼び出す際は、--noConfirm と必要なフラグ（--name X --frontend nuxt --git false）をすべて渡してください。
  • --api-link と --frontend-link はコピーではなくシンボリックリンクを作成する — テンプレートのチェックアウト（nest-server-starter、nuxt-base-starter）への変更は、このマシンのどこに存在していても、リンク先のプロジェクトに即座に影響します。これはフレームワーク開発には便利な機能ですが、コピーを期待する開発者にとっては驚きです。--api-link を使用する場合は、プロジェクトのREADMEにその旨を記載してください。
  • lt git reset は破壊的で元に戻せない — CLIメニューで安全な lt git get の隣にあります。reset は git reset --hard と強制プルを実行し、確認なしですべてのローカル変更を破棄します。プッシュされていない作業があるブランチでは決して実行しないでください。git stash + lt git get を推奨します。
  • lt server object X --controller はRESTを生成し、GraphQLは生成しない — デフォルトはRESTです。GraphQLプロジェクトの場合は --resolver を使用してください。CLIは既存のプロジェクトパターンから自動検出しません。明示的に指定する必要があります。
  • lt fullstack convert-mode はソースツリーを書き換える — npm モードと vendor モードの切り替えにより、フレームワークコードを src/core/（API）または app/core/（App）に移動します。この操作は元に戻せますが、実行中は冪等ではありません。開始する前に必ずコミットし、変換に失敗した場合は git reset でロールバックできるようにしてください。
  • --next は実験的であり、lt server module/object/addProp/test/permissions とは互換性がない — lt server create --next または lt fullstack init --next を使用すると、nest-server-starter の代わりに nest-base（Bun + Prisma 7 + Postgres + Better-Auth）からAPIがクローンされます。下流のジェネレーターはクラシックなnest-serverレイアウト（Mongooseモデル、src/server/modules/ など）をターゲットとしており、nest-base プロジェクトでは機能しません。これはグリーンフィールドのプロトタイピングにのみ使用し、本番環境ではデフォルトのテンプレートを推奨します。
  • macOS: 長い $TMPDIR が lt dev up でのNuxt SSRを壊す — macOSでは、$TMPDIR は長いユーザーごとのパス（/var/folders/…、多くの場合 >~49文字）です。Nuxt 4.4.7のvite-nodeは、このパスの下にUnixドメインソケットパスを構築し、OSの104文字制限を超えるため、SSRが500エラーでクラッシュします。回避策：短いtmpディレクトリで開始するには、TMPDIR=/tmp lt dev up を使用します。（Linuxの $TMPDIR=/tmp は短いため、この問題はmacOSでのみ発生します。）
  • macOS: HMR WebSocketポート24678が並列 lt dev プロジェクト間で競合する — 2つの lt dev プロジェクトが同時に実行されると、両方ともViteのHMR WSポート24678にバインドしようとします。vite.server.hmr.port はNuxt 4.4.7では無視されるため、設定で再割り当てできません。これは致命的ではありません — SSRの再コンパイルは引き続き機能します。2番目のプロジェクトでのライブHMRプッシュのみが影響を受けます。ページをリロードして変更を取得してください。

スキル境界

ユーザーの意図正しいスキル
「lt fullstack init」このスキル
「lt git get feature-branch」このスキル
「lt server create my-project」このスキル
「lt server module / object / addProp」generating-nest-servers
「lt server permissions」generating-nest-servers
「NestJSモジュールを作成する」generating-nest-servers
「Vueコンポーネントを構築する」developing-lt-frontend
「lt deployment create」このスキル（lt deployment create コマンドを参照）
「TurboOpsにデプロイする / 公開する / turboデプロイ / デプロイメントステージ」deploying-to-turboops

lt fullstack init 後：

  • バックエンド作業（projects/api/）→ generating-nest-servers
  • フロントエンド作業（projects/app/）→ developing-lt-frontend

コマンド

lt git get — ブランチのチェックアウト/作成

lt git get <branch-name>    # エイリアス: lt git g
  1. ブランチがローカルに存在する → 切り替える
  2. ブランチがリモートに存在する → チェックアウトして追跡する
  3. どちらも存在しない → 現在のブランチから新しいブランチを作成する

lt git reset — リモートにリセット

lt git reset

リモートから最新を取得し、現在のブランチを origin/<branch> にリセットします。破壊的 — すべてのローカル変更が失われます。

lt fullstack init — フルスタックワークスペースの作成

# 非対話型
lt fullstack init --name <Name> --frontend <angular|nuxt> --git <true|false> --noConfirm \
  [--git-link <URL>] [--api-link <path>] [--frontend-link <path>] [--next]
パラメータ必須説明
--nameはいワークスペース名（パスカルケース）
--frontendはいangular または nuxt
--gitはいgitを初期化: true / false
--noConfirmいいえ確認プロンプトをスキップ
--git-linkいいえGitリポジトリURL
--api-branchいいえnest-server-starter のブランチ
--frontend-branchいいえフロントエンドスターターのブランチ
--api-copy / --api-linkいいえローカルAPIテンプレート（コピー/シンボリックリンク）
--frontend-copy / --frontend-linkいいえローカルフロントエンドテンプレート（コピー/シンボリックリンク）
--nextいいえ実験的 — API用に nest-base（Bun + Prisma 7 + Postgres + Better-Auth）をクローンします。apiMode = Rest、frameworkMode = npm を強制し、ワークスペースインストールをスキップします（アプリは pnpm install、APIは bun install を手動で実行）。下流の lt server module/object/addProp/test は、結果のレイアウトと互換性がありません。

優先順位: --*-link > --*-copy > --*-branch > デフォルト（GitHubクローン）

作成される構造:

<workspace>/
├── projects/
│   ├── api/    ← nest-server-starter（または --next の場合は nest-base）
│   └── app/    ← nuxt-base-starter（または ng-base-starter）
├── package.json
└── .gitignore

作成後:

cd <workspace> && pnpm install
lt dev init                      # 冪等: ENVパッチ + 登録; マシンがまだセットアップされていない場合は、自動的に `lt dev install` を最初に実行します
lt dev up                        # Caddy経由で https://<slug>.localhost の背後でAPI + Appを起動

# --next の場合: サブプロジェクトごとにインストール、ワークスペースインストールは不要
cd <workspace>/projects/app && pnpm install
cd <workspace>/projects/api && bun install

（lt dev が使用されない場合は、デフォルトポート3000/3001で pnpm -r --parallel run start にフォールバックします。）

lt dev — 並列プロジェクトオーケストレーション（Caddy + HTTPS）

すべてのltプロジェクトを、Caddyを介して安定したHTTPS URL（<slug>.localhost、api.<slug>.localhost）で提供します。これにより、複数のプロジェクトが3000/3001で衝突したり、認証がクロスワイヤリングされたりすることなく、サイドバイサイドで実行できます。すべてのlt-monorepoまたはスタンドアロンAPI/Appプロジェクトでこれを使用してください。

lt dev install                   # マシンごとに1回: 専用のLaunchAgent/systemdユニット + Caddyfileスタブ + CAリマインダーをブートストラップします
lt dev uninstall [--purge]       # lt-devサービスを削除（--purge はCaddyfile + ログも削除）
lt dev init                      # プロジェクトごとに1回（冪等）: ENVパッチ + 登録
lt dev up                        # Caddyの背後でAPI + Appを起動
lt dev down                      # プロセスを停止 + Caddyブロックを削除（アイソレートされたテストスタックも破棄）
lt dev test                      # アイソレートされたPlaywright E2E: 並列スタック + 専用 `<slug>-test` DB、自動後片付け
lt dev test --shard              # 2つのアイソレートされたスタック全体でシャーディング（デフォルト — 安定したスイートスポット）
lt dev test --shard 3            # N個のアイソレートされたスタック全体でシャーディング（それぞれ独自のポート/Caddy/DB `<slug>-test-<i>`）
lt dev test --shard auto         # このマシンのCPU + RAMからNを決定（控えめ）
lt dev test down                 # アイソレートされたテストスタックを破棄（残骸なし）
lt dev status                    # このプロジェクトのURL + PID + ライブアップストリーム状態を表示（テストスタックを含む）
lt dev status --all              # 登録されたすべてのプロジェクトと実行状態をリスト
lt dev doctor                    # Caddy / CA / DNS / ポートの問題を診断
lt dev tunnel [--api]            # フォアグラウンドCloudflare Quick Tunnel: 公開 *.trycloudflare.com URL

各サブコマンドの機能:

  • install — マシンごとに1回。caddy がPATHにあることを確認し（ない場合は brew install caddy を提案）、~/.lenneTech/Caddyfile スタブを作成し、専用のLaunchAgent（macOS、~/Library/LaunchAgents/tech.lenne.lt-dev-caddy.plist）またはsystemd-userユニット（Linux）を書き込み、ブートストラップします。Caddy管理エンドポイント（:2019）が応答するまで最大8秒待機し、ファイルを検証し、sudo -E HOME="$HOME" caddy trust を実行するようにリマインダーを表示します（-E HOME="$HOME" は必須 — これがないとsudoはHOMEを /var/root に切り替え、CAインストールは静かに失敗します）。brew services start caddy は使用しません — そのplistは --config /opt/homebrew/etc/Caddyfile をハードコードしており、当社のCaddyfileの場所に対してクラッシュループします。自動チェーン: 初期化されていないlt-devプロジェクト内で実行すると、その後 init を実行します（--skip-init でオプトアウト）。
  • uninstall — install の対称的なカウンターパート。LaunchAgent / systemdユニットを取り出し、ユニットファイルを削除します。--purge を使用すると、~/.lenneTech/Caddyfile とcaddyログも削除します。caddyバイナリ自体は削除しません（必要に応じて brew uninstall caddy を使用）。
  • init（エイリアス migrate） — 冪等。プロジェクトIDを構築し（スラグ = package.json の「name」、モノレポレイアウトからのサブドメイン）、レガシーなハードコードされた port: 3000 / port: 3001 / Vite-proxyターゲット / Playwright URLを環境認識可能なバリアントにパッチし（デフォルトは維持）、~/.lenneTech/projects.json に永続化し、「Local Development (lt dev)」URLブロックをすべての CLAUDE.md ファイルに注入し、.lt-dev/ を .gitignore に追加します。自動チェーン: マシンがまだ準備されていない場合は、最初に install を実行します（--skip-install でオプトアウト）。
  • up — 内部アップストリームポート（4000以降、決して3000/3001ではない）を割り当て、reverse_proxy 127.0.0.1:<port> を使用してCaddyブロックをアップサート + リロードし、PORT、HOST=127.0.0.1 / NITRO_HOST=127.0.0.1（開発サーバーをIPv4に固定し、アップストリームが明確になるようにする）、BASE_URL、APP_URL、NUXT_API_URL、NUXT_PUBLIC_API_URL、NUXT_PUBLIC_SITE_URL、NUXT_PUBLIC_STORAGE_PREFIX、NUXT_PUBLIC_API_PROXY=false、APIのデータベース（MongoDB: NSC__MONGOOSE__URI; PostgreSQL / MySQL / MariaDB、lt CLI 1.54.0以降: NSC__DATABASE__URL と NSC__DATABASE__OWNER_URL。APIのみ、スタック独自のデータベースに対して、最初の起動時に所有者ロールとして作成されます。そのため、所有者はPostgreSQLでは CREATEDB、MySQL / MariaDBでは CREATE + GRANT OPTION が必要です。資格情報なしで ~/.lenneTech/projects.json の dbUrls の下に記録されます）、NODE_EXTRA_CA_CERTS（CaddyルートCA。これによりNuxt SSRフェッチがHTTPSを信頼する）、さらに NUXT_* 規則より前のプロジェクト用のレガシーエイリアス API_URL / SITE_URL をエクスポートします。次に、pnpm start（api）+ pnpm dev（app）をデタッチして起動します。プリフライトチェックでは、Caddyがない場合、Caddyデーモンがダウンしている場合、既存のセッションが生きている場合、内部ポートがバインドされている場合に起動を拒否します。ログは <root>/.lt-dev/{api,app}.log にあります。
  • down — 保存されたプロセスグループ（負のPID）にSIGTERMを送信し、子プロセス（Vite、Nestウォッチャーなど）もそれを受信するようにします。プロジェクトのCaddyブロックを削除し、リロードします。また、このプロジェクトのアイソレートされたテストスタック（lt dev test）もすべて破棄します。
  • test — アイソレートされたE2E。2番目の並列スタック（<slug>-test.localhost / api.<slug>-test.localhost、独自のポート + Caddyブロック + .lt-dev/.env.test ブリッジ）を専用のDB <slug>-test（開発用の <slug>-local やAPIテスト用の <slug>-e2e とは別）上に起動し、Playwrightスイートを実行し（グローバルセットアップは最初のテストの前にそのDBを1回リセット）、その後残骸なしで自動後片付けを行います。開発セッションと並行して実行され、開発セッションには決して触れません。--keep はそのままにします。lt dev test down で停止します。--api は代わりに（すでにアイソレートされた）APIテストを実行します。--debug = PWDEBUG+headed。-- <args> はPlaywrightに転送されます。--shard N はスイートを並列でN個の完全にアイソレートされたスタック（それぞれ独自のポート + Caddyブロック + DB <slug>-test-<i>）+ N個の --shard=i/N Playwrightプロセスに分割して実行します — ローカルCIパリティマトリックス。単に --shard はデフォルトで2になります（安定したスイートスポット: N≥3は一般的な開発マシンでパフォーマンスコアを過剰サブスクライブし、不安定になります）。--shard auto はCPU+RAMからNをサイジングします（控えめ）。ローカルシャードは1台のマシンを共有します（CIのシャードごとのコンテナとは異なります）。そのため、CLIは LT_DEV_TEST_SHARDS をエクスポートし、プロジェクトの playwright.config がその負荷の下でのみタイムアウトを緩和できるようにします（CIは高速のまま）。lt dev test down はすべてのシャードを回収します。このアイソレートされたセッションを出荷するlt CLIバージョンが必要です。
  • status / status --all — 現在のプロジェクト: サブドメイン → アップストリームポート、DB URI、セッションPID（生存/死亡）、ライブ lsof アップストリーム状態。--all: 登録されたすべてのプロジェクトを ●/○ インジケータ付きで表示。
  • doctor — CaddyがPATHにあるか、lt-dev LaunchAgent / systemdユニットがロードされているか、デーモンが実行中か、Caddyfileが有効か、ポート80/443が空いているかCaddyが保持しているか、*.localhost が解決するか（IPv4またはIPv6ループバック）、レジストリステータス。
  • tunnel — フォアグラウンドCloudflare Quick Tunnel: cloudflared tunnel --url https://<slug>.localhost --http-host-header <slug>.localhost --no-tls-verify。公開 *.trycloudflare.com URL（5-10秒）を出力し、Ctrl-Cまで実行されます。デフォルトではAppを公開します。--api はターゲットを切り替えます。localhostドメインの認証CookieはトンネルURLでは有効ではありません。ログインフローを成功させるには、トンネルURLをBetter-Authの trustedOrigins に追加してください。完全な外部使用のために、並行して2番目の lt dev tunnel --api を開始します。

起動バイナリのオーバーライドは LT_PNPM_BIN を介して行います（例: ラッパースクリプトを介したbunベースのプロジェクト用）。

lt ticket — 並列チケット開発環境

1つのプロジェクトの複数のチケット/機能に同時に取り組みます。それぞれが独自のgit worktree + 独自のアイソレートされた lt dev スタック（独自のURL、ポート、Caddyブロック、空のDB）を持つため、複数のチケットをブラウザテストおよびE2Eテストで並行して、相互影響なしにテストできます。

lt ticket start DEV-2200            # worktree（ブランチ feat/DEV-2200、origin/dev から）+ pnpm install + lt dev up

...（翻訳のため省略）

Individual skills in this repo

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

lenneTech/grilling-decisions

Round-based interview that settles every open decision with a human before implementation starts and ends in a decision record; triggers on "grill me" and "frag mich aus".

lenneTech/maintaining-lt-stack

Stack-wide maintenance and releases of the lt base repos ("Grund-Repos"): dependency order (nuxt-extensions to nuxt-base-starter, nest-server to nest-server-starter), the release recipe per repo, and the smoke test as release gate. Activates on "maintain stack", "release all repos", "stack release", "Grund-Repos aktualisieren", and behind /lt-dev:publish. NOT for a single npm package (use maintaining-npm-packages). NOT for nest-server upgrades inside customer projects (use nest-server-updating).

lenneTech/running-check-script

Runs the package.json check script (monorepo-aware) and auto-fixes until green, escalating audit findings, whenever work must prove runnability; triggers on "pnpm run check".

関連スキル

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community