Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/vercel/workflow/internal-dev-workbenchnpx skills add vercel/workflow --skill internal-dev-workbenchgit clone --depth 1 https://github.com/vercel/workflowWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00122 | $0.02766 |
| Opus 5 | $0.00061 | $0.01383 |
| Sonnet 5 | $0.00024 | $0.00553 |
| Haiku 4.5 | $0.00012 | $0.00277 |
Grade B, and why
internal-dev-workbench scanned grade B with 2 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
Wire it into `~/.claude/settings.json` so it works across all sessions and worktrees. **Point the path at your primary checkout, not at a worktree**. Worktrees get deleted, so any path like `~/github/vercel/workflow--<br Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
/usr/bin/curl -s "$(portless get turbopack)/.well-known/workflow/v1/manifest.json" \ How it starts
The opening of the file, as written. The whole thing — 167 lines — stays where its author put it; the contents beside it link to each section on GitHub.
internal-dev-workbench
Bootstraps an opinionated 3-pane tmux session for end-to-end Workflow SDK development. Each pane is launched through portless so URLs are stable and worktree-scoped (e.g. https://<branch>.turbopack.localhost), letting multiple worktrees run concurrently without port conflicts. A companion statusline script surfaces the active URLs in Claude Code's prompt.
This is opt-in contributor tooling. The repo's standard dev path (pnpm dev from a workbench, no portless) is unaffected.
Prerequisites
tmuxinstalledportlessinstalled globally (npm i -g portlessor via Homebrew). Verify withportless --version.- Repo bootstrapped:
pnpm install && pnpm build. The first run on a fresh worktree must complete both before any dev server can start (the workbench apps depend on built workspace packages; withoutpnpm buildyou getMODULE_NOT_FOUNDforworkflow). WORKFLOW_PUBLIC_MANIFEST=1is required on the dev server when running e2e tests against it (otherwise/.well-known/workflow/v1/manifest.jsonis gated).
Layout
With main-vertical, the dev server takes the left column; the right column stacks the observability UI on top of a scratchpad shell:
+----------------------+--------------------------+
| | PANE_OBS: workflow web |
| | (observability UI |
| PANE_DEV: turbopack | scoped to the |
| (Next.js dev) | workbench app) |
| +--------------------------+
| | PANE_SH: zsh scratchpad |
| | (repo root, for build, |
| | tests, e2e, git, etc.) |
+----------------------+--------------------------+
Setup
The session name must match the worktree's portless prefix (the basename of the current branch) so the statusline and any other tooling that derives the prefix from the branch can locate it. Always run tmux ls first to confirm there's no pre-existing session with that name; never kill an existing one.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 167 lines · 122 tokens per session scan B 4135589af160
internal-dev-workbench is a skill published in the GitHub repository vercel/workflow (2,363 stars, last pushed 3d ago), licensed Apache-2.0. It adds 122 tokens to every session and 2,766 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it B with 2 findings (reads agent configuration directories, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
drizzle
Use this skill when writing or modifying Drizzle ORM schemas, queries, or migrations in this repo — specifically the @internal/dashboard-agent-db package (the dashboard agent's conversation datastore). Covers pg-core schema definition, the postgres-js driver, drizzle-kit migrations, and this repo's conventions: a…
trigger-getting-started
Bootstrap Trigger.dev into an existing project from scratch: authenticate the CLI, install @trigger.dev/sdk and @trigger.dev/build, write trigger.config.ts with the project ref and task dirs, scaffold a /trigger directory with a first task, wire tsconfig and .gitignore, set TRIGGERSECRETKEY, and run the dev server.…
trigger-dev-tasks
Use this skill when writing, designing, or optimizing Trigger.dev background tasks and workflows. This includes creating reliable async tasks, implementing AI workflows, setting up scheduled jobs, structuring complex task hierarchies with subtasks, configuring build extensions for tools like ffmpeg or…
span-timeline-events
Use when adding, modifying, or debugging OTel span timeline events in the trace view. Covers event structure, ClickHouse storage constraints, rendering in SpanTimeline component, admin visibility, and the step-by-step process for adding new events.
trigger-authoring-chat-agent
Author and run a durable AI chat agent with chat.agent from @trigger.dev/sdk/ai: the per-turn run loop, why you MUST spread ...chat.toStreamTextOptions() first, returning a StreamTextResult vs calling chat.pipe(), the two server actions (chat.createStartSessionAction + auth.createPublicToken), and wiring useChat to…
trigger-chat-agent-advanced
Advanced and operational chat.agent capabilities for Trigger.dev, loaded on demand. Load this when working on the raw Sessions primitive (sessions / SessionHandle), a custom chat transport or the realtime wire protocol, durable sub-agents (AgentChat, chat.stream.writer), human-in-the-loop, steering, actions…