en un clic
api-create-worker
// Create a new background worker in daily-api with full type safety, infrastructure config, and tests
// Create a new background worker in daily-api with full type safety, infrastructure config, and tests
Add a new GraphQL mutation to an existing schema in daily-api with validation, resolvers, and tests
Add a new GraphQL query endpoint with type safety, GraphORM integration, and tests
Wraps any prompt with a reminder to respect CLAUDE.md files
Format TypeORM migrations with beautifully formatted SQL code. Use this skill after generating migrations to ensure consistent SQL formatting.
Local environment management - run SQL queries, set up fake payments, reset test data. Use when the user needs help with local database operations or test data setup.
| name | api-create-worker |
| description | Create a new background worker in daily-api with full type safety, infrastructure config, and tests |
| argument-hint | [worker name and purpose] |
You are creating a new background worker for daily-api. Follow this skill step by step.
Before writing any code, read these files for code style rules and worker conventions:
AGENTS.md (project root) — code style, architecture, best practicessrc/workers/AGENTS.md — worker-specific patterns, types, and conventionsThese are the source of truth for all code style decisions. Do not deviate from them.
Before writing any code, ask the user the following questions in this order:
TypedWorker (standard) or TypedNotificationWorker?
TypedWorker — standard worker with handler(message, con, logger) returning Promise<void>TypedNotificationWorker — notification worker with handler(data, con, logger) returning NotificationHandlerReturnThis determines the handler signature, return type, registration target, and file template.
What topic does this worker subscribe to?
This determines the subscription config and schema lookup.
What is the message type? One of:
- (a) Existing Protobuf type from
@dailydotdev/schema- (b) Existing type already in
PubSubSchema(checksrc/common/typedPubsub.ts)- (c) New type — describe the fields
This determines whether to add a schema entry, wire up parseMessage, or reference an existing type.
What should the worker do when it receives a message?
Core implementation details.
Based on the message type answer from Step 0:
@dailydotdev/schemaImport the type and add an entry to PubSubSchema in src/common/typedPubsub.ts mapping the topic to the imported Protobuf type. The worker will need a parseMessage function using .fromBinary().
Reference: src/workers/opportunity/storeCandidateOpportunityMatch.ts — uses MatchedCandidate.fromBinary(message.data).
PubSubSchemaSkip this step — just reference the existing topic key in the worker's generic parameter.
Add a new entry to PubSubSchema in src/common/typedPubsub.ts:
export type PubSubSchema = {
// ... existing entries
'your-topic-name': {
field1: string;
field2: number;
};
};
Create the worker file at src/workers/[name].ts (or src/workers/[domain]/[name].ts for domain-specific workers).
Reference examples: src/workers/feedbackClassify.ts (standard), src/workers/opportunity/storeCandidateOpportunityMatch.ts (Protobuf with parseMessage).
import { TypedWorker } from './worker';
const worker: TypedWorker<'topic-name'> = {
subscription: 'subscription-name',
handler: async (message, con, logger): Promise<void> => {
const { data, messageId } = message;
},
// For Protobuf types only — add parseMessage:
// parseMessage: (message) => YourProtoType.fromBinary(message.data),
};
export default worker;
Reference example: src/workers/notifications/achievementUnlockedNotification.ts.
import { TypedNotificationWorker } from '../worker';
const worker: TypedNotificationWorker<'topic-name'> = {
subscription: 'subscription-name',
handler: async (data, con, logger) => {
// data is already parsed (no message wrapper)
// Return NotificationHandlerReturn
},
};
export default worker;
Registration depends on worker type:
| Worker Type | Registration File | Array |
|---|---|---|
TypedWorker | src/workers/index.ts | typedWorkers |
TypedNotificationWorker | src/workers/notifications/index.ts | notificationWorkers |
For TypedWorker: add import + entry to the typedWorkers array in src/workers/index.ts.
For TypedNotificationWorker: add import + entry to the notificationWorkers array in src/workers/notifications/index.ts. These are automatically wrapped via notificationWorkerToWorker and spread into the main workers array.
Add a subscription entry to the workers array in .infra/common.ts:
{
topic: 'topic-name',
subscription: 'subscription-name',
args: { /* optional: ackDeadlineSeconds, deadLetterPolicy */ },
},
Note: Topics are managed in the separate "streams" repository. This step only adds the subscription.
Create an integration test at __tests__/workers/[name].ts.
Reference: __tests__/workers/feedbackClassify.ts for a complete TypedWorker test example.
Follow the pattern in __tests__/workers/feedbackClassify.ts. Every test file should include:
typedWorkers (or workers for notification workers) by subscription nameexpectSuccessfulTypedBackground<'topic-name'>(worker, { ... }) with the generic type parameter for type safetyFor TypedNotificationWorker, check registration in the workers array (which includes wrapped notification workers) instead of typedWorkers.
| Purpose | Path |
|---|---|
| PubSub schema types | src/common/typedPubsub.ts |
| Worker file | src/workers/[name].ts |
| Worker registration (typed) | src/workers/index.ts → typedWorkers |
| Worker registration (notification) | src/workers/notifications/index.ts → notificationWorkers |
| Infra subscription config | .infra/common.ts → workers |
| Test file | __tests__/workers/[name].ts |
| Code style reference | AGENTS.md, src/workers/AGENTS.md |
When the user invokes this skill:
AGENTS.md and src/workers/AGENTS.md for context