/daily-dev-onboarding

name: daily-dev-onboarding
description: Set up a daily.dev account from the agent. Connects the agent to a new or existing account with one link the user opens, learns what the user works on, then follows the right tags, sources and squads, sets their preferences and marks onboarding complete. Use when the user asks to set up, join, connect or personalize daily.dev, or pastes a prompt that points to this skill.
allowed-tools: Bash

daily.dev onboarding

Set up the user's daily.dev account for them. They do one thing in a browser: open a link and create the account. You do the rest: work out what they care about, follow the right tags, sources and squads, apply their preferences and mark onboarding complete. Change nothing on the account before they approve the plan.

All calls go to `https://api.daily.dev`. Never send a token to any other domain, and never print one.

The commands below are written for a POSIX shell. On Windows outside Git Bash or WSL, call `curl.exe` (in Windows PowerShell plain `curl` is a different command), put JSON bodies in double quotes with the inner quotes escaped, and read the token from `$env:DAILY_DEV_TOKEN`.

If a command is refused, by the user or by your client's permission checks, don't work around it and don't switch to another way of connecting. Show the user the exact command, say in one line what it is for, and ask them to allow it or run it themselves. Nothing here runs without their say.

Step 1: Check for access you already have

If the daily.dev MCP tools are available or `DAILY_DEV_TOKEN` is set, the user already has an account connected. Skip to step 3 and treat it as an existing account.

Don't search the OS secure storage for a token. If the user says they connected daily.dev on this machine before, resolve the token as the daily.dev skill describes ("Resolving the API token"). Otherwise go to step 2: the link connects an existing account as well as a new one.

Step 2: Connect

1. Ask for a link:

   curl -s -X POST https://api.daily.dev/agents/v1/signup \
     -H 'Content-Type: application/json' \
     -d '{"client":"<your client, such as claude-code, codex or cursor>"}'

Keep `token` to yourself. Use `claimUrl`, `userCode` and `expiresAt` from the response. `client` may contain only letters, digits, spaces, `_`, `.` and `-`.

2. Open the link in the user's default browser yourself. Don't wait for them to click it:

   open "<claimUrl>"                      # macOS
   xdg-open "<claimUrl>"                  # Linux
   powershell -Command "Start-Process '<claimUrl>'"   # Windows
   powershell.exe -Command "Start-Process '<claimUrl>'"   # WSL

Then tell them what you did and give them the code, in these words or close to them:

> I opened daily.dev in your browser so you can create your account, or connect the one you have. > Check that the page shows this code: `<userCode>` > Come back here when it says you're all set. > If the page didn't open, use this link: `<claimUrl>`

Always print the link as well: the command can fail silently, and you may be running on a remote machine or in a sandbox with no browser. If you can't run commands at all, give them the link and ask them to open it.

The code is how they know the page came from you. If the page shows a different code, they should close it.

3. Wait for them. Every 5 seconds, until `expiresAt`:

   curl -s https://api.daily.dev/agents/v1/signup/status \
     -H "Authorization: Bearer <token>"

• `pending`: keep waiting.
• `claimed`: the response carries `apiToken` and `isNewUser`. The token is returned once, on the first poll that sees the claim. Set `DAILY_DEV_TOKEN` for this session first, then store the token in the OS secure storage exactly as the daily.dev skill describes (service `daily-dev-api`). Tell the user it is stored, that it lasts 90 days and that they can revoke it at https://daily.dev/settings/api. If storing it fails or is refused, carry on with the session token and tell them it was not saved, so the other daily.dev skills will ask them to connect again.
• `claimed` without `apiToken`: the token was already handed out and is gone. Start again from 1.
• `expired`: the link ran out after an hour. Start again from 1.

From here on, call `https://api.daily.dev/public/v1` with `Authorization: Bearer $DAILY_DEV_TOKEN`.

Step 3: Read the account

curl -s https://api.daily.dev/public/v1/onboarding/setup \
  -H "Authorization: Bearer $DAILY_DEV_TOKEN"

It returns what the account follows and how it is set, plus `completed`.

• **New account** (`isNewUser` true, or `completed` false with nothing followed): do the full setup below.
• **Existing account**: tune it up. Suggest additions only. Don't touch the username, settings or digest unless the user asks, and never unfollow or block anything they chose.

Step 4: Learn what the user works on

Ask once before you look, in one question: may you look at their projects and GitHub to work out what to follow? If they say no, ask them for their main languages, frameworks and interests instead.

With their OK, use what you can reach:

• the project you are in: manifests (`package.json`, `go.mod`, `Cargo.toml`, `pyproject.toml`, `Gemfile`), frameworks, infrastructure files;
• their GitHub, if you have access: main languages, starred repositories, topics;
• anything they already told you in this conversation.

Only the names of technologies and topics leave their machine. Never send code, file contents, private repository names or company details to daily.dev.

Step 5: Draft the setup

Most important first. Followed tags decide almost everything a new account sees, so spend your effort there.

1. **Tags.** Fetch the real tag list once (`GET /tags/`) and pick from it; a tag that does not exist is skipped. Aim for 10 to 20 that match what they actually use, plus a few adjacent interests they named. Don't pad the list with