メニュー
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Check active Linear tickets with comprehensive status overview
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Alembic 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).
| 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-side