robconery

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

Designs the sprint's technical approach, authors the sprint-specific Reviewer checklist, and runs the final architectural review at sprint close. Also pulls in at strike 3 as an escalation partner. Does not write production code.

Writes production code to make failing tests pass for the current task. Bound by declared file ownership and the full styleguide. Use during each development task after the Orchestrator has assigned it.

Drives the sprint lifecycle end-to-end — planning interview, routing between agents (PO, Architect, Tester, PM, Builder, Reviewer, Security), per-task gate sequence, strike counter, final review. Use when the user wants to start, resume, or drive a sprint. Never writes production code or tests.

Q&A script the Orchestrator runs with the human at sprint start to establish sprint goal, sprint name (kebab-case), and verification steps. Use only when kicking off a new sprint.

Breaks Architect's design into tasks, groups into waves (parallel tasks in the same wave NEVER touch the same files), writes spec.md and plan.md during planning, and updates living docs at sprint close. Use after Architect during planning, and at sprint close for doc updates.

Translates the sprint goal into user stories with behaviorally testable acceptance criteria and explicit out-of-scope lists. Use during sprint planning after the interview, before the Architect. No hand-waving allowed.

Per-task code review against the Architect's sprint checklist plus the standing styleguide. Flags crap code — does NOT rewrite it. Owns Gate 2 (pass/fail).

Per-task security review — webhook signature verification, secrets hygiene, input validation, error hygiene, logging/PII, SQL safety, signed URL TTL, authz, deserialization. Owns Gate 3 (pass/fail).

Apply when writing, structuring, or reviewing application code — covers SOLID, YAGNI, DRY, composition over inheritance, Gang of Four patterns (used sparingly), Command/Query Separation, the banned Repository pattern, /lib application logic, and /tests BDD coverage. Load whenever designing classes, services, modules, or deciding where code lives.

Apply whenever you write or modify ANY class, method, or .ts file — not only when editing comments. Every class and method you author must be commented per this skill, so load it alongside code-architecture during all code-writing. Covers commenting classes and methods (not internals), writing for a future LLM reader, and avoiding noise comments on properties or obvious code.

Apply when reading or writing data, designing schema, choosing a datastore, or wiring persistence — covers Drizzle ORM usage, SQLite for dev/test, Cloudflare D1 for prod, Firebase Storage links, and the absolute ban on the Repository pattern. Load whenever touching the database, migrations, queries, or storage.

Apply when choosing runtime/framework/deploy targets or scaffolding an app, API, route, webhook, or deployment — covers Bun with TypeScript, Cloudflare Workers, D1, Firebase Storage, Resend, and Stripe webhooks. Load whenever setting up endpoints, configuring runtime, or planning deployment.

Apply when writing, reviewing, or planning tests — covers BDD style, happy-path AND sad-path coverage, deriving tests from user stories, and using bun:test. Load whenever creating *.test.ts files, adding coverage, or turning a requirement into a spec.

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.

Gang of Four design patterns reference for TypeScript projects. Use when choosing or implementing a design pattern, refactoring toward a known pattern, reviewing code for pattern misuse, or answering "which pattern fits here" questions. Covers all 23 creational, structural, and behavioral patterns with idiomatic TypeScript examples and guidance on when (and when not) to use each.

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.

Apply when writing, structuring, or reviewing application code — covers SOLID, YAGNI, DRY, composition over inheritance, Gang of Four patterns (used sparingly), Command/Query Separation, the banned Repository pattern, /lib application logic, and /tests BDD coverage. Load whenever designing classes, services, modules, or deciding where code lives.

Apply when adding, reviewing, or cleaning up code comments — covers commenting classes and methods (not internals), writing for a future LLM reader, and avoiding noise comments on properties or obvious code. Load whenever writing comments or judging whether a comment should exist.

Run an interactive brainstorming and planning session for a new feature. Guides the user through clarifying questions, solution proposals, and verification design. On approval, creates all project artifacts (feature branch, plan doc, prd.json, verification scripts) and commits everything. GitHub issues are created by chappie execute.