/agentic-os-standalone

name: agentic-os-standalone
description: Set up an agentic OS as a standalone Next.js web dashboard — wired to the Claude Agent SDK plus up to 7 live MCP integrations (Circle community, Fireflies meetings, YouTube/VidIQ, Unipile LinkedIn DMs, Apify Twitter/X, Reddit), per-profile views, a button-bar of actions, snapshot-style data refreshes, and an optional Railway deploy with HTTP basic auth and a persistent volume. A real web app — runs locally or live. Use when the user says "set up a standalone agentic OS", "build an MCP-powered web dashboard", "spin up my AI ops dashboard", "deploy an AI dashboard to Railway", "give me a web version of the dashboard", or asks to personalize a web dashboard previously created with this skill.
disable-model-invocation: true
allowed-tools: Bash, Read, Write, Edit, AskUserQuestion

Agentic OS — Standalone web dashboard

Packages a Next.js 14 dashboard wired to the Claude Agent SDK + up to 7 platform integrations, plus an optional Railway deployment path. The template ships as `references/standalone/template.tar.gz` (packed because the Next.js dynamic-route folders use `[name]`/`[id]` paths that some plugin installers reject — extract it before use, see Step 3) and contains no secrets. Substitutions and live credential probes are the skill's job.

The dashboard's conceptual model: a per-profile dashboard, a button-bar of actions, and snapshot-style data refreshes — backed by JSON snapshots and deployable as a real web app.

> Want a markdown-native dashboard inside an existing Obsidian vault with no server instead? That's the Obsidian route — use the `agentic-os-obsidian` skill.

Audience

The user is a **founder, operator, or marketer** — NOT a developer. Keep language plain. Never say "MCP", "snapshot prompt", "stdio transport", "TypeScript type" out loud. Say "platform", "data refresh", "your YouTube channel", "the dashboard's settings file".

Internally you still operate on those technical concepts. The user just shouldn't have to read jargon.

What you produce

By the end the user has:

1. A new project folder at the path they chose, customized for their org and team. 2. Every integration they wanted connected AND probed (a real test call landed). 3. The dashboard running locally on http://localhost:3015, OR live on a Railway URL with HTTP basic auth. 4. A summary of what works, what they deferred, and how to add the deferred ones later. 5. **An iteration loop after first-run** — the skill keeps going to help them personalize tabs, rename things, change what each refresh pulls, swap colors, add new sections.

Pre-flight (collect credentials BEFORE asking discovery questions)

Two keys gate everything else. Get them upfront so the user isn't surprised mid-flow:

1. **Anthropic API key.** Required. Powers every refresh. "Head to console.anthropic.com → API Keys → create one and paste it here." Store as `ANTHROPIC_API_KEY`. 2. **Railway token (only if deploying today).** Ask: "Do you want to put this online today, or just try it on your laptop first?" If online: have them run `railway login` in their own terminal (browser flow), then `railway whoami` to confirm. Don't store the token — Railway's CLI keeps it locally.

If they don't have the Anthropic key yet, pause here and wait. Don't keep going.

Step 1 — Plain-language discovery

Ask these in plain English. Use AskUserQuestion when the options are clear.

1. **"What should we call this thing?"** → Display name (e.g. "Acme", "Sarah's Brain"). Show them what the kebab-case slug will be (e.g. `acme-os`) and let them override. 2. **"Where on your computer should I put it?"** → Default: `~/Projects/<slug>`. Confirm before writing. 3. **"Who's on your team?"** → Free text: comma-separated first names, 1-8 of them. Example: "Sarah, Marcus, Priya". The first name becomes the "main" view (gets a synthesis dashboard); everyone else gets a standard view. If they're solo, one name is fine. Tell them they can drop a profile picture for each person later. 4. **"Which platforms do you want me to pull from?"** → Multi-select. Use these plain labels (map to MCPs internally — never show MCP names):

| Label to show user | Maps to (internal) | What it does | |---|---|---| | "Your Circle community" | `circle-community` | Pulls posts, comments, DMs, member stats | | "Your meeting notes (Fireflies)" | `fireflies` | Pulls recent meeting transcripts + summaries | | "Your YouTube channel" | `vidiq` + `youtube` | Channel stats, recent videos, comments | | "Your LinkedIn DMs (Unipile)" | `unipile` | Unread DMs, draft replies, send button | | "Twitter/X trend scanning" | `apify` | Tracks accounts you care about | | "Reddit trend scanning" | `reddit` | Subreddit pulls |

Tell them they can skip any of these and add them later. Skipping a platform just leaves that tab empty in the dashboard.

Step 2 — Per-platform credentials + live probe

For EACH platform they selected, collect the credentials (using plain language) THEN immediately probe to confirm it works. Don't batch — do one at a time so the user can fix issues as they come up.

The probe pattern: write a temp `.mcp.json` with just that one server, then run `node scripts/probe-mcp.mjs <server-name>` (the template ships this script). It calls one cheap read-only tool on the MCP and exits 0/1. If it fails, surface the actual error from the JSON output and re-ask for the credential.

Per-platform credential questions (plain wording)

• **Circle community:**
• "What's the API key for your Circle MCP server?" → `MCP_CIRCLE_KEY`
• "What email do you use to log into Circle?" → `CIRCLE_OWNER_EMAIL`
• Probe: `probe-mcp.mjs circle-community`. If it fails on email, the dashboard still works for posts/comments; only DMs need the email.
• **Fireflies meeting notes:**
• "What's your Fireflies API key? (fireflies.ai → Settings → Integrations → API)" → `MCP_FIREFLIES_KEY`
• Probe: `probe-mcp.mjs fireflies`
• **