Skip to main content

create-draft-pr

Commit, push, and create a draft PR using the pr-description format, with UX flow context when relevant.

소스 정보

저장소
trycompai/crm
최근 소스 활동
2026년 8월 6일 07:09
감지된 SKILL.md 언어
영어
스타
11,950
포크
1,778

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
create-draft-pr
description
Commit, push, and create a draft PR using the pr-description format, with UX flow context when relevant.
user-invocable
true
# Create Draft PR Commit all changes, push to remote, and create a draft pull request with a focused generated description. ## Steps 1. Run `git status` to see changes 2. Run `git diff` to understand what changed 3. Run `git log` to see commit message style 4. If on `main`, create a new branch in the format `<initials>/<feature>` or the project's branch naming convention, then switch to it 5. Stage and commit changes with a concise message 6. Push branch to remote with `-u` flag 7. Generate the PR description using the `pr-description` skill's description format. 8. If the change is user-facing, workflow-oriented, or architectural, include a concise UX flow section using the `ux-flow-plan` style. 9. Create draft PR using `gh pr create --draft` 10. If you created the branch (were on `main`), switch back to `main` after the PR is created ## PR Body Format Use the `pr-description` skill's format as the base: ```markdown ## Summary <One sentence describing the overall change> - Additional note if needed - Another note if needed ## Problem Describe the issue being addressed. What was broken, missing, or suboptimal? Be specific about the root cause. ## Solution Explain the approach taken to fix the problem. Include code snippets only when they clarify the core approach. ``` When relevant, add this section between `Problem` and `Solution`: ````markdown ## UX Flow ```text Current flow └─ ... Desired flow └─ ... ``` ```` Only include `UX Flow` when it helps explain the product behavior, user journey, or architecture boundary. Keep it short and use the `ux-flow-plan` tree style. ## Rules - PR title should be succinct (no "feat:" prefix, but "fix:" is ok for bug fixes) - Use `pr-description` as the source of truth for PR body structure. - Include `UX Flow` from `ux-flow-plan` only when relevant; omit it for mechanical, dependency, or tiny internal changes. - Do NOT include a file-by-file summary of code changes. - Do NOT include a test plan with checkboxes. - Do NOT include "Generated with Claude Code" or similar footers - Keep the PR description concise and focused on intent and approach - Use HEREDOC for the PR body to preserve formatting
GitHub에서 보기