cassini-workshop

How to orchestrate Claude Code's experimental Agent Teams — spawning teammates as separate sessions, delegating work to them, and waiting for results instead of doing the work yourself in the main thread. Use whenever a task should run as parallel/independent workstreams: multi-file refactors, reviewing or auditing many modules at once, exploring competing approaches or hypotheses, research from several angles, or any "do A, B, and C in parallel" / "spin up a team" / "have agents work on this" request. Also use to recall the enable flag, teammate-mode config, coordination tools (SendMessage, task list), hooks, and the delegate-don't-implement orchestration pattern, and to avoid the anti-pattern of running everything sequentially in the lead session.

Behavior-driven design: write executable specifications BEFORE any implementation code. Reads /docs/PLAN.md for the build plan and /docs/STORIES.md for user stories, and stops to ask for either if it is missing. Generates TypeScript spec files in nested blocks — Feature > Scenario > Specification — where each Scenario arranges all of its data in a beforeAll/beforeEach, every Specification makes exactly one assertion, happy-path specs come first and exhaustively, and sad-path specs live in their own separate blocks. Auto-detects the runner: bun:test if the project uses Bun, otherwise Jest. Use when starting a new project or feature, when asked to "spec out", "write the tests first", do BDD/TDD, or turn a plan or user stories into a test suite. Ships PLAN.md and STORIES.md scaffolds plus ready-to-copy bun:test and Jest spec templates.

General object-oriented design principles for TypeScript projects that are NOT part of SOLID or the Gang of Four patterns — coupling and cohesion (incl. connascence), DRY, YAGNI, KISS, separation of concerns, encapsulation / information hiding, Tell Don't Ask, Law of Demeter, composition over inheritance, program-to-an-interface, Command–Query Separation, Principle of Least Astonishment, and fail-fast. Use when designing or refactoring modules, reviewing code for coupling/duplication/leaky-abstraction smells, deciding whether an abstraction earns its keep, or answering "is this good design / which principle applies" questions that SOLID and GoF do not cover.

GitHub workflow conventions: writing clear conventional commits, opening detailed issues and PRs via the `gh` CLI, and choosing trunk-based vs short-lived branch flow based on the size of the change. Use whenever the user wants to commit, branch, push, open an issue, open a PR, or asks how to structure any of those. Keep it light — direct, detailed messages, no ceremony.

Opinionated PostgreSQL schema and database design conventions: snake_case naming, `id serial primary key` surrogate keys, compound primary keys for many-to-many junctions, NOT NULL foreign keys by default (nullable only with an explicit override), enums instead of excessive lookup tables, STORED generated columns for derived/searchable data, business logic in plpgsql functions instead of application code, and JSONB used as a document store alongside a relational spine. Use when designing or reviewing a Postgres schema, writing DDL/migrations, naming tables/columns/constraints, deciding enum vs lookup table, modeling many-to-many, choosing JSONB vs columns, or answering "what is the right Postgres way to do this" questions. Ships copy-ready DDL, function, and JSONB-document templates.

Web application security review for TypeScript/JavaScript stacks, frontend and backend: XSS and output encoding, CSRF, clickjacking, secrets leaking into client bundles, authn/authz and IDOR, injection (SQL/command/NoSQL/ template), SSRF, mass assignment, insecure deserialization, file upload, path traversal, security headers and cookie flags, and dependency/supply- chain risk. Includes targeted rules for Next.js (Server Actions, route handlers, middleware, `NEXT_PUBLIC_`, RSC data exposure), Nuxt (Nitro server routes, `runtimeConfig` vs `public`, `v-html`), Bun (`Bun.serve`, `Bun.$` shell, file serving), and Hono (middleware order, JWT, CORS, context). Use when reviewing or writing web code for vulnerabilities, triaging a security finding, or answering "is this exploitable / how do I fix it" questions. Ships secure-default config templates and a finding report format.

SOLID object-oriented design principles for TypeScript projects. Use when designing or refactoring classes and modules, reviewing code for design smells (rigid, fragile, tightly coupled code), deciding how to split responsibilities or introduce abstractions, or answering "is this good OO design / which SOLID principle applies here" questions. Covers all five principles with idiomatic TypeScript before/after examples and guidance on when applying them helps and when it is over-engineering.

Opinionated SQLite conventions for local TypeScript + Bun web development with Drizzle ORM, where Postgres is the likely production target. Keeps the postgres-dba naming and modeling rules (snake_case, plural tables, `id` surrogate keys, NOT NULL FKs with explicit ON DELETE, compound junction keys, JSON document store) so the schema ports to Postgres with a dialect swap, not a rewrite. Covers the `bun:sqlite` + `drizzle-orm/bun-sqlite` driver, mandatory connection pragmas (WAL, foreign_keys, busy_timeout), STRICT tables, the SQLite analogues of enums / booleans / timestamps / JSONB / generated columns, drizzle-kit migrations, and a full section on running SQLite *in production* (single-writer discipline, Litestream/LiteFS durability, tuning) plus the Postgres cutover checklist. Use when starting or reviewing a Bun+Drizzle app on SQLite, writing the schema or migrations, choosing a column type, deciding whether SQLite can be the production database, or porting a SQLite schema to Postgres. Ships copy-ready `sch

Test-driven development with bun:test, written for clarity. Produces failing tests FIRST — before any implementation — that read as the executable spec a builder agent implements against. Each test names a single behavior in plain language, follows Arrange–Act–Assert, asserts one thing, and uses real types with no `any`. Use when asked to "write the tests first", do TDD, red-green- refactor, or hand a builder agent a test suite to build against. This is the lighter sibling of `bdd-specs`: no PLAN.md/STORIES.md ceremony, no Feature/Scenario nesting — just clear, behavior-named bun tests that guide the build. Ships a ready-to-copy bun:test template.

Idiomatic TypeScript conventions and best practices: strict compiler settings, type-level modeling (discriminated unions, branded/nominal types, `as const`/`satisfies`, exhaustiveness), `unknown` over `any`, immutability, error handling with a Result type, null/undefined hygiene, async/promise rules, module and naming conventions, and the project rule that every class exposes `toString()` and `toJSON()`. Use when writing new TypeScript, doing code review, setting up a tsconfig, modeling a domain type, or answering "what is the idiomatic TypeScript way to do this" questions. Ships ready-to- copy templates for value objects, entities, errors, Result, state machines, branded types, type guards, and a strict tsconfig.

Write, split, and refine agile/scrum user stories and acceptance criteria. Produces /docs/STORIES.md as the canonical backlog, formatted to feed directly into the bdd-specs skill (Story → Feature, Given/When/Then acceptance criteria → Scenario/Specification). Use this whenever the user wants to write a user story, capture requirements as stories, "groom" or "refine" a backlog, break an epic or feature into stories, split a story that is too big, write or tighten acceptance criteria, draft a Definition of Done, or turn a vague feature request or PRD into a structured backlog — even if they don't say the words "user story" or "scrum".