# Sc All > Turn a plain-language web-app goal into a working live app. Designed for non-technical users: choose architecture and hosting automatically, connect accounts safely, create/publish code, data, domain and verification end-to-end, delegate user-facing frontend quality to sc-fe, and expose technical details only when needed or requested. - Skill: `rahmanef63/sc-all` (Agent Skill) - Install (CLI): `npx skillmds@latest add rahmanef63/sc-all` - Raw SKILL.md: https://api.skillmd.com/api/skills/rahmanef63/sc-all/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: rahmanef63 (https://skillmd.com/u/rahmanef63) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/rahmanef63/sc-all --- # /sc-all — runtime first, then deployment route ## Language Keep durable instructions in English. **Reply in the user's language** unless they request another language. Use this when the user says **build me a web app**, **create a website**, **put this app online**, **use my domain**, or describes a product they want built and published. The user should describe the goal, not the infrastructure. SI-Coder owns the routing. ## Non-technical default UX — mandatory SI-Coder is primarily for people who want a working web app, not an infrastructure lesson. **Lead with the outcome, hide the plumbing.** A valid user request can be as simple as: > "Create a salon booking app and put it on my domain." From that sentence, the agent should normally choose the stack, database/data service, hosting route, repository strategy, deployment method, domain records, and verification approach itself. Rules: 1. **Speak in goals:** "publish the app", "connect the account", "connect the domain", "store the app data". Do not lead with terms such as environment variable, DNS record, deploy key, compose, container, build pipeline, or provider routing. 2. **One user action at a time.** Never dump a setup checklist when only one permission/account connection blocks progress. 3. **Do not ask users to choose technology** unless they explicitly care. Choose sensible defaults and keep the technology name in optional technical details. 4. **Do not ask a question that tools/repo state can answer.** Inspect first, then ask only the unresolved product/domain/account decision. 5. **Credentials are framed as permissions, not secrets.** Say "I need permission to use the email service" first. Then show the official create/connect action, where access is stored, and what SI-Coder will do next. Put env-key names and terminal commands under optional technical details unless the user must run the command. 6. **Never ask the user to copy values between services** when a connector/server-side flow can do it safely. 7. **Progress is product-oriented:** `Build the app → Prepare data → Frontend quality → Publish → Connect domain → Verify`, not internal provider phases. 8. Every completion message must state what is now working and then offer exactly one `[rekomendasi]` next step. 9. Technical users can ask for "technical details", `--technical`, JSON, or provider-specific skills. Do not force those details on everyone else. 10. When a planner/tool returns `userPlan`, **that is the default user-facing response**. Fields such as route, providerRouting, executionEngine, credential key names, and raw flow ids are internal/advanced unless they are necessary to recover from an error. When a technical failure occurs, translate it first: - preferred: "The domain is not connected yet. I am fixing the connection between the domain and the website." - optional detail: "The CNAME does not match the hosting target yet." Never hide a failure, but explain its user impact before its implementation detail. ## Core promise One request drives the complete path. The following route vocabulary is **internal/advanced**; do not repeat it to a non-technical user unless needed: `detect runtime → choose/ask VPS branch → connect auth safely → GitHub → backend → frontend → sc-fe quality gate → domain/DNS → verify → recommend next action` Do not stop at repo creation, project creation, DNS write, build trigger, or a compiled frontend. Complete and verify the production path. ## Frontend quality delegation — mandatory when applicable `sc-all` owns end-to-end delivery; `sc-fe` owns frontend quality. For any user-facing frontend created or materially changed by this workflow, delegate to `sc-fe` before final production verification. Rules: 1. New frontend with no established design system → use `sc-fe` with product/platform defaults unless the user named a preset/profile. 2. Existing coherent product → use `sc-fe --existing` behavior by default; preserve design DNA instead of resetting it to generic SI-Coder taste. 3. Forward explicit frontend flags unchanged, including `--apple`, `--workbench`, `--profile `, `--save-profile `, `--density`, `--motion`, `--platform`, `--audit`, and `--strict`. 4. Do not route backend-only/infrastructure-only work through a cosmetic frontend pass. 5. User scope exclusions are hard locks. If the user excludes a surface (for example a mobile nav dock), `sc-all` and `sc-fe` must not modify it directly or indirectly. 6. Presets are principle references only; do not copy proprietary assets or pixel-clone another product. 7. Frontend completion requires rendered/interaction verification when the runtime provides browser/screenshot capability; compilation alone is not sufficient evidence. ## Delivery contract and existing-project precedence Read [the delivery workflow](../sc/references/delivery.md) before provisioning. In the standalone web package it is `references/delivery.md` under the main `sc` directory. Follow its applicable checkpoints from initiation through CI/CD. Existing project configuration and available authorized tools override the new-project routing defaults below: preserve managed Convex with a VPS frontend, the current auth provider, package manager and deployment source mode. A browser-hosted conversation with an authorized VPS runner can use that runner directly. Composio is one option, not a mandatory intermediary. Required login/recovery/email/legal/CI flows belong to the requested delivery, not an optional recommendation after declaring the app complete. # 0. FIRST BRANCH — where is the agent running? This decision happens **before credential routing**. ## A. Hosted agent — Claude Web, ChatGPT chat, other server-side chat hosts Treat the runtime as `hosted` when the agent has no normal local shell/filesystem/SC vault and is operating through hosted connectors/plugins. **Do not ask whether the user owns a VPS. Do not require a VPS. Do not ask for local `sc secret set`.** The default path is full Composio: ```text Composio connect → GitHub → Convex Cloud → Vercel → Hostinger DNS → verify ``` Every deployment provider, including GitHub, is a Composio connected account in this mode because there is no local SC/Git identity to preserve. Planning equivalent: ```bash sc deploy plan --runtime hosted --target auto --composio --json ``` The script is a portable policy reference; a hosted chat does **not** need the local `sc` executable to execute the flow. The host agent should run the equivalent connector calls directly. ### Hosted Composio execution contract 1. Discover the required toolkit/actions for **GitHub, Convex, Vercel, Hostinger**. 2. Check connection state for each toolkit. 3. For disconnected toolkits, create the secure Composio auth connection and show the auth link. 4. Continue only after the needed connection is active. 5. Run the provider operations through Composio; never retrieve/decrypt credentials just to pass them between providers. 6. Reuse identifiers returned by earlier steps (repo, project, deployment, domain) rather than searching ambiguously again. 7. Verify the public result. If Composio is unavailable, discover other authorized provider connectors or a connected VPS runner. Report a missing-access blocker only when no available route can perform the needed operation safely; never ask for provider API keys in chat. If a hosted user explicitly asks to deploy to their VPS/Dokploy, explain that this requires a connected VPS runner/MCP or a local SI-Coder runtime. Never silently replace an explicit VPS request with Vercel. ## B. Local agent — Claude Code, Codex CLI, Hermes/OpenClaw on a machine The first infrastructure branch is: > **Do you have a VPS you want SI-Coder to deploy to?** Do not ask this if existing configuration already answers it (for example valid Dokploy configuration), or if the user already said yes/no. Otherwise ask this **once, before provider credential setup**. Planner: ```bash sc deploy plan --runtime local --target auto --json ``` When ambiguous it returns `route: decision-required` + the VPS question instead of guessing. ### B1. Local + VPS ```text GitHub (SC) → Convex self-hosted → Dokploy → Hostinger DNS → verify ``` Default target: `dokploy`. Optional `hybrid` when the user wants VPS frontend + managed Convex: ```text GitHub (SC) → Convex Cloud → Dokploy → Hostinger DNS → verify ``` ### B2. Local + no VPS ```text GitHub (SC) → Convex Cloud → Vercel → Hostinger DNS → verify ``` On a local runtime, GitHub stays in SC by default so repository identity remains deterministic. Vercel/Convex/Hostinger prefer Composio when connected and fall back to SC credentials when necessary. # Provider routing matrix | Provider | Hosted web/chat | Local, no VPS | Local + VPS | |---|---|---|---| | GitHub | **Composio** | **SC** | **SC** | | Convex | **Composio / Cloud** | Composio preferred, SC fallback | **SC/self-hosted** (`hybrid`: managed) | | Vercel | **Composio** | Composio preferred, SC fallback | optional | | Hostinger | **Composio** | Composio preferred, SC fallback | Composio or SC | | Dokploy | n/a | n/a | **SC** | Read `../../references/provider-routing.md` before auth work. # One-prompt orchestration ## Phase 1 — inspect, do not interrogate Infer whenever possible: - project/app name, - GitHub repository/branch, - framework/build command, - whether `convex/` exists, - canonical domain, - existing Vercel/Dokploy/Convex state, - whether a user-facing frontend exists and which design/profile constraints already apply. Only ask for a fact that cannot be safely inferred. On local runtime, VPS ownership is the first such branch when unknown. ## Phase 2 — repository ### Hosted Use the connected Composio GitHub account. Confirm the selected account if multiple connections exist. Create/reuse the repository and publish the intended source through the available GitHub connector actions. ### Local Use SC/direct GitHub identity. Protect `.env*`, keys, certificates and other secret files before staging. Never embed a PAT in a Git URL. # Phase 3 — backend/frontend ## Hosted or local/no-VPS managed route 1. **Convex Cloud** — reuse/create production project/deployment through Composio when available. 2. **Vercel** — reuse/create project, bind repository, apply config safely, deploy production. 3. Keep credentials inside their connected-account/secret boundary; do not surface raw deploy keys to chat merely to copy them elsewhere. ## VPS route 1. Ensure/reuse Dokploy project. 2. Preserve the existing backend. For a new VPS project, use the selected self-hosted or managed route; never reprovision an existing managed backend merely because the frontend is on a VPS. 3. Ensure/reuse Dokploy application. 4. Inject only required public/build values. 5. Deploy and poll to success/failure. ## Frontend quality gate If a user-facing frontend exists or was changed, run the `sc-fe` workflow before final publication verification. `sc-fe` internally composes UI, UX, DX and AX checks, preserving existing design DNA by default and honoring any named preset/profile. Do not let a successful build override an unresolved strict frontend gate. # Phase 4 — domain is first-class For a Hostinger domain/subdomain: 1. use the user's intended canonical domain, 2. attach that exact domain to Vercel or Dokploy, 3. retrieve the destination's required DNS configuration, 4. validate/write Hostinger DNS, 5. re-check domain verification, DNS and HTTPS. Do not invent a replacement subdomain when a canonical domain already exists. # Completion gate A deployment is complete only when applicable checks pass: - source/repository and live revision match the verified release, - the applicable auth/legal/email and CI/CD checkpoints in the delivery workflow have evidence or an explicit unresolved status, - backend is reachable, - frontend deployment succeeded, - user-facing frontend passed the applicable `sc-fe` quality/interaction verification, - explicit excluded surfaces remained unchanged, - custom domain is attached, - DNS points to the intended destination, - HTTPS works, - public app responds, - no plaintext secret was emitted. Report both runtime and route, for example: - `hosted/composio/vercel` - `local/managed/vercel` - `local/vps/dokploy` - `local/vps/hybrid` # Proactive next-step behavior After a successful milestone, offer **exactly one** high-value next action. Pattern: > Deployment and all requested flows are verified. Offer only an optional improvement outside the completed scope; never defer requested password reset, invitations, or CI/CD as a recommendation. Rules: 1. Explain the benefit. 2. State prerequisites before asking. 3. Ask a simple opt-in question. 4. Hosted runtime: use a secure connector/auth link when available; never ask for a raw key in chat. 5. Local runtime: resolve/create a named provider connection and use the connection-scoped hidden-terminal handoff. Credential-dependent local scripts run through `sc run -- ...` so the selected connections are injected without exporting secrets globally. 6. After completion, suggest only the next most relevant action. 7. Never recommend something already healthy. Typical progression when relevant: `build → frontend quality → deploy → transactional email → auth/account flows → observability → backups/recovery → CI/release hardening` # Explicit routing ```bash # Hosted chat/web: full Composio, no VPS branch sc deploy plan --runtime hosted --composio # Local: ask/detect VPS first sc deploy plan --runtime local sc deploy plan --runtime local --vps sc deploy plan --runtime local --no-vps --composio # Advanced explicit targets sc deploy plan --runtime local --target dokploy sc deploy plan --runtime local --target hybrid sc deploy plan --runtime local --target vercel ``` Low-level skills remain available through `sc-dokploy`, `sc-convex`, `sc-convex-cloud`, and `sc-vercel`. `/sc-all` owns runtime/route orchestration; `sc-fe` owns frontend quality orchestration; provider sub-skills own provider mechanics. ## Related references - Provider routing: `../../references/provider-routing.md` - Portable hosted/local behavior: `../../references/portable-skills.md` - Frontend quality: `../sc-fe/SKILL.md` - Secret/MCP boundary: `../sc-provider/SKILL.md` ## Mandatory credential + next-step response contract Whenever a credential/API key is missing, **never output only the variable name**. Always make the handoff explicit: ```text Buat di : Petunjuk : Connection : Save with : Stored in : Lanjut : ``` Rules: - Local SC runtime: resolve/create a labeled connection first, then use the provider endpoint and `sc user credential-set --connection `. Direct values live only in that connection's `0600` file; legacy profile/shell storage is migration-only. - Hosted Claude Web/ChatGPT-style runtime: prefer the secure Composio connection URL returned by the connector; credentials stay in the connected account. Do not ask for the raw provider key unless the connector explicitly requires an API key bootstrap. - If a custom API-key provider has no creation URL, do not guess one. Require its provider metadata to be updated with `--url https://...` first. - Never put the credential value in chat, argv, logs, recommendations, or tool JSON. After every meaningful completed milestone, emit exactly one next-step block: ```text [rekomendasi] Next : Why : Needs : If you want : ``` Do not dump multiple recommendations. Do not recommend something already configured and healthy.