SI-Coder (sc)

A simple tool for AI coding agents to build, connect, publish, and verify web apps from plain-language goals.

SC is a tool, not another platform you need to learn.

For normal use, you only need to know one thing:

Tell `sc` what you want to build or change.

Examples:

ChatGPT Skill (eligible workspace): @sc Create a booking app for my salon.
Claude Code : /sc Create a booking app for my salon.
Natural use : Fix the mobile checkout flow and publish it.

SC handles the technical work behind the request: choosing sensible defaults, editing the app, connecting supported services, publishing, and verifying the result.

You do not need to understand SC's internal skills, provider routing, MCP functions, memory system, recipes, evidence receipts, or release checks to use it.

What SC does

SC gives an AI coding agent a consistent way to:

• build a new web app from a plain-language idea,
• work on an existing app,
• connect the accounts/services the app actually needs,
• publish to an appropriate runtime,
• connect a domain when requested,
• verify the important user flow after a change,
• keep credentials out of chat and tool payloads,
• suggest one useful next step after a meaningful milestone.

The default experience is intentionally product-focused. SC should ask about what the app needs to do, not make a normal user choose frameworks, databases, DNS records, container strategies, or deployment pipelines.

The normal workflow

Your goal
   ↓
  sc
   ↓
understand the product
   ↓
build or change it
   ↓
connect only what is needed
   ↓
publish
   ↓
verify the real result

For a vague new idea, SC may ask a small number of product questions. If it can infer a reasonable default, it should continue instead of turning the request into a requirements workshop.

For an existing project, just describe the change you want:

/sc Make the dashboard responsive and fix the broken mobile navigation.

For deployment:

/sc Publish this app and verify the login flow.

For a provider integration:

/sc Connect transactional email for password reset.

The main sc skill routes internally to the appropriate workflow. Normal users should not need to choose a sub-skill themselves.

Move users and connections between projects

sc data export --out users.integration-bundle.json
sc data export --include-secrets --out users.integration-bundle.enc.json
sc data import --file users.integration-bundle.json

Plain JSON contains metadata only. Encrypted transfers prompt locally for a passphrase. Import previews conflicts before an explicitly confirmed create-only apply; no default, folder mapping or active OAuth session is copied. The browser manager also has Import / export JSON. Receiving projects use the documented versioned bundle and their own import adapter; no other application is required to run SI-Coder.

Data portability and schema.

Set credentials without pasting into chat

sc setup --web

The temporary browser hub includes every registered provider, user selection, named connections, source/auth methods, official links, expandable instructions, masked inputs, and verification before saving. Run it in an interactive terminal. For VPS access, use SSH port forwarding rather than exposing the local port. See Secure credential setup.

Installation

Already have SC installed in your agent? Skip this section and just use sc.

The canonical source is the skills/sc/ directory containing SKILL.md. Different AI clients use different installation transports, so the exact install step varies by surface.

Installation by client

Installation format matrix

Generated from docs/install/README.md. Do not edit this matrix here.

Surface	What it installs/reads	Recommended SI-Coder link	Invocation
Claude Code	Plugin marketplace, or a skill directory containing SKILL.md	GitHub repo / sc skill directory	/sc
Claude Web / claude.ai	ZIP containing the skill folder	Download sc.zip	Automatic when relevant
Codex CLI / app	GitHub skill directory containing SKILL.md	sc skill directory plus core sibling skills	Client-specific / automatic
ChatGPT uploaded Skills (eligible workspaces)	Uploaded skill package; canonical content is a folder with SKILL.md	Download sc.zip	Automatic or @sc
ChatGPT managed workspace	GitHub plugin marketplace	GitHub repo	@SI-Coder / plugin picker / automatic
Hermes / OpenClaw / generic Agent Skills	Skill directory containing SKILL.md	sc skill directory or install.sh	Runtime-specific
Client that explicitly supports .skill archives	.skill archive containing a normal skill directory	Download optional sc.skill	Client-specific

Detailed guides:

• Installation overview
• Claude Code
• Claude Web / claude.ai
• Codex
• ChatGPT uploaded Skills
• ChatGPT workspace marketplace
• Generic local Agent Skills

If an AI agent is given only this repository URL and asked to install SC, it should read AI_INSTALL.md and choose the appropriate path automatically.

Claude Code

