Ywc Create Pr

Create PR

Announce at start: "I'm using the ywc-create-pr skill to commit and open a pull request."

Commit changes and create a draft PR following the PR template.

Rationalization Defense

When tempted to skip a step, check this table first:

| Excuse | Reality | |---|---| | "User said 'create PR' — they obviously want it merged too" | Default is draft PR. Mark ready/merge only when explicitly asked. | | "CI check is slow, just push and let CI run remotely" | Local CI catches failures before review delay. Skip only with --skip-ci-check. | | "Force push will resolve the rejection faster" | Non-fast-forward = teammate work or rebase needed. Force only with explicit user approval. | | "The PR template is generic, my custom body is better" | If .github/pull_request_template.md exists, follow it. Templates encode team norms. | | "Secret scan flagged a value but it's just a test fixture" | Stop and confirm with the user before bypassing the scan. Better to over-confirm than leak. | | "Base branch is obvious from history" | Auto-detect order is develop → main → master. Show the chosen base before proceeding. | | "The hook is just being pedantic, CLAUDE_MD_CHECK=skip git push will fix it" | Inline VAR=value git push does NOT reach the hook subprocess — the hook runs before the command executes. Use export VAR=value && git push in a single Bash call instead, or instruct the user to run ! VAR=value git push in their terminal. | | "CI passed locally, so remote CI will pass too" | Remote CI may use different OS runners, Node versions, or environment secrets unavailable locally. Always verify remote CI after pushing — local and remote diverge more often than expected. | | "CI is slow — let the reviewer catch failures" | CI failures signal a broken branch to every reviewer. Fix them immediately after PR creation so the PR stays reviewable and avoids a second round-trip after the reviewer waits for another push. | | "CI is green, so the PR is ready to merge" | CI status and merge-readiness are independent gates. A green PR can still be CONFLICTING against the base if the base advanced. Check gh pr view --json mergeable,mergeStateStatus before declaring the PR done — a CONFLICTING/BEHIND/BLOCKED PR blocks every reviewer just like a CI failure. | | "The PR conflicts with base — I'll rebase the feature branch to fix it" | Rebasing rewrites commit SHAs and orphans existing PR review threads. Merge the base into the feature branch instead (git merge --no-ff origin/); it preserves SHAs and review history. See references/pr-conflict-resolution.md. | | "The UL update adds noise before every PR" | The update is a diff-driven incremental review, not a full re-extraction. If no new domain terms appeared in the branch, the skill produces no changes. Skipping it lets the glossary drift from the codebase with every PR that introduces new vocabulary. | | "I generated this code, I know it is fine — just file the PR" | Filing code whose diff you have not read yourself inflicts unreviewed code on every reviewer. Read each changed line first (Step 6.5); it catches scope creep, leftover debug output, and secrets the generation step introduced — the cheapest review pass there is. |

Violating the letter of these rules is violating the spirit. If you find yourself rephrasing a rule to make an exception, stop and ask the user.

Context

• Changed files: !git status --short
• Current branch: !git branch --show-current

Task

Follow the steps below to commit and create a PR.

0. Language and Title Initialization

1. Title: Check $ARGUMENTS for --title "". If present, store it as the PR title — it will be used verbatim in Step 7 (skip self-generated title).
2. Language: Check $ARGUMENTS for a language hint (e.g., --lang ja, --language korean). If a --lang flag is present, use it. Otherwise resolve the output language via the shared resolution reference before prompting.

> Action required: Read [../references/language-resolution.md](../references/language-resolution.md) — it defines how a configured policy is resolved. If a policy resolves, write the PR title and body in that language and skip the language prompt entirely (AC6).

Only when resolution yields nothing (no --lang, no policy) and no --title was provided, use the AskUserQuestion tool to ask: "What language should the PR title and description be written in?" with the full option set English / Japanese / Korean / Spanish / Chinese (en | ja | ko | es | zh) — then immediately continue to Step 0.5 in the same turn; do not end the turn or wait for further input after receiving the answer. If --title was provided, it is used verbatim in Step 7 and a resolved policy governs only the body language (EC4); with no policy, infer the body language from the title or default to English — do not prompt. The title's [task-id] / conventional prefix always stays English.

1. Apply the chosen language consistently when writing the PR description in Step 7.
2. Post-CI check: Check $ARGUMENTS for --skip-post-ci-check. If present, skip Step 8 (Remote CI & Bot Review). This flag is passed by ywc-finish-branch, which handles CI verification independently in its own Step 4.
3. Ubiquitous Language update: Check $ARGUMENTS for --skip-ubiquitous-update. Store the flag — it controls Step 0.5.

