About stackbone-coder
stackbone-coder is a skill for shaping Stackbone agents and workflows through an interview. It gathers requirements one question at a time, scaffolds with the CLI, and coordinates implementation and verification with other skills.
Key features
- 01Interview to select a piece type
- 02Scaffold projects with the CLI
- 03Confirm capability needs step by step
- 04Coordinate SDK and CLI skills
- 05Run the emulator and verify
Use cases
- 01Create a Stackbone project from requirements
- 02Add an agent or workflow to a workspace
- 03Write and verify code after choosing capabilities
MCP support
It uses the stackbone-docs MCP server to find Stackbone documentation through search_docs, get_doc, and list_docs.
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ stackbone/ stackbone-skills --skill stackbone-coderAfter installing, type/stackbone-coderin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
references/agent.mdcapabilities.mdworkflow-agent.mdworkflow.mdDetails
From the project READMEStackbone coder — generate a piece by interview
This skill turns "I want to build X" into a scaffolded, wired-up Stackbone piece. It is an interview + scaffolding orchestrator: it picks the right shape, runs the stackbone CLI to lay down the files, then asks the user exactly what each surface needs and wires in only those. It does not replace the other skills — it calls them:
stackboneskill → the SDK code (the three shapes, the rules, the ambientstackboneclient).stackbone-cliskill → the commands (login,init,add,dev).stackbone-debugskill → triage when a run misbehaves.
The API itself (every defineDeepAgent option, every stackbone.* method) lives in the Stackbone docs, served over MCP as the stackbone-docs server (search_docs, get_doc, list_docs). A surface's page is titled like the surface under SDK (stackbone.rag, stackbone.database, …): list_docs for its path, then get_doc; a helper with no page of its own is found with search_docs on its name. Without those tools, fetch https://docs.stackbone.ai/llms.txt and follow the page's link to its raw markdown.
Golden rules
- One question at a time. Never dump the whole interview at once. Ask, get the answer, move on. Use a structured question tool (e.g.
AskUserQuestion) when you have one. - Default to the minimal piece. Only add a capability the user says yes to. A tool-only agent or a single-step workflow is a perfectly good answer.
- Never ask for injected env.
STACKBONE_POSTGRES_URL,MODEL_PROVIDER_API_KEY,MODEL_PROVIDER_BASE_URL,HMAC_SECRET, etc. are platform-managed — the runtime injects them. Don't ask for connection strings or keys. The model provider is configured once in Studio. - You orchestrate; the other skills implement. When it's time to write code, follow the
stackboneskill and read the surface's page. When it's time to run a command, follow thestackbone-cliskill.
The flow (5 steps)
1. Pick the piece type
Ask one question first — what are we building?
| Type | What it is | Pick it when |
|---|---|---|
| agent | A deepagents agent: model + system prompt + tools, holds a conversation. | A human (or another agent) talks to it and it reasons/acts with tools. |
| workflow | Durable, replayable code: input → steps → output, no conversation. | A background job, ETL, a scheduled task, multi-step orchestration with checkpoints. |
| workflow-agent | A durable workflow that calls a deep agent in one of its steps (callDeepAgent). | You need both: deterministic orchestration and a reasoning agent in the loop. |
Then detect the workspace: if the cwd already has package.json + deep-agents/ (or workflows/), you'll add to it; otherwise you'll init a new one.
2. Scaffold with the CLI
Drive stackbone (see the stackbone-cli skill for the full surface):
- New workspace:
stackbone init <name> --with <agent|workflow|workflow-agent> - Existing workspace:
stackbone add <deep-agent|workflow|workflow-agent> <name> workflow-agentandadd workflow --calls <agent>wire the workflow→agent step for you.
Network: every
addkind is fully offline (the pieces are members of the already-linked workspace). Onlyinitneeds a signed-in session (stackbone login) — it links the workspace to the org.
3. Type-specific interview
Open the matching reference and run its interview:
| Building… | Read & run |
|---|---|
| an agent | references/agent.md — its tools and its system prompt |
| a workflow | references/workflow.md — its input and output data → the schemas |
| a workflow-agent | references/workflow-agent.md — both, plus the workflow→agent wiring |
4. Capability checklist — one at a time
Open references/capabilities.md and walk every capability with the user, one question each: do we need a database? storage? an LLM call? RAG? human-in-the-loop? a connector? prompts? config? secrets? a schedule? to call another agent? a browser? For each yes, the reference tells you the surface, where it's reachable from (tool vs. workflow step), what to add (a src/schema.ts, a config.schema.ts…), and how to find the docs page for the code.
5. Wire & verify
Write the code with the stackbone skill, then boot the emulator with stackbone dev (see stackbone-cli) and exercise the piece — chat the agent, start the workflow, check a run — before you call it done.
Reference files
| File | What it holds |
|---|---|
| references/agent.md | The agent interview: role, system prompt, the tools (name / description / inputs / behaviour), model choice. |
| references/workflow.md | The workflow interview: trigger, input data, output data, the steps; how answers map to inputSchema / outputSchema and 'use step'. |
| references/workflow-agent.md | The combined interview + the workflow step that calls the agent via callDeepAgent. |
| references/capabilities.md | The full capability checklist — every surface, when it applies, what it adds, and how to find its docs page. |