skills/new-app/SKILL.md
--- name: new-app description: Generic "start a new project" orchestrator. Walks the canonical [[stack-decision-map]] tree (audience → app shape → scale → reactivity → EU residency → owns-the-table → connectors → payments) using AskUserQuestion, lands on a leaf, dispatches to the framework-specific skill that builds it (`/ro:new-tanstack-app`, `/ro:new-astro-app`, `/ro:new-mcp-server`, ...). Use when the user wants to start, create, scaffold, bootstrap, or begin a new project but isn't sure whic
npx skillsauth add RonanCodes/ronan-skills skills/new-appInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A thin orchestrator that walks [[stack-decision-map]] and hands off to the framework-specific skill once the user lands on a leaf. Doesn't scaffold anything itself — every actual file write happens in the dispatched-to skill.
If you already know which framework you want, skip this and call the leaf skill directly:
/ro:new-tanstack-app — server-leaning SaaS / app/ro:new-astro-app — static-leaning marketing / portfolio / blog/ro:new-mcp-server — MCP server (McpAgent on Workers, optional --with-card)This skill is the "I'm not sure" entry point.
Every dispatch path scaffolds a /styleguide route by default (role-gated to superadmin + staff when auth is wired, dev-only otherwise). Downstream skills like /ro:new-tanstack-app and /ro:new-astro-app invoke /ro:design-system-create --showcase as part of their flow; this orchestrator doesn't need to ask about it.
/ro:new-app # walk every question
/ro:new-app my-site # pre-fill the app name
/ro:new-app --from-doc # re-read stack-decision-map.md before walking (don't trust cached snapshot)
/ro:new-app --explain # at each fork, print the rationale from the canon table
The decision tree this skill walks lives in [[stack-decision-map]] (LLM wiki research vault). Treat that doc as the source of truth — the prompts below reflect a 2026-05-05 snapshot. If the wiki tree changes (new framework leaf, removed alt, etc.), update the dispatch matrix at the bottom of this file rather than re-deriving the questions from scratch.
If --from-doc is passed and the wiki repo is checked out at ~/Dev/ai-projects/llm-wiki/vaults/llm-wiki-research, read the source mermaid block before asking anything — that's the authoritative version.
Use AskUserQuestion for each fork. Keep the wording faithful to the wiki tree:
Q1 — Audience (Q_AUDIENCE):
Q2 — App shape (Q_SHAPE):
If Marketing/static, ask Q3a — Existing site?
/ro:new-astro-app <app-name>/ro:migrate-to-astroIf Web SaaS, walk Q_SCALE → Q_REACTIVE → Q_EU → Q_OWNTABLE → Q_CONNECTORS → Q_PAYMENTS — but don't re-implement those questions here. Just dispatch /ro:new-tanstack-app <app-name> and let it walk its own --interactive flow with the same questions. (Different sub-skill, same questions, single source of truth.)
If MCP server: dispatch /ro:new-mcp-server <app-name>.
If 2D game | 3D experience: those leaves point to tbd:phaser-game / tbd:r3f etc. — print the leaf name and a short note that the dedicated skill is pending.
If Mobile-first PWA: dispatch /ro:new-tanstack-app <app-name> --pwa (which then composes /ro:pwa-install post-bootstrap).
Before invoking the chosen skill, summarise the decisions in one paragraph and print the exact downstream invocation. The user can interrupt if anything looks wrong.
Based on your answers:
- audience: power-user
- shape: marketing site
- migrate: no, fresh build
About to run: /ro:new-astro-app <app-name>
Continue? (yes/edit-decisions/no)
Invoke the dispatched skill. From here on, this skill is silent — the leaf skill drives.
| User picks | Then... | Dispatches to |
|---|---|---|
| Audience: vibe-coder | (no further questions) | (recommend Alex Finn stack, no skill dispatch) |
| Shape: Web SaaS | Walk SaaS-specific tree inside the skill | /ro:new-tanstack-app <app-name> --interactive |
| Shape: Marketing → fresh | (none) | /ro:new-astro-app <app-name> |
| Shape: Marketing → migrate | (none — migrate-app handles the source-side qs) | /ro:migrate-to-astro |
| Shape: MCP server | (sub-skill picks transport) | /ro:new-mcp-server <app-name> |
| Shape: Mobile PWA | (sub-skill composes PWA install) | /ro:new-tanstack-app <app-name> --pwa |
| Shape: 2D game | (no skill yet) | placeholder: tbd:phaser-game |
| Shape: 3D experience | (no skill yet) | placeholder: tbd:r3f / tbd:babylon |
When the wiki gains a new framework leaf, add a row above and a question/answer pair in step 1.
[[stack-decision-map]] — the canonical tree this skill walks/ro:migrate-app — the migration-side sibling (same dispatcher pattern, different leaf set)/ro:new-tanstack-app, /ro:new-astro-app, /ro:new-mcp-server — the leaf skills this dispatcher routes to/ro:setup-logging — every scaffolded app should run this for the diagnosable-by-default observability baseline (structured logging + trace_id + CF observability); pairs with /ro:diagnosecanon/auth-guards.md (MANDATORY with auth) — every login-gated page needs a server-side route guard; signed-out users must be redirected, never shown a gated page that then 401/500sdevelopment
--- name: worktree description: Coordinate multiple agents on one repo via a worktree-lock pool, so two agents never clobber each other's working tree. Acquire the first free slot (main, then beta/gamma… worktrees, created on demand), work there on your own branch, release when you've pushed. Use before modifying any repo that might be in use by another agent (factory, dataforce, etc.), or whenever you're told a repo is being worked on. Backed by `ro worktree`. category: development argument-hin
testing
--- name: ship description: Ship a feature branch the local-CI-first way — run the full local gate, push, open a PR, squash-merge, then deploy, without waiting on GitHub Actions. Use when a branch is ready for main and you want it merged and deployed now. Reads CI policy from `ro ci` (default skips remote CI because GitHub Actions billing keeps hitting limits). Sibling to /ro:gh-ship (waits on GitHub checks) and /ro:cf-ship (the deploy half). Triggers on "ship it", "ship this", "merge and deploy
testing
--- name: setup-logging description: Set up (or audit) the observability stack in a TanStack Start + Cloudflare Workers app so it is "diagnosable by default" — structured logging (logtape) with a request context carrying trace_id + userId + tenant/orgId, a trace_id propagated FE→BE→logs→Sentry→PostHog, Cloudflare Workers observability enabled, and Sentry + PostHog wired. Two modes: `setup` (wire it into an app) and `audit` (check an existing app + report gaps). Use when scaffolding a new app, wh
development
Manage credentials INSIDE the active ~/.claude/.env file — read which token/account to use for a given app (Simplicity vs Dataforce vs Ronan-personal), add or update a secret WITHOUT it passing through the chat (an interactive Terminal window prompts for it), and track secrets that were exposed in a transcript so they get rotated. Sibling to /ro:context (which switches WHICH env file is active). Use when the user wants to add an API key/token/secret, asks "which credential do I use for X", needs the env organized/labelled, or a secret was pasted into the chat and should be rotated.