메뉴
Enrich GitHub PR descriptions with root-cause context, related issues/PRs, and CC mentions. Use when creating or editing a PR, when a PR has an empty or sparse description, or when the user asks to improve a PR description.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | gh-enrich-pr-description |
| description | Enrich GitHub PR descriptions with root-cause context, related issues/PRs, and CC mentions. Use when creating or editing a PR, when a PR has an empty or sparse description, or when the user asks to improve a PR description. |
Analyze branch changes and git history to build a rich PR description with three sections: a contextual summary, related issues/PRs, and people to CC.
gh pr create)Run these in parallel to understand the full picture:
# Current branch and diff against base
git log --oneline main..HEAD
git diff main...HEAD
# PR if it already exists
gh pr view --json number,title,body,url,baseRefName,headRefName 2>/dev/null
For each changed file, dig into the history to understand the origin of the problem:
# Blame the changed lines on the base branch to find who introduced them
git blame main -- <file> | sed -n '<start>,<end>p'
# Show the originating commit
git log -1 --format='%H %an <%ae> %s' <commit-sha>
# Find the PR that introduced the commit
gh pr list --search "<commit-sha-prefix> OR <ticket-id>" --state merged --json number,title,author,url
Key questions to answer:
Search for related work using ticket IDs, keywords, and function names:
# By ticket ID from branch name or commit messages
gh pr list --search "<TICKET-ID>" --state all --json number,title,author,url,state
# By keywords from the change
gh pr list --search "<keyword>" --state all --limit 10 --json number,title,author,url,state
Classify each related PR/issue:
From git blame and related PRs, collect GitHub usernames of people who:
git blame)Extract GitHub usernames from PR data:
gh pr view <number> --json author --jq '.author.login'
Use this structure:
## Summary
[2-4 sentences explaining WHAT changed and WHY. Focus on the root cause
and why the previous behavior was wrong. Include the mechanism of failure.]
> [!NOTE]
> [Optional callout for additional context, such as a sibling function
> that handles the same case correctly, or a related convention.]
## Related
- #<number> -- <relationship>: <brief description>
- #<number> -- <relationship>: <brief description>
CC @<username> @<username>
For an existing PR:
gh pr edit <number> --body "$(cat <<'EOF'
<composed description>
EOF
)"
For a new PR, pass it to gh pr create --body.
Ask structured questions one at a time to gather requirements, context, or clarification. Each question includes the intention behind it and current assumptions. Use when the user wants to be interviewed about a topic, gather requirements, or needs help thinking through a problem step by step.
Design new Datadog dashboards, redesign existing ones, or audit dashboards for operational readiness. Covers widget selection, layout organization, template variables, group structure, tab organization, alert threshold validation, and zero-knowledge readability. Uses pup CLI for inspecting dashboards and validating designs. Use when designing new dashboards, redesigning existing ones, auditing before on-call handoff, or reviewing after dashboard changes. Do not use for: (1) Datadog agent installation or configuration, (2) monitor/alert rule design, (3) APM instrumentation or tracing setup, (4) log pipeline configuration.
Review or create event definitions for event-driven architecture. Covers event names, payload field names, event_type identity, stream naming boundaries, and record metadata/context/payload placement for both domain events (event-sourcing) and integration events (cross-service). Use when designing a new event definition, reviewing an existing event definition, or auditing event definition consistency across a catalog. Do not use for full event modeling workflows (use trogonstack-eventmodeling skills), event schema evolution or migration strategy, or event store implementation design.
Step 6 of Event Modeling - Apply Conway's Law with swimlanes. Organize events into autonomous system parts that different teams can independently own. Use after defining inputs/outputs. Do not use for: planning feature slice implementation order (use eventmodeling-slicing-event-models) or defining command/read model boundaries (use eventmodeling-designing-event-models).
Step 1 of Event Modeling - Brainstorm all domain events from requirements. Extract every state-changing event the system could have. Use when starting event modeling from requirements or a new domain. Do not use for: arranging events in sequence (use eventmodeling-plotting-events), designing commands or read models (use eventmodeling-designing-event-models), or when a complete event list already exists.
Step 8 of Event Modeling - Completeness Check. Verify every field has origin and destination. Ensure complete event model before code generation. Use after all scenarios defined. Do not use for: architectural validation against event sourcing principles (use eventmodeling-validating-event-models) or elaborating Given-When-Then specs (use eventmodeling-elaborating-scenarios).