/plugin marketplace add rahmanef63/si-coder-agent
/plugin install si-coder@si-coder-marketplace

Then:

/sc Create a booking app for my salon.

Local Agent Skills runtimes

Requires Node.js 22, 24, or 26. The installer reads skills/catalog.json and installs active/default skills only; unfinished/legacy skills are kept out of normal routing.

bash install.sh --agent claude
bash install.sh --agent codex
bash install.sh --agent hermes
bash install.sh --agent openclaw

Use --with-mcp only when the local runtime should also register SC's bundled MCP server.

Accounts and credentials

SC should never ask you to paste a password, API key, or access token into chat or machine-tool JSON.

When account access is required, SC should tell you:

1. which service/account is needed,
2. why it is needed,
3. the safest supported way to connect it,
4. how SC will verify the connection.

Hosted agents should prefer secure connected-account authorization. On a fresh local install, sc setup creates/selects a user and named provider connection first; direct credentials are stored only in that connection's 0600 file. Fresh setup does not write provider secrets to ~/.bashrc.

See first-run account onboarding for the detailed model.

One recommendation, not a backlog dump

After a meaningful milestone, SC may return one next step:

[rekomendasi]
Next : Add transactional email
Why  : Password reset needs reliable delivery.

The point is to keep the workflow moving without overwhelming the user with an internal engineering backlog.

Advanced usage

Everything below is optional for normal SC users.

Local CLI and provider connections

Running sc on a TTY opens the local interactive CLI. It is useful for operators who want to inspect users, provider connections, deployment plans, or diagnostics directly. Esc goes back one level; inside a credential/metadata input it cancels that input without saving or exiting SC. The lower INFO/PREVIEW/RESULT area expands on taller terminals so setup guidance is easier to read.

sc doctor
sc deploy plan
sc deploy plan --technical
sc user connections <user>

Direct local connections are user/account scoped. External OAuth or connected-account backends keep their provider tokens outside SC and store only safe routing metadata locally.

See CLI navigation and account ownership.

MCP and machine tools

SC exposes a machine-readable tool surface for compatible agents through the bundled MCP server.

• Machine-function SSOT: machine/functions.json
• MCP server: scripts/sc-mcp.js
• Tool documentation: docs/tool-calling.md

This is an integration surface for agents. A normal user does not need to call these functions manually.

Agent memory, evidence, recipes, and verification

SC also contains repo-local engineering safeguards used while maintaining SC itself:

sc task prepare "change provider auth routing" --json
sc memory query "provider auth" --json
sc skill verify --strict
sc verify
npm run verify:release

These features help an engineering agent reuse relevant past debugging/test knowledge, classify risky maintenance work, keep compact verification evidence, and promote repeated maintenance work into verified recipes/scripts.

They are maintenance infrastructure, not concepts a normal SC user needs to learn before using the tool.

See agent workflow and repo-local memory.

Design principles

SC should remain:

• Simple at the surface — one main tool/skill for normal use.
• Product-first — ask about desired behavior before infrastructure choices.
• Agent-friendly — technical capabilities are machine-readable when an agent needs them.
• Safe with credentials — secrets do not travel through chat/tool payloads; fresh local setup is named-connection-scoped rather than shell-global.
• Verifiable — completion means the important result was actually checked.
• Standalone — this repository owns its runtime contracts and does not require another local project or orchestrator to function.
• Progressively disclosed — advanced internals stay available without dominating the main user experience.

Repository map

Only the major surfaces are shown here:

skills/sc/               main user-facing skill
skills/sc-*/             internal/specialized workflows
bin/sc.js                local CLI
machine/functions.json   machine-tool contract
scripts/sc-mcp.js        MCP server
docs/                    detailed documentation
.agent/                  repo-maintenance memory/evidence/recipes

Development

For contributors and maintainers:

npm test
npm run docs:check
node bin/sc.js skill verify --strict
npm run verify:release
npm pack --dry-run

Release checks cover regression tests, lifecycle catalog validation, repository-wide secret scanning, skill validation, portable package contents, documentation consistency, and deterministic generated artifacts. Tagged releases rerun the full gate and verify public reachability before GitHub Release publication.

Documentation

• Installation
• CLI
• Tool calling / MCP
• Agent workflow and memory

If you only want to use SC, you can ignore those internals and start with:

@sc Build or change the app I describe, publish it when needed, and verify the result.