claude-template

Use when the user wants the Claude `/deploy` command workflow in Codex, or asks to run `deploy` using the claudet command template.

Use when the user wants the Claude `/fix-issue` command workflow in Codex, or asks to run `fix-issue` using the claudet command template.

Use when the user wants the Claude `/review` command workflow in Codex, or asks to run `review` using the claudet command template.

Use when syncing, auditing, or converting Claude Code and Codex project configuration; when the user says "sync agent configs", "convert Claude project to Codex", "convert Codex project to Claude", "make this project work with both Claude and Codex", or asks to keep AGENTS.md, CLAUDE.md, .claude, .codex, .mcp.json, agents, commands, and skills aligned.

Use when starting a new project from scratch and wanting Claude Code or Codex conventions; when the user says "scaffold from the template", "use claudet", "set up a new project", "init claude config in this repo", "init codex config in this repo", or asks to copy rules/agents/commands/claudedocs structure from the claudet template repo.

Use when the user wants to install or update the claudet rule library (`code-style`, `naming-and-comments`, `file-and-module-structure`, `dependency-management`, `testing`, `api-conventions`, `documentation`) into the current project's `.claude/rules/`; when the user says "sync rules from claudet", "install standard rules here", "update rules in this project", or asks why their rules look outdated compared to claudet's.

Use when designing or reviewing CI/CD pipelines or GitHub Actions workflows; when auditing CI for security or quality gaps; when picking tools (gitleaks, semgrep, trivy, osv-scanner, etc.); when deciding what should fail-the-build vs warn; when shipping AI-generated code that needs harder gates than human code; when a PR slipped through with secrets, hallucinated APIs, broken migrations, or uncovered branches.

Use when about to dispatch a long-running agent task that will modify files and the user wants to keep editing the main checkout; when planning to run two or more agents in parallel on the same repo and worried about file-edit collisions; when reviewing a PR or running a risky/experimental edit without losing current uncommitted state; when bisecting a bug across branches; when comparing two implementations side-by-side; when a destructive operation (large refactor, dependency upgrade, codemod) needs an escape hatch.

Use when adding a cache layer (Redis, Memcached, in-memory, CDN, HTTP); when a slow query is being "fixed" by caching instead of being fixed; when designing TTLs and invalidation; when there is cache stampede / thundering herd risk on a hot key; when stale data shows up after a write; when designing cache keys with versioning; when deciding between cache-aside / read-through / write-through / write-back / refresh-ahead; when a request coalescing or stale-while-revalidate pattern is needed; when adding negative caching for misses; when considering caching per-user or PII data; when picking eviction (LRU/LFU/TTL); when an in-memory cache is unbounded; when reasoning about multi-tier caches (browser → CDN → app → Redis → DB).

Use when considering whether to extract a helper, create an abstraction, add a configuration option, or build for a future requirement; when copy-pasting code; when adding indirection; or when a piece of code feels too clever or too speculative.

Use when a webhook handler can be retried by the upstream; when a queue or message-bus consumer might receive the same message twice; when two concurrent requests can both pass a uniqueness check before either inserts; when a cron job runs on multiple instances; when Stripe-style idempotency keys are being designed; when code does check-then-act on shared state; when an ORM update lacks an optimistic version column and is racing; when retry/backoff is being added to a non-idempotent operation; when a counter is being updated as `count = appComputedValue` instead of `count = count + 1`; when distributed locks (Redis SETNX, Zookeeper, etcd) are being used for correctness; when "exactly-once" delivery is being assumed from a broker; when an outbox or saga is being designed.

Use when writing, reviewing, or running database schema migrations against a non-empty database; when adding NOT NULL without a default, renaming/dropping columns or tables, adding foreign keys, creating indexes on large tables, or backfilling data; when an ORM (Prisma, Doctrine, Rails ActiveRecord, Django, Alembic/SQLAlchemy, TypeORM, Sequelize, Knex, GORM, Liquibase, Flyway) auto-generates a migration that's about to ship; when deploys fail with locks, timeouts, or "column does not exist" errors; when planning the order between code release and schema change.

Use when writing try/catch blocks; when adding async functions that can fail; when designing how a function reports failure to its caller; when retrying transient operations; when an error message would surface to a user; or when Claude is tempted to write `catch (e) {}` or wrap everything in a generic try/catch.

Use when adding `console.log` or any logging; when debugging an issue that only happens in production; when designing how a system reports its health; when adding metrics, dashboards, or alerts; when a bug requires correlating events across services; or when sensitive data might end up in logs.

Use when a task says "make it faster", "optimize", "speed up", or "improve performance"; when adding caching, parallelism, async, batching, or a worker pool to "make it faster"; when an N+1 query, missing index, or chatty API is suspected; when memory growth or a leak is being investigated; when picking between O(n²) and O(n log n) algorithms; when micro-optimizing CPU code while a DB or network call dominates the hot path; when no profile or flamegraph has been run yet; when allocating a p99 latency budget across services; when an SLO is at risk; when a benchmark on a laptop is being used to predict prod; when "premature optimization" is being introduced; when a regression test for a hot path is missing.

