--- name: devintern-setup description: Install DevIntern Code, set up a worker, or connect source control and task tracker accounts. Use for first-time setup, credentials, GitHub App or relay authorization, browser-assisted integration setup, and verifying worker readiness. Ongoing workspace policies and recurring schedules belong to devintern-workspace; task dispatch and DevIntern PM setup are separate workflows. --- # Set up DevIntern Recommend workspace/worker mode as the standard DevIntern Code setup, including for a single repository. It provides ongoing task acquisition, PR follow-up, schedules, and centralized configuration. For a general request to set up DevIntern, guide the user toward a workspace worker with relay-backed integrations. Honor explicit requests for a one-off interactive CLI run; those do not require a resident service or worker entitlement. Do not treat a successful standalone task as completion of requested worker setup. Use the [quick start](https://devintern.com/docs/code/quick-start), [configuration guide](https://devintern.com/docs/code/configuration), and [worker guide](https://devintern.com/docs/code/worker). In a source checkout, read the corresponding `docs/code/*.md` files and implementation when needed. Installed skills must not assume a source checkout or other DevIntern skills are present. Check installed command help before using flags from newer documentation. ## Establish the destination and existing state Identify the execution host, repository remotes, chosen agent, task source, and desired PR/review behavior. Reuse working configuration and authentication. Inspect credential names and presence without printing values; do not dump `.env`, session, or relay files into tool output. Preserve existing settings, repository/team identifiers, and file permissions. The default worker config is `~/.devintern/workspace.toml`. Honor `DEVINTERN_WORKSPACE_DIR` and explicit `--workspace /path/to/workspace.toml` selections on commands that support them. Secrets, git credentials, and agent authentication must work on the worker host, even when authorization happens in a browser on another machine. Read [Integrations](references/integrations.md) when configuring source control, tracker credentials, provider authorization, or relay connections. Code-host access, task-tracker access, DevIntern sign-in, and agent authentication are separate checks. Actively help complete provider setup through available browser automation, such as browser-use, Chrome DevTools Protocol (CDP), or another browser tool. This can include GitHub App authorization, repository selection, and tracker webhook settings. Use an existing authorized browser connection when available; no particular browser tool is required. Let the user complete login, MFA, or admin approval when needed, then resume setup and verify the CLI result. For a new worker with supported code-host/tracker integrations, recommend the hosted relay as the standard setup. Provider webhooks reach DevIntern's relay and the worker connects outbound, so the worker needs no public webhook endpoint, inbound port, tunnel, or customer-owned GitHub App. Include relay pairing in the normal integration setup and retain polling as fallback. Honor an explicit polling-only, no-relay, or air-gapped choice and preserve existing delivery choices when making unrelated changes. Standalone CLI tasks and local-only automations do not need relay pairing. ## Prepare the runtime and configuration - Check Bun, Git, `devintern`, and the selected agent CLI on the execution host. If installation is requested and DevIntern is absent, use `bun install -g @getdevintern/code`. Follow the runtime or selected agent's official instructions when those prerequisites are absent; preserve the user's agent choice. Configure `AGENT_HARNESS` in the environment used by the worker. Finding the executable alone does not prove the agent is authenticated. - For the recommended guided terminal setup, start with `devintern worker init` inside the checkout. It reuses project credentials or offers tracker setup when missing, configures the workspace, validates the task query, offers relay pairing, and optionally installs/starts a user service. A separate `devintern init` run is not a prerequisite. These are interactive wizards: do not pipe guessed answers into them or rerun a wizard indiscriminately over an existing workspace. `worker init --no-service` skips the service offer. Use project `devintern init` for an explicitly requested standalone CLI setup. - For agent-driven worker setup without terminal prompts, `devintern worker scaffold` creates the workspace, and `devintern worker add-repo` registers the current checkout. Configure the workspace credentials and sources directly; `devintern init --yes` is an optional project-template helper, not a required first step and not credential validation. Registration imports existing project `.devintern-code/.env`: absent keys merge into workspace `.env`, conflicts become `[repos.env]` overrides. These commands alone do not connect accounts, select work, or start a service. Inspect help for custom workspace support; edit the selected config directly if a setup command cannot target it. - Store shared worker credentials in workspace `.env`, repo credentials in repo environment layers, and tracker credentials in the relevant team layers. Prefer owner-only secret files, preserve `0600`, and keep secrets out of version control and summaries. A checkout's project `.env` is not automatically loaded by workspace execution. See [workspace configuration](https://devintern.com/docs/code/workspaces) for exact precedence and routing. - For unattended work, check an active Worker Pilot or automation license. Use `devintern worker login [method] --workspace /path/to/workspace.toml` when worker sign-in is needed and supported; project `devintern login` alone is not proof that the selected worker is signed in. Paid license use does not by itself require sign-in; hosted relay pairing does. Never activate a paid subscription merely to complete setup. Configure only the requested sources and policies. A single repo needs no routing rules. Multiple tracker sources use `[[teams]]`; a team fixed to one codebase can set `repo`, otherwise use unambiguous routing rules. Select a narrow, user-intended ready-work query in the tracker's query language. Do not execute `devintern --query` as a read-only connection test: it can process matching tasks. Automations can run without tracker credentials or a polling query; the current schema still requires `[defaults].tracker`. For detailed workspace changes, use `devintern-workspace` when available, or consult the workspace guide directly. Recurring prompts, estimation sweeps, Sentry monitor policies, pipelines, quiet hours, and concurrency do not need to be enabled for basic setup. One-off dispatch uses `devintern-delegate` when available. ## Verify and activate Use read-only provider checks for the intended repository, tracker project, query, and configured workflow states. Validate the TOML and relevant schema; there is no assumed `worker validate` command. `devintern doctor` checks readiness in its loaded project/environment context, not every repo/team in a workspace; inspect its output before claiming it tested remote credentials or worker authentication. Use `devintern worker connect status --workspace /path/to/workspace.toml` for relay pairing status, not as a complete worker health check. Before starting a worker, inspect whether a service or daemon already owns the selected workspace. Startup begins acquiring eligible work. Start the worker or install/start its user service when the user's requested setup includes activation; do not launch a second daemon. Follow the installed wizard's generated service instructions or the [service guide](https://devintern.com/docs/code/worker#running-as-a-service), including Bun/agent PATH and unattended git authentication. Do not invent `worker service install`. Changes to shared tracker credentials, tracker/team identity, or dashboard/startup settings require a restart; ordinary repo/query/routing edits can reload. Verify logs show that the requested configuration was accepted. Only run a trial task when covered by the user's request: it can modify files, transition tracker tickets, post comments, and create PRs. Configuration validation and successful authorization are not proof that an implementation ran successfully. Report the selected host/config, repositories and task sources, and evidence separately for: **configured**, **credentials verified**, **relay connected or polling-only**, and **worker running or intentionally stopped**. Identify remaining browser/user actions and any checks that could not be performed. Never include tokens, session data, or private ingest URLs.