SummonAI Kit 3.0, Your Team Workflow, Wired Into Claude Code in Ten Minutes

Setting up Claude Code, Cursor, or Codex in a real project is two problems pretending to be one.

The first is making the AI understand your code: which framework, which ORM, which conventions. SummonAI Kit has done that since 1.0, point the binary at your repo, get a CLAUDE.md, get per-stack skills, get specialized subagents.

The second is making the AI understand your team: which tracker you ticket in, what your branch convention looks like, what fires when a PR merges, which webhook events your code subscribes to, how you operate Stripe in production. None of that lives in package.json. The analyzer can't read it. The AI can't infer it.

3.0 is the release where the second problem gets a first-class answer.

//The Gap Between Knowing the Code and Knowing the Team

Take a simple ask: "Issue a refund for the order in PROJ-431."

A generic AI will:

1. Open the Stripe SDK docs.
2. Suggest you write a one-off script.
3. Maybe mention the dashboard.
4. Not know which of your test or live keys to use.
5. Not know that your team's policy is "refunds over $500 require manual review".
6. Not know to comment back on Linear ticket PROJ-431 when done.

A team-aware AI will:

1. Read its stripe-ops skill, sees the test-vs-live policy, sees the policy on amounts.
2. Run stripe refunds create --charge=… --amount=… against the right keys via the local CLI.
3. Read its linear-ops skill, pulls the ticket, posts a comment with the refund ID.
4. Transition the ticket per the team's lifecycle rule (e.g. "manual", leaves it open for review).
5. Optionally post a one-line note to #refunds per the dev-cycle skill's post-action conventions.

The difference is context: the policies, the conventions, the wiring. 3.0 ships a way to install all of that in ten minutes.

//What's in 3.0

The headline addition is /saikit-workflows, a slash command you run inside Claude Code, Cursor, or Codex that wires your operational stack into the AI's surface.

The numbers:

• 110 supported tools across 14 integration categories, ticketing, docs, comms, error tracking, analytics, payments, cloud, database, auth, email, design, marketing, product, SEO.
• 33 hand-written ops skills for the highest-leverage tools (Stripe, Sentry, Linear, GitHub Issues, Slack, Cloudflare, Vercel, Supabase, Neon, Postgres, Drizzle, Prisma, Better Auth, Clerk, Resend, PostHog, Datadog, Polar, Notion, Confluence, Figma, HubSpot, Customer.io, Meta Ads, Intercom, Cal.com, Statsig, GSC, Profound, structured data, in-repo ADRs, …).
• 47 official MCPs auto-detected and offered for wiring, 23 are zero-config paste-URL HTTP servers (Linear, Stripe, Sentry, Calendly, PlanetScale, Meta Ads, Cloudflare, Vercel, Notion, Slack, Intercom, Figma, HubSpot, …).
• A 7-question dev-cycle playbook synthesized into a project-level skill on every relevant turn.
• Three cross-tool slash commands, /start-task <TICKET>, /ship, /post-merge, generated to match your team's actual conventions.
• Three opt-in guardrail hooks for Claude Code, block force-push, block .env edits, block direct push to main.
• Idempotent flow. Re-run any time to add tools. Skips what's already installed; appends to (never overwrites) the existing playbook.

It runs on Claude Code, Cursor, and Codex. One run can fan out skills, MCPs, and commands into all three.

//How It Works

Two passes:

1. The codebase pass, summonaikit (binary). Same as before. Scans the repo, writes CLAUDE.md, generates per-stack skills, builds subagents.
2. The workflow pass, /saikit-workflows (slash command). Runs inside the AI CLI in chat. Detects which tools you actually use, asks short questions about how you operate them, installs ops skills + wires MCPs + synthesizes a dev-cycle playbook + writes cross-tool commands + offers guardrail hooks.

The two passes are intentional. Codebase context (which framework, which ORM, how the monorepo is laid out) is a different problem from workflow context (which tracker, which branch convention, what fires after a PR merges). Mixing them produces shallow output for both.

The workflow pass is opinionated about that separation. It runs in chat, not in the binary, because the AI should be the one asking you the questions. The questions feel natural in chat. They feel weird in a TUI.

//The Protocol, Why a Slash Command Drives the Binary

/saikit-workflows is sixty lines of Markdown. Look at it:

1. Run `summonaikit workflow run [--state=<BASE64>] --json` (omit `--state` on
   the very first call). Parse the JSON response.