0.5. Ubiquitous Language Update (optional)

Skip this step if --skip-ubiquitous-update is present in $ARGUMENTS. This flag is passed by ywc-finish-branch, which runs the update in its own Step 1.5 before delegating PR creation to this skill.

Check whether docs/ubiquitous-language.md exists in the project root:

test -f docs/ubiquitous-language.md

• Exists: Invoke ywc-ubiquitous-language --mode update. Any changes to docs/ubiquitous-language.md will be picked up and committed by Step 4.
• Not exists: Skip silently — the project has not yet established a ubiquitous language document.

1. Determine Base Branch

• If a base branch is specified in $ARGUMENTS, use it
• Otherwise, auto-detect the default base branch in the following priority order:

1. develop — if it exists locally or in remote (git rev-parse --verify develop 2>/dev/null || git rev-parse --verify origin/develop 2>/dev/null)
2. main — if it exists locally or in remote
3. master — fallback

• Store the determined base branch and use it consistently throughout all subsequent steps
• Show the determined base branch to the user: "Base branch: ``"

2. Pre-flight Checks

Before proceeding, verify the environment is ready:

• Confirm gh CLI is installed and authenticated (gh auth status). If not, stop and tell the user how to set it up
• Check if a PR already exists for this branch (gh pr list --head --state open). If one exists, show the URL and ask the user whether to update it or create a new one
• If update: Skip PR creation (Step 7), but do not skip Step 8. Commit and push changes, optionally update the PR description with gh pr edit --body-file -, then proceed to Step 8 (Remote CI & Bot Review Check). Updating a PR can break CI exactly like creating one — the verification must run on the update path too, not only on the new-PR path (unless --skip-post-ci-check was passed by an upstream caller).
• If new: Continue with the full workflow
• Verify the current branch is not the base branch itself — refuse to create a PR from main/develop/master to itself

3. Security Check

Run the bundled secret scan script:

# Phase 1+2: dangerous file names + staged/unstaged diff content
bash claude-code/skills/ywc-create-pr/scripts/scan-secrets.sh --staged

# Phase 3: all commits on this branch vs base (secrets already committed)
bash claude-code/skills/ywc-create-pr/scripts/scan-secrets.sh --committed 

Exit 0 = clean — proceed. Exit 1 = secrets or dangerous files found — the script prints matches to stdout.

If either scan returns exit 1, warn the user and show the script output. Do not include flagged files in the commit unless the user explicitly confirms. For committed secrets (second scan), require explicit confirmation before proceeding to PR creation.

4. Commit Uncommitted Changes

• Check uncommitted changes with git status and git diff
• If there are uncommitted changes, delegate to ywc-commit with --skip-ubiquitous-update:
• Why the flag: Step 0.5 of this skill already invoked ywc-ubiquitous-language --mode update (unless this skill itself was called with --skip-ubiquitous-update by an upstream caller like ywc-finish-branch). Without the flag, ywc-commit's own Step 0.5 would run the update a second time. The flag must always be passed in this delegation — even when this skill's Step 0.5 was skipped, because the upstream caller is the one responsible for the UL update in that scenario.
• ywc-commit classifies every changed file as IN / UNKNOWN / OUT relative to the current session, splits logically distinct changes into separate commits, and learns the project's commit message style from git log
• It will confirm with the user before staging any UNKNOWN or OUT files — do not skip that confirmation
• Follow the repository's observed co-author trailer convention; do not force-add a trailer if the repository does not already use one
• If there are no uncommitted changes: skip this step

5. CI Check (Pre-push Validation)

Run the same lint, format, typecheck, and test checks locally that CI will execute. The goal is to catch failures before pushing, since CI failures delay PR review.

Skip this step if --skip-ci-check is present in $ARGUMENTS.

5-1. Detect CI Check Commands

Run the bundled detector first — it emits candidate commands from each source plus the package manager, so you do not re-derive the same greps each run:

bash claude-code/skills/ywc-create-pr/scripts/detect-ci-commands.sh [repo-dir]

It is best-effort; reconcile its output against the priority order below (workflows are authoritative, then CLAUDE.md, then package.json, then Makefile):

