メニュー
Commit, push, and open a GitHub Pull Request following this repo's promotion chain (dev -> stage -> tag). Use on "create pr", "open a pr", "/create-pr", or "promote <branch>".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
| name | create-pr |
| description | Commit, push, and open a GitHub Pull Request following this repo's promotion chain (dev -> stage -> tag). Use on "create pr", "open a pr", "/create-pr", or "promote <branch>". |
This repo is on GitHub (github.com/blurifycom/openora). Use the gh CLI. Branches are promoted along a fixed chain - never open a PR straight to stage from a feature branch.
| Source (current) branch | PR target | Notes |
|---|---|---|
dev (default working) | stage | Promote accumulated work to staging |
stage | (git tag) | Cut a release tag, no PR (see Release) |
any feat/* / fix/* | dev | Feature work merges into dev first |
Any other branch: target dev.
git branch --show-current -> the table above.git status -s. Commit ONLY changes belonging to this unit of work. Foreign/pre-existing edits in the tree: stage your files explicitly, tell the user what you left out. Never git add -A blindly.conventions section 12). No AI attribution trailers. Keep the message free of sensitive/internal data (below).pnpm verify. Don't push a red tree.dev, stage) especially. Only after the yes: git push -u origin <current>..github/PULL_REQUEST_TEMPLATE.md) - don't invent a structure: Summary (what, then why - bare ticket key, no URL), Changes (a reviewer map per module/area), Acceptance criteria (from the ticket), the Checklist (tick what actually passed), Notes (deferred / out-of-scope), and Closes <KEY>.
gh pr create --base <target> --head <current> --title "<type>(<scope>): <summary>" --body-file <filled-template>
gh pr list --head <current> --base <target>).-> tag step)Production is a git tag cut from stage: git tag vX.Y.Z && git push origin vX.Y.Z. Only on an explicit user request; confirm the version first.
They are the public-facing record. Never include: internal URLs (Jira/Confluence/Slack/Notion, dashboards, CI links - reference a ticket by bare key, eg ABC-45), secrets, tokens, customer/operator names, PII, internal IPs/hostnames/paths. When in doubt, leave it out.
pnpm verify must pass before the push.SOC 職業分類に基づく
Deliver an OSS platform-core feature end-to-end: context collection -> plan + approval -> implementation -> unit/integration tests -> e2e test cases + run -> fixes -> create-pr -> Jira transition (only on explicit ask) -> Slack notice. Fed by a work-order (from the consumer add-feature handoff) or an OSS ticket. Use on "add feature", "plan <work-order>", "deliver this OSS change", or /add-feature [path|ticket]. Read-only until the plan is approved; never pushes without explicit OK.
Multi-agent code review of the working branch against this repo's conventions, boundaries, contracts, security, messaging, and audit rules. Fans out a configurable number of parallel reviewers, each grounded in the rule docs, then synthesizes one verdict. Use on "review this", "oss review", "/oss-review", optionally "--agents N", "--base <ref>", "--fix", a GitHub PR number, or paths.
Context-aware PR review - gathers ticket AC + PR discussion, reviews from fixed angles (security, performance, duplication, simplification, conventions, igaming fit), and returns line-anchored draft comments plus a one-sentence go/no-go. Token-budgeted so it runs fine on capped plans. Use on "review", "/review", "review this PR", optionally a PR number or "--base <ref>".
Deliver a feature end-to-end in this consumer repo. Aggregates context (Jira + Confluence + Slack + Google Drive + Notion + local docs + past sessions + codebase), produces an approved plan, then drives delivery by calling sibling skills - create-plugin (build), review, create-pr (MR) - and create-task for ticket hygiene. Transitions Jira (no comments) and drafts a one-line Slack notice. Use on "add feature", "plan <KEY>-XXX", "deliver <KEY>-XXX", or /add-feature [<KEY>-XXX]. Read-only until the plan is approved; never pushes, transitions Jira, or sends Slack without OK.
Guided creation of an extension - the right way to add behavior or swap a vendor without touching `@openora/*` core. Interviews for intent, classifies the seam (plugin / adapter / page / route), runs the matching scaffold command, wires extensions.config.ts, and enforces boundaries + audit + db rules. Use on "create plugin", "add an extension", "swap KYC/PSP", "mount a page", "/create-plugin <name>".
Commit, push, and open a GitLab Merge Request following this repo's promotion chain (dev -> stage -> prod). Use on "create pr", "create mr", "open a pr/mr", "/create-pr", or "promote <branch>".
