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 3 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: d3f6f7b 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 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📜 Recent 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)
🧰 Additional context used📓 Path-based instructions (8)**/*.{ts,tsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.{ts,tsx,js,jsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.{test,spec}.{ts,tsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.ts📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
Files:
packages/cli-v3/src/commands/**/*📄 CodeRabbit inference engine (packages/cli-v3/CLAUDE.md)
Files:
**/*.test.{ts,tsx}📄 CodeRabbit inference engine (CLAUDE.md)
Files:
**/*.{js,ts,tsx,jsx,css,json,md}📄 CodeRabbit inference engine (AGENTS.md)
Files:
**/*.test.{js,ts,tsx}📄 CodeRabbit inference engine (AGENTS.md)
Files:
🧠 Learnings (7)📚 Learning: 2026-03-22T13:26:12.060ZApplied to files:
📚 Learning: 2026-03-22T19:24:14.403ZApplied to files:
📚 Learning: 2026-05-18T08:21:27.694ZApplied to files:
📚 Learning: 2026-05-18T08:21:27.694ZApplied to files:
📚 Learning: 2026-05-18T14:40:02.173ZApplied to files:
📚 Learning: 2026-05-18T14:40:02.173ZApplied to files:
📚 Learning: 2026-06-04T18:16:35.386ZApplied to files:
🔇 Additional comments (7)
WalkthroughThis PR adds optional AI tooling to 🚥 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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
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: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 are written to disk
installSkillsFromInit at packages/cli-v3/src/commands/skills.ts:271-284 returns true whenever the bundled manifest loads, regardless of whether any skill files were actually installed. If the user selects only "Unsupported target" in the resolveTargets multiselect, installSkills calls handleUnsupportedTargetOnly() (which just prints a link) and returns without writing anything. Back in packages/cli-v3/src/commands/init.ts:190, installedSkills is set to true, causing the AI hand-off prompt at line 219 to appear. If the user then chooses "ai" at line 236, they see "Your AI tooling is ready. Ask your assistant to set up Trigger.dev and it will use the getting-started skill…" — but no skill was actually installed, so the assistant won't find it.
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.
…dist stub
The skills loader resolved the package.json nearest the bundled code, which is
tshy's `dist/esm` dialect stub ({"type":"module"}), so it looked for skills in
`dist/esm/skills` (which does not exist) and reported "No agent skills found"
from every published build. It only worked when run from source via tsx. Walk
up to the first package.json with a name (the real package root) instead, which
resolves correctly both bundled and from source, and also fixes the version
stamp falling back to 0.0.0.
| and you are writing task code, switch to the authoring-tasks skill. | ||
| type: core | ||
| library: trigger.dev | ||
| library_version: "{{TRIGGER_SDK_VERSION}}" |
There was a problem hiding this comment.
🚩 SKILL.md contains unresolved template placeholder
Lines 14 and 214 contain {{TRIGGER_SDK_VERSION}} as a template placeholder. This is presumably resolved at build/publish time by the skills loader (which replaces it with the CLI's pkg.version). If the replacement mechanism doesn't process SKILL.md frontmatter and footer, users would see the raw placeholder. Worth confirming the BundledSkillsLoader handles this substitution in both the frontmatter library_version field and the body text.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
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.