2. The response is `{ ok: true, data: { instruction: { kind, ... }, nextStateBase64 } }`.
3. Execute the `instruction` per the table below.
4. Re-run step 1 with `--state=<nextStateBase64>` from the previous response.
5. Stop when `instruction.kind === "done"`.

The slash command is a thin protocol executor. The binary returns one instruction (ask, free-text, bash, write, message, done, error), the AI executes it (AskUserQuestion / Write / Bash), the AI calls back with the new state. State is opaque base64 JSON, the AI never inspects or edits its shape, only merges in user answers at the path the binary specifies.

Two reasons this matters:

Updates ship via summonaikit update. All the workflow IP, question text, playbook templates, cross-tool command bodies, hook configs, is compiled into the binary. There's no chance of the slash command and the binary going out of sync. Update one, and the protocol updates everywhere it's used.

The same flow runs on three AI CLIs. Claude Code, Cursor, and Codex all support AskUserQuestion + Bash + Write. That's all the protocol needs. The slash command renders the same way on each. The binary doesn't care which one called it.

//The Three Kinds of Skill

3.0 introduces a clean taxonomy:

The naming convention <tool> (codebase) vs. <tool>-ops (operational) lets both coexist. Each description tells Claude which to pick:

• stripe, "Wire up Stripe SDK calls in this repo. SDK patterns, idempotency keys, error handling, type-safe metadata. For operational tasks like refunds and webhook tailing, use stripe-ops."
• stripe-ops, "Operate against the Stripe API safely, refunds, disputes, subscription debugging, webhook scaffolding, MRR queries via the stripe CLI and Stripe MCP. For codebase-level Stripe SDK usage patterns in this repo, use the stripe skill instead."

When the model semantically matches a request against descriptions at session start, the high-keyword density on each picks the right one. "Issue a refund" routes to ops. "Wire a checkout session" routes to codebase.

The 33 ops skills are hand-written, not LLM-generated. Each has a hardcoded section on operating principles (test mode first, idempotency keys mandatory, webhooks are source of truth) and a templated section on the specifics (your test-vs-live policy, your webhook events, your refund-amount thresholds). The hand-writing is the point, these are the skills you don't trust an LLM to invent on the fly.

//The Dev-Cycle Playbook, Connective Tissue

Seven questions, two minutes, one project-level skill:

1. Branch naming convention. feat/PROJ-123-slug, <user>/<feature>, whatever you do.
2. Sub-task template under a Story or Task, names in order, or "none".
3. Commit footer for ticket references, Refs PROJ-123, Closes #456, or "none".
4. PR title pattern, feat(scope): subject (PROJ-123), conventional, or describe.
5. When the ticket transitions to In Progress, branch creation, first commit, PR open, manual.
6. Post-merge motion, close the ticket, post to comms, write a Notion row, tag a release, run deploy.
7. Autonomous-mode permissions, what the AI may do without confirmation.

The output lands at .claude/skills/dev-cycle/SKILL.md. It's the connective tissue, the skill that turns "I have Linear and Stripe and Cloudflare and Slack" into a single coherent workflow the AI follows.

