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

• stackbone skill → the SDK code (the three shapes, the rules, the ambient stackbone client).
• stackbone-cli skill → the commands (login, init, add, dev).
• stackbone-debug skill → 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 stackbone skill and read the surface's page. When it's time to run a command, follow the stackbone-cli skill.

The flow (5 steps)