القائمة
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Generate PR descriptions from branch changes for creating or updating pull requests
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | ezra-describe-pr |
| description | [NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Generate PR descriptions from branch changes for creating or updating pull requests |
Generate a fact-dense PR description from the current branch's changes, suitable for creating or updating a pull request.
Read the PR description template:
docs/_templates/pr-description-template.md to understand the formatGather branch information:
git branch --show-currentgh pr view --json url,number,title,state,baseRefName 2>/dev/nullmain if no PR exists)git log main..HEAD --onelinegit diff main...HEADgh repo set-defaultAnalyze the changes thoroughly: (think deeply about the code changes, their architectural implications, and potential impacts)
Generate the description:
Present the description to the user:
Create or update the PR:
gh pr create --title "..." --body "..."PRs in this repo have a Macroscope bot that auto-generates summaries between HTML comment markers (<!-- Macroscope's pull request summary starts here --> ... <!-- ends here -->). When updating an existing PR:
gh pr view {number} --json body -q '.body'---/tmp/pr-body.md) — the Macroscope HTML comments contain characters that break shell quotinggh pr edit fails with a Projects Classic GraphQL error:
gh api repos/{owner}/{repo}/pulls/{number} -X PATCH -f body="$(cat /tmp/pr-body.md)" --jq '.html_url'
gh pr view {number} --json body -q '.body' | head -5Alembic 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).