It only runs when both ticketing and code-hosting tools are confirmed (the playbook is about the ticket-to-merge motion, and there's no point synthesizing one when half the inputs are missing).

It's append-only. Re-running /saikit-workflows after the playbook is written doesn't ask the seven questions again. To start over, delete the file and re-run.

//Cross-Tool Commands That Match Your Conventions

If the playbook ran, three slash commands are offered:

• /start-task <TICKET>, pulls ticket details via your ticketing-ops skill, creates a branch using your naming pattern, transitions the ticket per your lifecycle rule, posts a kickoff comment.
• /ship, runs your pre-ship gate, opens a PR with your title pattern and your commit footer, watches CI.
• /post-merge, runs your post-merge motion in order, close the ticket, post to comms, write the Notion row, tag the release, kick the deploy, but only the items you said you actually do.

The bodies are templated from your playbook answers and the commands reference the relevant <tool>-ops skills directly. Claude reads the dev-cycle skill, finds the pattern, applies it.

It is one keystroke from a ticket ID to "branch created, ticket in progress, kickoff comment posted". One keystroke from "code looks good" to "PR opened with the right title and the right footer, watching CI". One keystroke from a merged PR to "ticket closed, Slack posted, deploy kicked".

//Guardrails as Deterministic Hooks

Three Claude Code PreToolUse hooks, opt-in per project:

• Block git push --force. Force-pushing rewrites shared history. The hook fires regardless of branch.
• Block .env edits. Allows .env.example. Secrets stay out of files Claude has rewritten.
• Block direct push to main. Forces every change through a PR.

Why hooks and not prompts? Because the AI's promise to "never run git push --force" is fine until prompt injection from a tool output undoes it. A hook is deterministic, it intercepts the Bash call before it runs, exits 2, and Claude sees the rejection in the loop.

Hooks are a Claude Code feature today. Cursor and Codex have incompatible extensibility models, the kit skips this step on Cursor- or Codex-only setups rather than misconfigure.

//Idempotency by Design

/saikit-workflows is safe to re-run. The first thing it does on every invocation is scan your skills directories for existing <tool>-ops skills. Tools that already have one are filtered out of the per-category detection step.

That means you can run it now for ticketing + payments, then run it again next week to add error tracking, and the second run won't ask anything about Linear or Stripe.

The dev-cycle playbook is append-only. The hook merge in .claude/settings.json is additive. The MCP wiring in .mcp.json skips entries that already exist. The kit treats every artifact as user-owned content that it adds to but never overwrites, except its own bundled slash command bodies, which are canonical.

//What's Supported

110 tools across 14 categories. The full table is on the Categories & Tools page. Highlights, by category:

• Ticketing, Linear, Jira, GitHub Issues, Notion, Asana, Shortcut, Monday, ClickUp.
• Payments, Stripe, Polar, Paddle, Lemon Squeezy, PayPal, RevenueCat, Chargebee.
• Error Tracking, Sentry, Datadog, New Relic, Honeycomb, Grafana, OpenTelemetry.
• Cloud, Cloudflare, Vercel, Fly, Railway, Render, Netlify, AWS, GCP, Azure, K8s, Terraform, Docker.
• Database, Supabase, Neon, PlanetScale, Turso, Postgres, MongoDB, Firebase, Prisma, Drizzle.
• Marketing (Founder), HubSpot, Salesforce, Customer.io, Klaviyo, Meta Ads, Google Ads, LinkedIn Ads, TikTok Ads, Mailchimp, Beehiiv, Kit, Attio, Airtable.
• Product (Founder), Intercom, Zendesk, Plain, Crisp, Help Scout, Front, Cal.com, Calendly, Statsig, GrowthBook, LaunchDarkly, Typeform, Tally, Productboard.
• SEO (Founder), Google Search Console, structured data, Profound, Peec.ai, Ahrefs, SEMrush, Surfer, Frase, Clearscope, PageSpeed, Screaming Frog.

Detection runs locally, package.json deps (exact + prefix), env-var name prefixes, repo-root files, and a small set of content substrings. The kit never pings external services to decide whether you use Linear; it looks at LINEAR_* env names and .linear/ files.

For tools without a hand-written ops skill, the kit still wires the MCP if one exists. You get direct API access through the AI without the runbook layer.

//Plan Tiers

Tier filtering happens both client-side (UX) and server-side (the catalog endpoint refuses Founder skills for Solo users). If you ship code, Solo is enough. If you also do go-to-market, running ads, sending lifecycle email, tracking SEO citations, operating Intercom, you want Founder.

//A Real Run, End to End

$ claude
> /saikit-workflows

  Which integration categories matter for your workflow?
  [x] Ticketing & Project Management
  [x] Error Tracking & Observability
  [x] Payments & Billing
  [x] Cloud & Deployment
  [ ] Communication & Messaging
  [ ] …

  Detecting tools…
  → Ticketing: linear (env LINEAR_API_KEY), github-issues (.github/workflows/)
  → Errors: sentry (@sentry/nextjs, sentry.client.config.ts)
  → Payments: stripe (stripe + STRIPE_SECRET_KEY)
  → Cloud: cloudflare (wrangler.toml, alchemy)

  Which Ticketing tools do you actually use day-to-day?
  [x] Linear
  [ ] GitHub Issues

  Which Error Tracking tools do you actually use day-to-day?
  [x] Sentry

  …

  [Linear] Your team's ticket conventions
  > Title in imperative. Description has Why / What / Acceptance sections.
    Bugs use BUG- prefix; features use ENG-.

  [Linear] PR ↔ ticket linking rules
  > Branch name eng-123-short-slug auto-links via Linear GitHub integration.
    PR title prefixed with ticket ID. Merged PR moves ticket to Done.

  [Stripe] Describe your primary Stripe workflow
  > Subscription billing for SaaS, handle renewals, dunning for failed
    charges, prorated upgrades. Refunds processed manually after Linear
    ticket.

  [Stripe] Which Stripe webhook events does your code handle?
  > checkout.session.completed, customer.subscription.updated,
    customer.subscription.deleted, invoice.payment_failed

  …

  Installing skills…
  ✓ linear-ops  (.claude/skills/linear-ops/SKILL.md)
  ✓ sentry-ops  (.claude/skills/sentry-ops/SKILL.md)
  ✓ stripe-ops  (.claude/skills/stripe-ops/SKILL.md)
  ✓ cloudflare-ops (.claude/skills/cloudflare-ops/SKILL.md)

  Add 4 MCP server(s) to .mcp.json?
  [x] linear    , https://mcp.linear.app/sse
  [x] sentry    , https://mcp.sentry.dev/mcp
  [x] stripe    , https://mcp.stripe.com/
  [x] cloudflare, https://mcp.cloudflare.com/sse

  ✓ wrote .mcp.json

  What is your branch naming convention?
  > eng-{ticket-number}-{slug}

  What format is your commit footer?
  > Refs ENG-{number}

  What is your PR title pattern?
  > [{ticket}] {imperative subject}

  When does the ticket move to In Progress?
  ◉ When the branch is created

  After a PR merges, what fires automatically?
  [x] Close the ticket
  [x] Post to Slack
  [ ] Add a row to a Notion DB
  [ ] Tag a release
  [x] Run deploy

  In autonomous mode, what is the AI authorized to do without confirmation?
  [x] Commit on the feature branch
  [x] Transition tickets and sub-tasks
  [x] Post comments on tickets
  [ ] Create new tickets when discovering scope

  ✓ wrote .claude/skills/dev-cycle/SKILL.md

  Which cross-tool slash commands should I install?
  [x] /start-task <TICKET>
  [x] /ship
  [x] /post-merge

  ✓ wrote .claude/commands/start-task.md
  ✓ wrote .claude/commands/ship.md
  ✓ wrote .claude/commands/post-merge.md

  Install guardrail hooks in .claude/settings.json?
  [x] Block git push --force
  [x] Block .env edits
  [x] Block direct push to main

  ✓ updated .claude/settings.json

  Done, 11 minutes, 4 ops skills, 4 MCPs, 1 dev-cycle playbook,
  3 cross-tool commands, 3 hooks. Re-run /saikit-workflows any time.

After this, "issue a refund for the order in PROJ-431" works exactly the way the team expects.

//What's Next

A few things on the roadmap:

• More ops skills. 33 covers the highest-leverage tools, but the gaps are obvious, Auth0, LaunchDarkly, Mailchimp marketing-side, Klaviyo. Picking the next round based on what users actually wire.
• Workflow templates. The dev-cycle playbook is a starting point, not a ceiling. Letting users extend it with hotfix branches, RC release patterns, multi-repo flows.
• Better merge for existing configs. The TOML merge in .codex/config.toml is intentionally simple; richer comment preservation would be nice.
• Cursor and Codex-specific extensibility surfaces. Right now hooks are Claude-only. Cursor MDC rules and Codex prompt-as-skill could host equivalent guardrails, at the cost of accepting they're advisory rather than deterministic.

//Getting Started

If you're new:

# Install Claude Code (or Cursor or Codex)
curl -fsSL https://claude.ai/install.sh | bash
claude auth login

# Install SummonAI Kit
curl -fsSL https://cli.summonaikit.com/install.sh | bash

# Codebase pass, generates CLAUDE.md, skills, subagents
cd ~/code/your-app
summonaikit

# Workflow pass, wires your team workflow
claude
> /saikit-workflows

If you're on 2.x:

summonaikit update
# then in your AI CLI:
> /saikit-workflows

The slash command is installed by every fresh summonaikit run. Existing 2.x projects need one re-run of the binary (or summonaikit update) to pick it up.

Full docs: Workflows Overview. Full per-tool catalog: Categories & Tools. The thirty-three ops skills, what they look like, how the templating works: Ops Skills. The seven-question playbook: Dev-Cycle Playbook.

Ten minutes from summonaikit to an AI that ships the way your team ships. That's the bet 3.0 is making.