1. .github/workflows/*.yml — Read CI workflow files and extract active check commands

• Look for run: fields containing lint, format, typecheck, type-check, test, check
• Exclude deployment-related jobs/steps (deploy, release, publish, docker build)
• Prioritize workflows with on: pull_request or on: push triggers

1. CLAUDE.md — Search the project root CLAUDE.md (or parent directory) for lint, format, typecheck, and test commands
2. package.json scripts — Use scripts whose keys match lint, format, typecheck, type-check, or test
3. Makefile — Use targets named lint, format, check, or test

If no commands are detected, skip this step and inform the user of the reason.

5-2. Detect Execution Environment

• If CLAUDE.md specifies a docker exec prefix, apply it to all commands
• Determine the package manager (pnpm, npm, yarn, etc.) from the lock file

5-3. Run Checks

• Execute all detected check commands in sequence (recommended order: lint → format → typecheck → test)
• Record the pass/fail result of each command
• Continue running remaining commands even if one fails — report all results together at the end

5-4. Report Results and Next Steps

• If all checks pass, proceed to the next step (Push)
• If any check fails:
• Summarize which checks failed and what the errors were
• Present the user with two options:

1. Fix and retry — Resolve the issues, then re-commit and re-run checks
2. Skip and proceed — Ignore the check failures and continue to Push & PR creation

6. Push to Remote

• Check if the current branch is already up-to-date with the remote (git status -sb — look for ahead count). If the branch is already pushed and there are no new local commits, skip the push
• Push to remote with git push -u origin HEAD
• If push fails due to a PreToolUse hook error (error message contains "hook error" or "Blocked:"):

1. Read the full hook error message — it usually states exactly what is required or how to bypass
2. Look for a bypass env var hint (e.g., CLAUDE_MD_CHECK=skip, SKIP_CHECK=true). If found:

• Retry with export = && git push -u origin HEAD in a single Bash call
• Why: VAR=value git push sets the variable only for the git process, not for the hook subprocess that runs before it. Exporting in the same shell command makes the variable available to the hook

1. If the hook requires a content action (e.g., "update CLAUDE.md before pushing"):

• Evaluate whether the requirement genuinely applies to the changed files
• If yes: fulfill the requirement (e.g., update CLAUDE.md), then retry the push normally
• If no (e.g., changes are test fixtures or QA docs with no documentation impact): use the bypass approach in step 2

1. If the bypass attempt also fails or no bypass is indicated, instruct the user to run this in their terminal:

`` ! export = && git push origin HEAD ` Explain: the !` prefix runs the command directly in the user's shell session, where the exported variable reaches the hook subprocess. Continue to Step 7 once the user confirms the push succeeded

• If push fails due to remote changes (non-fast-forward):
• Suggest git pull --rebase origin to the user (rebase against the same feature branch, not the base branch)
• Do not force-push without explicit user approval

6.5. Author Self-Review Gate (mandatory)

Before filing the PR, read your own diff end to end. Do not file code you have not reviewed yourself — unreviewed code shifts the cost of your mistakes onto every reviewer. This gate has no skip flag.

git diff ...HEAD

Read the full output and confirm each row. If any fails, fix it before Step 7:

| Check | Reject if | |---|---| | Intent traceability | A changed line does not trace to this session's request (scope creep) | | No debug residue | Leftover console.log / print / dbg!, commented-out blocks, or FIXME/TODO introduced by generation | | No drive-by edits | Unrelated reformatting, renames, or "improvements" outside the task | | No secrets | Hardcoded keys, tokens, or credentials (Step 3 scans patterns; this is the human-readable cross-check) | | Convention fit | Naming and structure match the surrounding code |

This is the author's own pass, not an approval — it does not replace independent review. For a thorough multi-aspect review before filing, run ywc-impl-review (architecture / design / devex / security / QA); that pass stays opt-in, this self-review does not.

7. Create PR

• Check if .github/pull_request_template.md exists
• If exists: Read the template and create the PR description following its structure
• If not exists: Create a PR description with the following default structure:

```markdown ## Summary

[1-3 bullet points summarizing the changes]

## Changes

[List of specific changes made]

## Test Plan

[How to verify the changes] ```

• Write each section based on all commits from the base branch (git log ..HEAD)
• Review the full diff (git diff ...HEAD) to ensure the description accurately reflects the changes
• PR title: if --title was provided in Step 0, use it verbatim. Otherwise, generate a title from the commit history in the language chosen in Step 0.
• Write all description content in the language chosen in Step 0
• If there are no UI changes, write "N/A" in the screenshot section (if the template has one)
• Create a draft PR with `gh pr create --draft --base --title "" --body-file - --log-failed

```

1. Categorize and fix by failure type:

| Failure type | Fix action | |---|---| | Lint / format | Run the project's auto-fix command (eslint --fix

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: yongwoon
• Source: yongwoon/ywc-agent-toolkit
• License: MIT

Install and usage instructions live in the source repository linked above.