flow-detector

Flow Detector

Detect end-to-end flows for a vague task. Output is structured candidates, not questions.

Activation Triggers

This skill activates when:

• The user runs /clarify "<task>" or invokes @clarifier.
• The user describes a task using vague verbs: send, notify, sync, handle, process, integrate, support, fire, dispatch, push, alert, log.
• The user mentions a ticket reference and the description doesn't fully pin down the implementation surface.

Core Principle

Every candidate flow is a complete answer, not a piece of one. The user picks between whole flows, not between individual dimensions. Do not emit candidates that differ only in trivial parameters (timeout values, log level, retry count) — those are defaults inside one flow.

Process

1. Read the task description

Extract:

• The verb (what is being done)
• Any explicit entity mention (User, Tenant, Order, etc.)
• Any explicit trigger mention (on signup, after payment, etc.)
• Any explicit recipient mention (to the user, to the team, etc.)

2. Ground in the codebase

Before generating candidates, scan the repo for evidence:

• Entities: search for likely model files — User, Tenant, Org, Account, Workspace, Team, Member. Note which exist.
• Auth surfaces: search for sign-in, signin, login, signup, register, authenticate, auth/, /api/auth. Note routes/handlers.
• Notification channels: search for email senders (sendgrid, ses, resend, mailer), push (fcm, apns, expo), in-app (notifications table/service), SMS (twilio).
• Async infrastructure: queues (bullmq, celery, sidekiq), background jobs, event buses.
• Failure infrastructure: retry libs, dead-letter queues, error reporters (sentry, bugsnag).

Anchor every candidate in symbols you found. A candidate that mentions infrastructure the repo doesn't have is a defect — either reframe the candidate as "build new X" or drop it.

3. Generate candidates