メニュー
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] GitHub PR operations via gh CLI. Use when creating reviews, replying to comments, or fetching PR data. CRITICAL - Always create reviews as drafts by omitting the event field.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | ezra-github-ops |
| description | [NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] GitHub PR operations via gh CLI. Use when creating reviews, replying to comments, or fetching PR data. CRITICAL - Always create reviews as drafts by omitting the event field. |
Comprehensive reference for GitHub pull request operations using the gh CLI and API.
For detailed command patterns and syntax, see Command Reference.
When creating a new PR review with inline comments, ALWAYS create it as a pending/draft review first.
DO NOT include an event field when creating the review. Omitting event creates a pending review (draft state) that the user can review and submit from the GitHub UI.
CRITICAL: Only include event field when user explicitly requests submission.
| Value | Behavior | When to Use |
|---|---|---|
| Omit field | Creates draft/pending review | DEFAULT - Always use this |
"PENDING" | Creates draft/pending review | Same as omitting |
"COMMENT" | Submits immediately as comment | Only if explicitly requested |
"APPROVE" | Submits immediately as approval | Only if explicitly requested |
"REQUEST_CHANGES" | Submits immediately requesting changes | Only if explicitly requested |
When authoring PR reviews, follow these principles for tone and content:
Write as the reviewer, not as an AI: Use natural, conversational language — not checklist reports or robotic phrasing
Keep it conversational: Frame observations as you would in a normal code review
Only post inline comments for actionable items — things the author should change, consider, or respond to.
Write in plain language — no severity prefixes, no bold labels. The comment should read like something a colleague typed, not a categorized finding.
Do NOT post:
If there are no actionable items, a body-only approval is the correct review. That's not "just a comment" — it's a clean approval.
The ezra-review-code skill's Output Format (Necessary/Correct/Complete structure) is an internal analysis framework for your reasoning. Do NOT copy it verbatim into a GitHub review. Summarize your findings in natural language instead.
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).
