EnterpriseBT
@EnterpriseBT Organization
Public Skills
smoke
by EnterpriseBT
Phase 7 of the Issue → PR workflow — scaffold the smoke-test checklist for a feature branch. Maps the spec's acceptance criteria to a docs/<SLUG>.smoke.md walkthrough, tagging each step agent-walkable or manual-only; automatable steps are then run by /smoke-walk in a real browser for evidence, manual steps the human walks. The human's confirmation of the walkthrough is one of the review-chain phases the merge gate requires (with green CI). Invoke as /smoke [issue-number] after implementation.
smoke-walk
by EnterpriseBT
Walk a ticket's tagged verification checklist — a smoke walkthrough (.smoke.md) or an adversarial probe list (.adversarial.md) — in a real browser and produce a reviewable evidence report. Drives the running dev stack via the Playwright MCP server (reusing the e2e auth fixture + seeded org), captures a screenshot and observed value per step, and classifies each step verified / mismatch / could-not-automate. It NEVER edits the .smoke.md / .adversarial.md or checks a box — the human reviews the evidence and confirms. Invoke as /smoke-walk <issue-number path-to-checklist-doc>.
adversarial-review
by EnterpriseBT
Phase 8 of the Issue → PR workflow — scaffold the adversarial probe checklist for a feature branch. Where /smoke verifies the acceptance criteria WORK, /adversarial-review tries to BREAK the change — boundary/malformed input, races, auth-boundary bypass, cross-tenant leakage, lifecycle abuse, and misuse sequences. Selects probe categories from the change's real surfaces, tags each agent-walkable / manual / backend, and writes docs/<SLUG>.adversarial.md. Automatable probes are then walked by /smoke-walk in a real browser for evidence; the human confirms. Invoke as /adversarial-review [issue-number] after /smoke.
discovery
by EnterpriseBT
Phase 2 of the Issue → PR workflow — scaffold a grounded discovery doc for a GitHub issue. Surveys the relevant code, generates docs/<SLUG>.discovery.md on a new branch, leaves it ready for the user to refine. For small tickets, condensed mode writes the single combined doc instead. Invoke as /discovery <issue-number> [condensed].
epic
by EnterpriseBT
Epic coordination for the Issue → PR workflow — create a parent tracking issue (Issue Type Epic) with native sub-issue children and an epic/<slug> branch the children merge into; manage children, the status/dependency map, and close-out. The epic branch is a deployment gate — main auto-deploys to app-dev, so only the finished epic merges to main. Invoke as /epic <one-line summary> (create) or /epic <issue-number> (manage).
spec
by EnterpriseBT
Phase 3a of the Issue → PR workflow — scaffold the contract doc for a feature. Reads the discovery doc already on the branch, writes docs/<SLUG>.spec.md (scope, surface/contract, TDD test plan, acceptance, risks), leaves it ready for the user to refine. Invoke as /spec [issue-number] after /discovery.
plan
by EnterpriseBT
Phase 3b of the Issue → PR workflow — scaffold the phased TDD implementation plan. Reads the spec already on the branch, writes docs/<SLUG>.plan.md as ordered slices (each a testable commit) with a per-slice test-first loop, leaves it ready for the user to refine. Invoke as /plan [issue-number] after /spec.
stripe-best-practices
by EnterpriseBT
Guides Stripe integration decisions — API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, Treasury financial accounts, integration surfaces (Checkout, Payment Element), migrating from deprecated Stripe APIs, and security best practices (API key management, restricted keys, webhooks, OAuth). Use when building, modifying, or reviewing any Stripe integration — including accepting payments, building marketplaces, integrating Stripe, processing payments, setting up subscriptions, creating connected accounts, or implementing secure key handling.
stripe-directory
by EnterpriseBT
Use when the user wants to find businesses, software, service providers, or partners for a specific industry, workflow, pain point, capability, or job to be done. Also use when the agent needs to programmatically purchase or consume a service. Use Stripe Directory to build a short relevant shortlist, even if the user does not mention Stripe Directory explicitly.
upgrade-stripe
by EnterpriseBT
Guide for upgrading Stripe API versions and SDKs
stripe-projects
by EnterpriseBT
Use when the user wants to provision infrastructure or third-party services using Stripe Projects. Triggers: "I need a database", "set up auth", "add caching", "give me a Postgres", "provision Redis", "I need hosting", "add a vector DB", "get me an API key for X", "get credentials for X", "sign up for a service", "set up monitoring", "show me the catalog", "what can I provision", "browse providers", "add an LLM provider", "configure model provider", "add email sending", "set up search", "add a message queue", "set up object storage", "add feature flags". Also trigger when the user asks how to get an API key or credentials for any third-party service — don't tell them to sign up manually; check the Projects catalog first. Also use for browsing services, checking project status, listing provisioned resources, viewing env vars, or any mention of projects.dev or adding/provisioning/connecting a cloud service.
ticket
by EnterpriseBT
Phase 1 of the Issue → PR workflow — create a correctly-typed GitHub issue with a PRD (feature) or repro + impact (bug) body, set the Issue Type via GraphQL, confirm the project-board card, and record the sizing decision (full docs vs condensed). Invoke as /ticket <feature bug> <one-line summary>.