Menu
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Check active Linear tickets with comprehensive status overview
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | ezra-check-linear-tickets |
| description | [NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Check active Linear tickets with comprehensive status overview |
Review your active Linear tickets with a comprehensive, grouped status overview that catches tickets other queries miss.
Use ToolSearch with select: to load:
select:mcp__claude_ai_Linear__list_issuesselect:mcp__claude_ai_Linear__get_userRun two parallel queries — never use a state filter, as that misses Triage, Backlog, and other non-"started" statuses:
list_issues(assignee: "me", includeArchived: false, limit: 100)list_issues(query: "", limit: 50, includeArchived: false) — then filter results client-side to match the user's createdBy email (use get_user(query: "me") to get the email)Why no state filter? Linear's
state: startedonly returns In Progress and In Review. Triage, Backlog, Todo, and Upcoming are all excluded. Always filter client-side.
From the combined results:
Present tickets grouped by status in this priority order:
Within each group, sort by priority (Urgent → High → Normal → Low).
Display a summary table per status group:
### In Progress (2)
| Ticket | Title | Priority | Project |
|----------|------------------------------------|----------|----------------|
| DEV-2149 | Build Supabase-to-S3 Migration | Medium | Infrastructure |
| DEV-2100 | Fix health check endpoint | High | — |
After the main table, call out anything that may need attention:
Format anomalies as a short callout section:
### Needs Attention
- **DEV-2150** is in Triage with no assignee (you created it)
- **DEV-2091** is High priority but still in Todo
If there are no anomalies, skip this section.
state filter in queries — always fetch broadly and filter client-sideAlembic migration workflow for SQLAlchemy model changes, emphasizing autogeneration only, date-prefixed migration filenames, env.py model imports, review of generated revisions, and validation with upgrade commands and integration tests.
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Backend architecture patterns, API design, database optimization, and server-side best practices for Node.js, Express, and Next.js API routes.
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Clerk authentication patterns for the Ezra Next.js monorepo — server vs client auth, middleware strategies, Server Actions, API route protection, caching with auth, and token injection via authTokenProvider for Orval-generated hooks. Use when adding Clerk auth to a new app, protecting routes or actions, wiring auth tokens into API calls, debugging "unauthorized" or 401/403 errors, asking "how does auth work in this app", checking why an API call returns 401, protecting a page or Server Action, or implementing role/permission checks. Also use when touching middleware.ts, ClerkProvider, ClerkTokenSync, authTokenProvider, or any import from @clerk/nextjs. Do NOT use for Clerk SDK installation or initial project setup (see Clerk docs quickstart).
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development.
Advisory skill for evaluating and organizing backend domain packages according to DDD best practices and capability-oriented design. Use when creating new domains, reviewing existing domain boundaries, refactoring packages, or deciding where new business logic should live.
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Sentry SDK internals for the ezra_observability Sentry adapter — sentry_sdk.init configuration, StarletteIntegration/FastApiIntegration/SqlalchemyIntegration setup, EventScrubber denylist, before_send filters, PII rules, and adapter-level tests. ADAPTER AUTHORS ONLY. App code must use `from ezra_observability import get_observability` (see ezra-add-monitoring).