feat(cli): set up AI tooling in trigger init and add getting-started skill#3872
feat(cli): set up AI tooling in trigger init and add getting-started skill#3872ericallam wants to merge 2 commits into
Conversation
…skill init now offers the MCP server and agent skills together as one AI-tooling step, then lets you scaffold with the CLI or hand off to your assistant. The new getting-started skill is the bootstrap recipe that hand-off path uses: install the SDK, write trigger.config.ts, create a first task, run dev. Shared prompt-once gating means trigger dev no longer asks about skills separately.
🦋 Changeset detectedLatest commit: d07913f The changes in this PR will be included in the next version bump. This PR includes changesets to release 25 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThis PR adds optional AI tooling support to the 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
The "let my AI set it up" hand-off was gated on what the user selected, not what installed, so a failed skills install still offered it and claimed the getting-started skill was ready. Gate it on actual installs and describe only the tooling that landed. Also fix an inverted profile flag in the next-steps message that printed `--profile undefined` when no profile was set.
@trigger.dev/build
trigger.dev
@trigger.dev/core
@trigger.dev/plugins
@trigger.dev/python
@trigger.dev/react-hooks
@trigger.dev/redis-worker
@trigger.dev/rsc
@trigger.dev/schema-to-json
@trigger.dev/sdk
commit: |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 1563b5df-2a74-4486-b2ad-fc5f71b9b4ac
📒 Files selected for processing (1)
packages/cli-v3/src/commands/init.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (34)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: internal / 🧪 Unit Tests: Internal (4, 12)
- GitHub Check: internal / 🧪 Unit Tests: Internal (12, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: internal / 🧪 Unit Tests: Internal (8, 12)
- GitHub Check: internal / 🧪 Unit Tests: Internal (11, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (2, 10)
- GitHub Check: internal / 🧪 Unit Tests: Internal (9, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: internal / 🧪 Unit Tests: Internal (7, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: internal / 🧪 Unit Tests: Internal (10, 12)
- GitHub Check: internal / 🧪 Unit Tests: Internal (3, 12)
- GitHub Check: internal / 🧪 Unit Tests: Internal (5, 12)
- GitHub Check: internal / 🧪 Unit Tests: Internal (2, 12)
- GitHub Check: internal / 🧪 Unit Tests: Internal (6, 12)
- GitHub Check: internal / 🧪 Unit Tests: Internal (1, 12)
- GitHub Check: e2e-webapp / 🧪 E2E Tests: Webapp
- GitHub Check: packages / 🧪 Unit Tests: Packages (2, 3)
- GitHub Check: packages / 🧪 Unit Tests: Packages (1, 3)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: packages / 🧪 Unit Tests: Packages (3, 3)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: audit
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Build and publish previews
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects insteadImport from
@trigger.dev/sdkwhen writing Trigger.dev tasks. Never use@trigger.dev/sdk/v3or deprecatedclient.defineJob
Files:
packages/cli-v3/src/commands/init.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
**/*.{ts,tsx,js,jsx}: Prefer static imports over dynamic imports. Only use dynamicimport()when circular dependencies cannot be resolved, code splitting is needed for performance, or the module must be loaded conditionally at runtime
Import subpaths only frompackages/core(@trigger.dev/core), never import from the root
Files:
packages/cli-v3/src/commands/init.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
**/*.ts: When creating or editing OTEL metrics (counters, histograms, gauges), ensure metric attributes have low cardinality by using only enums, booleans, bounded error codes, or bounded shard IDs
Do not use high-cardinality attributes in OTEL metrics such as UUIDs/IDs (envId, userId, runId, projectId, organizationId), unbounded integers (itemCount, batchSize, retryCount), timestamps (createdAt, startTime), or free-form strings (errorMessage, taskName, queueName)
When exporting OTEL metrics via OTLP to Prometheus, be aware that the exporter automatically adds unit suffixes to metric names (e.g., 'my_duration_ms' becomes 'my_duration_ms_milliseconds', 'my_counter' becomes 'my_counter_total'). Account for these transformations when writing Grafana dashboards or Prometheus queries
Files:
packages/cli-v3/src/commands/init.ts
packages/cli-v3/src/commands/**/*
📄 CodeRabbit inference engine (packages/cli-v3/CLAUDE.md)
CLI command definitions should be located in
src/commands/
Files:
packages/cli-v3/src/commands/init.ts
packages/cli-v3/src/commands/init.ts
📄 CodeRabbit inference engine (packages/cli-v3/CLAUDE.md)
Implement
init.tscommand insrc/commands/for project initialization
Files:
packages/cli-v3/src/commands/init.ts
**/*.{js,ts,tsx,jsx,css,json,md}
📄 CodeRabbit inference engine (AGENTS.md)
Use Prettier for code formatting and run
pnpm run formatbefore committing
Files:
packages/cli-v3/src/commands/init.ts
🧠 Learnings (5)
📚 Learning: 2026-03-22T13:26:12.060Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: apps/webapp/app/components/code/TextEditor.tsx:81-86
Timestamp: 2026-03-22T13:26:12.060Z
Learning: In the triggerdotdev/trigger.dev codebase, do not flag `navigator.clipboard.writeText(...)` calls for `missing-await`/`unhandled-promise` issues. These clipboard writes are intentionally invoked without `await` and without `catch` handlers across the project; keep that behavior consistent when reviewing TypeScript/TSX files (e.g., usages like in `apps/webapp/app/components/code/TextEditor.tsx`).
Applied to files:
packages/cli-v3/src/commands/init.ts
📚 Learning: 2026-03-22T19:24:14.403Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:200-204
Timestamp: 2026-03-22T19:24:14.403Z
Learning: In the triggerdotdev/trigger.dev codebase, webhook URLs are not expected to contain embedded credentials/secrets (e.g., fields like `ProjectAlertWebhookProperties` should only hold credential-free webhook endpoints). During code review, if you see logging or inclusion of raw webhook URLs in error messages, do not automatically treat it as a credential-leak/secrets-in-logs issue by default—first verify the URL does not contain embedded credentials (for example, no username/password in the URL, no obvious secret/token query params or fragments). If the URL is credential-free per this project’s conventions, allow the logging.
Applied to files:
packages/cli-v3/src/commands/init.ts
📚 Learning: 2026-05-18T08:21:27.694Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3632
File: apps/webapp/sentry.server.ts:4-21
Timestamp: 2026-05-18T08:21:27.694Z
Learning: When handling Prisma error P1001 ("Can't reach database server") in TypeScript, don’t assume a single error shape. Prisma can surface P1001 via two different error classes/fields: `PrismaClientKnownRequestError` exposes it as `err.code === "P1001"` (common during mid-query connection drops), while `PrismaClientInitializationError` exposes it as `err.errorCode === "P1001"` (common on client startup failure). Therefore, predicates should use `err.code === "P1001" || err.errorCode === "P1001"`. Do not flag `err.code === "P1001"` as “unreachable/never matches,” as it is expected in production.
Applied to files:
packages/cli-v3/src/commands/init.ts
📚 Learning: 2026-05-18T08:21:27.694Z
Learnt from: d-cs
Repo: triggerdotdev/trigger.dev PR: 3632
File: apps/webapp/sentry.server.ts:4-21
Timestamp: 2026-05-18T08:21:27.694Z
Learning: When handling Prisma errors for P1001 ("Can't reach database server"), do not assume it only appears under a single property name. Prisma may surface P1001 via either `PrismaClientKnownRequestError` (`err.code === "P1001"`, e.g., mid-query connection drops) or `PrismaClientInitializationError` (`err.errorCode === "P1001"`, e.g., client startup connection failure). To reliably detect the condition, check `err.code === "P1001" || err.errorCode === "P1001"`, and avoid review rules that would incorrectly flag `err.code === "P1001"` as unreachable/never-matching.
Applied to files:
packages/cli-v3/src/commands/init.ts
📚 Learning: 2026-06-04T18:16:35.386Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3836
File: apps/supervisor/src/backpressure/backpressureMonitor.ts:3-5
Timestamp: 2026-06-04T18:16:35.386Z
Learning: When reviewing TypeScript in this repo, apply the rule “prefer type aliases over interfaces” only to data/object shapes and union/intersection type modeling. If an interface is being used as a behavioral contract for collaborators to implement (e.g., method-shape interfaces that define required behavior, such as `BackpressureLogger` / `BackpressureSignalSource` in `apps/supervisor/src/backpressure/backpressureMonitor.ts`), keep it as an `interface` and do not flag it as a type-alias-vs-interface violation.
Applied to files:
packages/cli-v3/src/commands/init.ts
🔇 Additional comments (7)
packages/cli-v3/src/commands/init.ts (7)
176-180: LGTM!
213-213: LGTM!
348-348: LGTM!
136-147: LGTM!
149-172: LGTM!
192-194: LGTM!
186-190: installSkillsFromInit returnsPromise<boolean, so theinstalled === truecheck is consistent. Inpackages/cli-v3/src/commands/skills.ts,installSkillsFromInit(...): Promise<boolean>matches the expectation used inpackages/cli-v3/src/commands/init.ts(lines 186-190).
| installedSkills | ||
| ? "Your AI tooling is ready. Ask your assistant to set up Trigger.dev and it will use the getting-started skill to add the SDK, config, and your first task." | ||
| : "The MCP server is installed. Ask your assistant to set up Trigger.dev using the MCP server." |
There was a problem hiding this comment.
Outro message should describe all installed tooling.
When both installedSkills and installedMcp are true, the current ternary only mentions the getting-started skill. The user should be informed about both tools being available.
💬 Suggested improvement
- installedSkills
- ? "Your AI tooling is ready. Ask your assistant to set up Trigger.dev and it will use the getting-started skill to add the SDK, config, and your first task."
- : "The MCP server is installed. Ask your assistant to set up Trigger.dev using the MCP server."
+ installedSkills && installedMcp
+ ? "Your AI tooling is ready. Ask your assistant to set up Trigger.dev—it can use the getting-started skill and the MCP server to add the SDK, config, and your first task."
+ : installedSkills
+ ? "Your AI tooling is ready. Ask your assistant to set up Trigger.dev and it will use the getting-started skill to add the SDK, config, and your first task."
+ : "The MCP server is installed. Ask your assistant to set up Trigger.dev using the MCP server."📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| installedSkills | |
| ? "Your AI tooling is ready. Ask your assistant to set up Trigger.dev and it will use the getting-started skill to add the SDK, config, and your first task." | |
| : "The MCP server is installed. Ask your assistant to set up Trigger.dev using the MCP server." | |
| installedSkills && installedMcp | |
| ? "Your AI tooling is ready. Ask your assistant to set up Trigger.dev—it can use the getting-started skill and the MCP server to add the SDK, config, and your first task." | |
| : installedSkills | |
| ? "Your AI tooling is ready. Ask your assistant to set up Trigger.dev and it will use the getting-started skill to add the SDK, config, and your first task." | |
| : "The MCP server is installed. Ask your assistant to set up Trigger.dev using the MCP server." |
| await installSkills(manifest, opts); | ||
|
|
||
| return true; |
There was a problem hiding this comment.
🟡 installSkillsFromInit returns true even when no skills were actually installed on disk
installSkillsFromInit at packages/cli-v3/src/commands/skills.ts:248 unconditionally returns true as long as the skills manifest was loaded, regardless of whether installSkills actually wrote any files. When the user selects "Unsupported target" as their only target during the interactive skills flow, installSkills calls handleUnsupportedTargetOnly() (a log message) and returns without installing anything (packages/cli-v3/src/commands/skills.ts:256-258). Back in init.ts:190, installedSkills is set to true, which causes the "How do you want to set up your project?" prompt to appear (init.ts:219). If the user then picks "ai", the outro message incorrectly tells them the getting-started skill is ready (init.ts:238-239), when in reality no skills were written to disk.
Prompt for agents
The problem is that installSkillsFromInit always returns true when a manifest is found, even if installSkills didn't actually install any skills on disk. This misleads init.ts into thinking skills were installed and offering the AI handoff option.
Two possible fixes:
1. Have installSkills return an indicator of whether any skills were actually installed (e.g., return the number of installations or a boolean), and propagate that through installSkillsFromInit's return value.
2. Alternatively, change installSkillsFromInit to inspect whether installSkills actually installed anything by having installSkills return its results array, then check if any installations occurred before returning true.
The key function chain is: init.ts calls installSkillsFromInit (skills.ts:236) which calls installSkills (skills.ts:251). installSkills already has the results array and checks results.some(r => r.installations.length > 0 || r.pointer) internally. That same check could be used to determine the return value of installSkillsFromInit.
Was this helpful? React with 👍 or 👎 to provide feedback.
| return; | ||
| } |
There was a problem hiding this comment.
🚩 MCP install failure aborts init even after successful skills installation
When the user selects both skills and MCP, and skills install successfully but MCP fails, the outro() + return at lines 209-210 aborts the entire init. Skills are installed on disk but the project isn't scaffolded (no trigger.config.ts, no SDK installed). The user would need to re-run trigger init, at which point hasSeenMCPInstallPrompt is true so it goes straight to CLI scaffolding — so this is recoverable. This pattern is carried over from the old MCP-only flow, but the impact is wider now since skills may have been installed. Consider catching the MCP error and continuing to the setupChoice / CLI scaffolding instead of aborting.
(Refers to lines 208-211)
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
trigger initnow sets up your AI coding assistant as part of project setup. Instead of the old either/or "MCP or CLI" prompt, it offers the MCP server and agent skills together, then asks whether to scaffold with the CLI or let your assistant do it.A new
getting-startedagent skill backs that hand-off: it teaches the assistant the bootstrap recipe (install the SDK, writetrigger.config.ts, scaffold a first task, wire tsconfig/gitignore, runtrigger dev) and is explicit about the two steps that genuinely need a human (trigger loginand copying the DEV secret key from the dashboard). It ships in the CLI alongside the existing skills, version-matched to your SDK.Prompt-once gating is shared, so opting in or out during
initmeanstrigger devwon't ask about skills again.