sonzai-sdk

sonzai-claude-skill

A multi-plugin skill repo for AI coding agents (Claude Code, Codex, Gemini CLI, Copilot CLI) building on the Sonzai SDK. Two plugins ship from this repo:

Plugin	Skills	Audience
sonzai-sdk (public)	sonzai-sdk (wizard) + full-auto (autonomous) + cto-loop (semi-auto with 2 operator gates)	Any developer using the Sonzai SDK
sonzai-internal-staff (internal-only)	sonzai-internal-staff	Sonzai staff with read access to private monolith repos

The sonzai-internal-staff plugin is install-time gated — it lives in a separate plugin manifest, so it is never copied to a non-staff disk just because they installed sonzai-sdk.

Which skill should I use?

If you have...	And you want...	Use
A scoping conversation with stakeholders	Interactive wizard → spec + plan (no build)	sonzai-sdk
A meeting transcript + no human in the loop	Unattended build → running app, no prompts	full-auto
A meeting transcript + a tech lead available	Build + 2 operator gates (masterplan + live-app review)	cto-loop

full-auto and cto-loop share the same core machinery (tech-stack derivation/intake, brownfield audit, version-search hard rule, builder + fixer subagents, docker-compose deploy, functional QA loop). The only differences:

• full-auto runs end-to-end autonomously; auto-fixer loop on QA failure (bounded 5 cycles).
• cto-loop inserts two gates (masterplan approval + live-app review), swaps autonomous tech-stack derivation for an interactive 7-question intake on greenfield (or a detect-and-confirm audit on brownfield), and replaces the auto-fixer with an operator-feedback-driven fixer (bounded 5 cycles + 1 explicit "one more").

---

What the skills do

sonzai-sdk skill (the wizard)

When invoked:

1. Step 0 — drift check. Compares the installed SDK version's committed OpenAPI snapshot against the live spec at https://api.sonz.ai/docs/openapi.json. Catches stale code generation.
2. Step 1 — runs the wizard (intake.md). 8-question diagnostic interview (Q1–Q8: archetype, integration path, latency, capabilities, brand/persona, proactive, scope, runtime mode). Skips any answered by workspace inference. Forks on greenfield vs existing-codebase.
3. Loads the archetype playbook that matches the developer's intent — one of:
   • companion — 1:1 persistent companion (Replika-shaped)
   • guide-router — MBTI / personality-routed (intake guide + N specialists)
   • enterprise-assistant — team-shared, KB-heavy, audited
   • customer-support — KB + custom tools + webhooks
   • game-npc — inventory + custom states + dialogue + events
   • coach-therapist — long sessions, sync memory, diary, mood
   • hybrid-custom — combinations / multi-tenant
4. Drives spec → review → plan via the playbook's templates. Output is a fully-specified implementation plan ready to execute via superpowers:subagent-driven-development or superpowers:executing-plans.

For developers who just want a syntax lookup, a skip-wizard path falls through to the per-language references (python.md, typescript.md, go.md).

full-auto skill (autonomous, transcript → running app)

Take a transcript, ship a running local app. Zero operator prompts. Bounded fix loop.

• Build-complete notifications (v1.7.0+): sends a Slack DM + Gmail when the build finishes (healthy or with failing QA). Useful for long unattended runs.

1. Pre-flight — drift check (live OpenAPI), Docker check, SONZAI_API_KEY check
2. Phase 0a-d — transcript analysis → project-type detection → tech-stack derivation (greenfield) OR brownfield audit → derive 8 sonzai wizard answers
3. Phase 1 — assemble masterplan at docs/cto-review/<date>-masterplan.md
4. Phase 2 — builder subagent (always-search-current-state hard rule; never hallucinates package versions)
5. Phase 3 — generate Dockerfile + docker-compose.yml (postgres / postgres+redis / stateless variants); docker compose up -d --wait; functional QA against the running app
6. Phase 4 — auto-fixer loop on QA failure (bounded 5 cycles)
7. Phase 5 — final report at docs/cto-review/<date>-final-report.md; live app stays running

Operator owns the push decision — full-auto commits locally, never pushes.

cto-loop skill (semi-auto, transcript → running app + 2 gates)

Same pipeline as full-auto, with two operator gates inserted and an interactive tech-stack intake on greenfield (instead of autonomous defaults).

• Async replies via Slack/Gmail (v1.7.0+): when Gmail + Slack MCPs are enabled, operator can approve/feedback/abort gates from their inbox or Slack DM instead of returning to the terminal. 20min poll cadence, 24h timeout, paused-resumable.