/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 <name>, --save-profile <name>, --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 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:

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:

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:

sc deploy plan --runtime local --target auto --json

When ambiguous it returns route: decision-required + the VPS question instead of guessing.

B1. Local + VPS

GitHub (SC)
  → Convex self-hosted
  → Dokploy
  → Hostinger DNS
  → verify

Default target: dokploy.

Optional hybrid when the user wants VPS frontend + managed Convex:

GitHub (SC) → Convex Cloud → Dokploy → Hostinger DNS → verify

B2. Local + no VPS

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

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

# 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:

Buat di      : <authoritative provider URL / secure connector auth link>
Petunjuk     : <minimum scope / exact menu when useful>
Connection  : <user/provider/label + scope>
Save with   : <sc user credential-set user provider KEY --connection alias, or provider connector>
Stored in   : <named SC connection 0600, or external connected account>
Lanjut       : <verification/resume action>

Rules:

• Local SC runtime: resolve/create a labeled connection first, then use the provider endpoint and sc user credential-set <user> <provider> <KEY> --connection <alias>. 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:

[rekomendasi]
Next        : <one highest-value next step>
Why         : <one sentence>
Needs       : <prerequisites, or "nothing from you yet">
If you want : <what SI-Coder will do next / secure auth handoff>

Do not dump multiple recommendations. Do not recommend something already configured and healthy.