Use when deciding what kind of test to write (unit/integration/E2E); when test suites are slow or flaky; when deciding what to mock vs hit for real; when adding tests for a new service; when refactoring code that's hard to test; or when a test exists but doesn't catch the bug it should have.

Use when configuring a service for production; when adding env vars or secrets; when a service is hard to deploy, scale, or run on a new environment; when a deployment behaves differently in dev vs prod; when adding background jobs; or when designing how a process should start, stop, and recover.

Use when designing or reviewing HTTP/REST endpoints; when picking method/status/URL shapes; when adding pagination, filtering, or sorting; when versioning an API; when an operation might be retried (idempotency); when an existing API is inconsistent or hard to use.

Use when opening or reviewing a pull request; when a PR exceeds ~400 lines or 20 files; when a single PR mixes refactor and feature changes; when a PR is stuck in review for days; when review comments are dominated by drive-by nits; when an AI-generated PR is being reviewed; when a self-merged PR after pushing changes is being considered; when a "fix bug" PR description has no testing notes or rollback plan; when a code-owner approval workflow is being designed; when deciding which checks must be green before requesting review.

Use when reviewing or refactoring existing code; when a function or class feels "too big"; when adding a feature requires touching many unrelated files; when conditionals keep growing; when bare strings/numbers spread through the codebase; or when a class spends more time using another class's data than its own.

Use when asked to deploy, prepare a release, run pre-deploy checks, or before shipping code to production; ensures typecheck, lint, tests, build, migrations, env vars, and breaking changes are reviewed before release.

Use when designing data structures or entities for a business domain; when fields drift between layers (different shapes of "user" everywhere); when validation logic is scattered; when IDs are bare strings and get mixed up; when a class is "anemic" (just getters/setters with logic in services); when modeling money, dates, or other domain primitives.

Use when a feature is being put behind a flag/gate/toggle/experiment; when rolling a feature out incrementally (canary, blue/green, dark launch, percentage rollout); when a kill switch is being added; when a flag has been live past its planned launch date and "we should clean it up someday"; when evaluating a flag inconsistently per request causes UX flicker; when considering gating a database schema change behind a flag; when feature-flag debt is piling up and both branches of an old flag are getting partial maintenance; when designing rollout percentages and targeting rules; when a "release" and a "deploy" are being conflated; when permissions/entitlements are being implemented as runtime flags; when picking the safe default for when the flag service is unreachable.

Use when a controller, route handler, command, or HTTP/RPC entry point imports a repository, ORM client (Prisma, Sequelize, Mongoose, Knex), or DB driver directly; when `prisma.x.findMany`/`db.query` calls appear inside a Next.js route, Express controller, or NestJS controller; when deciding where business logic should live across controller, service, and repository; when a "service" is a one-line passthrough or a controller exceeds ~200 lines doing data access; when designing CQRS command/query handlers; when transaction boundaries are unclear or scattered across layers.

Use when naming a new variable, function, class, type, or file; when deciding whether a comment is needed; when reviewing a PR where names obscure intent or comments paraphrase the code; when a TODO/FIXME has no owner or date; when a boolean is named without `is`/`has`/`can`/`should`/`did`; when abbreviations like `usr`, `cfg`, `req`, `tmp`, `mgr` appear in identifiers that outlive a function body; when files are named `utils.ts`, `helpers.py`, `misc.go`, or `common.*`; when classes/types use `Manager`, `Helper`, `Util`, `Data`, or `Info` suffixes; when commented-out code is about to be committed; when writing a docstring on an internal helper.

Use when the user asks to refactor or restructure code without changing behavior; when a planned rewrite or "big-bang" refactor is on the table; when renaming a widely-used symbol or moving a module across the codebase; when introducing an interface to replace direct concrete dependencies; when untested legacy code needs structural changes; when tests are red between intermediate refactor commits; when considering a long-lived refactor branch; when incrementally replacing a legacy subsystem; when a refactor PR is also adding behavior; when extracting a service from a controller or splitting a class along SRP lines.

Use when designing classes, services, or modules; when a class is doing too many things; when introducing inheritance; when an interface forces clients to depend on methods they don't use; or when high-level code reaches for low-level concrete classes.

Use when asked to review code for security; before deploying auth, payment, or other sensitive code paths; when handling user input, secrets, or API endpoints; or when the word "security" appears in a task.

Use when designing how objects interact, communicate, or distribute responsibilities; when modeling state transitions; when several handlers might process a request; when undo/redo, queueing, or logging of operations is needed; when one object's change must notify many; or when picking among interchangeable algorithms at runtime.

Use when designing object construction logic; when a constructor takes many arguments; when which concrete class to build depends on runtime input; when complex initialization spans many steps; when shared state needs a single access point; or when copying complex objects.

Use when composing or wrapping objects; when bridging incompatible interfaces; when building tree-like structures (menus, file systems, AST); when adding cross-cutting behavior (logging, caching, auth) without modifying the wrapped object; when a subsystem needs a simple front door; or when many fine-grained objects share state.

Use when the user wants to "build", "add", "implement", or "design" a new feature; when a request is described in user-facing terms ("we want users to..."); when scope is fuzzy or stakeholders aren't aligned; before a technical plan is written. Skip for pure refactors, bug fixes, and tooling changes.