메뉴
Create a pull request after verification and docs are updated. Runs final checks, detects doc gaps, and delegates to the project's pr-draft skill if available. Use this skill when the user says 'pr', '/pr', 'ship', 'ship it', 'create pr', 'open pr', 'ready to merge', 'let's ship', or after /review and /docs complete.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Take a bug, ticket, or feature from investigation all the way to a draft PR in one autonomous run — `/goal` planning plus the full ystack chain (/build → /go → /qa → /review → /docs → /pr), orchestrated end-to-end without stopping between phases. Use this skill when the user says 'yolo', '/yolo', 'ship it', 'just ship it', 'do the whole thing', 'full pipeline', 'investigate and fix and PR', 'end to end', 'take this to a PR', or hands over a ticket or bug and wants it shipped autonomously rather than only planned. If the user wants ONLY a plan, that's /goal or /build; for a trivial change, that's /quick; to handle reviewer comments on an existing PR, that's /address-review.
Fetch PR review comments, triage them by priority, and address them. Use this skill when the user says 'address review', '/address-review', 'address comments', 'fix review comments', 'address feedback', 'handle PR comments', 'review feedback', 'what do reviewers say', 'check PR comments', or when a PR has review comments that need to be addressed. Works with comments from human reviewers, AI reviewers, and CI checks.
Browser automation for QA testing via Playwright MCP. Navigate pages, click elements, fill forms, take screenshots, check console errors, and verify page state. Used by /qa for visual testing. Use this skill when the user says 'browse', '/browse', 'open browser', 'check the page', 'screenshot', or when /qa needs to test affected pages. Requires Playwright MCP to be registered (see Setup).
Plan a feature by reading documentation and code, surfacing assumptions, capturing decisions, and creating an execution plan with goal-backward success criteria. Use this skill when the user says 'build', '/build', 'implement', 'add feature', 'plan feature', 'I want to build', 'let me build', 'work on', or describes a feature they want to implement. This is the entry point for the ystack workflow — it produces a PLAN.md that /go executes, plus a local plan.html preview for user approval.
Update documentation for completed work. Only updates docs for features that are implemented and verified — never for planned or in-progress work. Use this skill when the user says 'docs', '/docs', 'update docs', 'update documentation', 'sync docs', or after /review passes and before /pr.
Execute a plan created by /build. Runs each task with a fresh subagent, produces atomic commits, and updates progress files. Use this skill when the user says 'go', '/go', 'execute', 'run the plan', 'execute the plan', 'start building', 'let's do it', or confirms a plan and wants to proceed with implementation. Requires a PLAN.md from a prior /build run.
| name | pr |
| description | Create a pull request after verification and docs are updated. Runs final checks, detects doc gaps, and delegates to the project's pr-draft skill if available. Use this skill when the user says 'pr', '/pr', 'ship', 'ship it', 'create pr', 'open pr', 'ready to merge', 'let's ship', or after /review and /docs complete. |
| compatibility | Designed for Claude Code |
| metadata | {"user-invocable":"true"} |
You are the final step of the ystack workflow. You verify everything is ready, then create a pull request.
--base <branch> — the PR's target branch (what it merges into). Overrides the
default-branch auto-detection. Example: /pr --base staging. When omitted, the base is
resolved dynamically from git symbolic-ref refs/remotes/origin/HEAD (falling back to
main). The resolved value is reused for both the documentation-check diff and
gh pr create --base.Run all checks before creating the PR. If any fail, stop and report.
Check if /review has been run:
ls .context/*/PLAN.md 2>/dev/null
If a PLAN.md exists, check whether all success criteria have been verified. If not:
Success criteria haven't been verified. Run
/reviewfirst?
Detect if code changes affect documented modules:
# Target branch (BASE): the --base <branch> argument if the user gave one (ARG_BASE),
# otherwise the repo's default branch resolved dynamically.
BASE="${ARG_BASE:-$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||' || echo main)}"
# Get changed files
git diff "$BASE"...HEAD --stat
# Check if any changed packages map to doc pages
# Read .ystack/config.json or scan docs structure
If this is a /quick change (.context/.quick exists): skip doc check entirely. Quick fixes don't need doc updates.
If this is a feature (.context/<feature>/PLAN.md exists):
Read .ystack/progress/<module>.md for newly checked [x] items.
Check if the linked doc sections still have <!-- ystack:stub -->.
If stubs remain:
Feature OAuth is checked off but docs still have stubs. Running
/docsto fill them in...
Run /docs inline — don't just warn, actually execute the doc update. Then continue with the PR.
If no stubs and no doc changes needed, proceed.
If unsure (no plan, no quick marker): fall back to a warning:
Code changes in payments but docs weren't updated. Run
/docsto update, or confirm docs don't need changes.
pnpm fix 2>/dev/null # or the project's lint fix command
pnpm typecheck 2>/dev/null
pnpm check 2>/dev/null
If any fail, report the errors and offer to fix.
git status
All changes should be committed. If there are unstaged changes, ask the user what to do.
pr-draft skillDelegate to the project's pr-draft skill. It knows the project's PR conventions, monorepo grouping, and section format. Pass the resolved base branch through (the --base value) so it opens the PR against the right target.
Delegating to
pr-draftfor PR creation...
pr-draft skillCreate the PR directly:
Ensure branch is pushed:
git push -u origin HEAD
Generate PR title — Conventional Commits format:
feat(payments): add refund reason tracking
Generate PR body from the plan and changes:
## Summary
- [What was built and why, 1-3 bullets from DECISIONS.md]
## Changes
- [Grouped by package/module from the diff]
## Verification
- [Success criteria from PLAN.md, marked as checked]
## Test Plan
- [ ] `pnpm typecheck` passes
- [ ] `pnpm check` passes
- [ ] [Feature-specific manual test steps]
Ask about PR status:
Create as draft or ready for review?
Create the PR (target the resolved $BASE branch):
gh pr create --title "<title>" --body "<body>" --base "$BASE" [--draft]
After the PR is created:
Verify progress — confirm all features in scope are checked in .ystack/progress/<module>.md.
Archive .context/ — don't delete, just note it's done:
Feature context at .context/<feature-id>/ can be cleaned up.
Report:
PR created: <URL>
## Summary
- Feature: <name>
- Commits: N
- Files changed: N
- Docs updated: yes/no
- All criteria verified: yes
/go./review./docs. But it DOES check if docs need updating.