원클릭으로 Manus에서 모든 스킬 실행

create-pr

스타18

포크2

업데이트2026년 7월 26일 22:36

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>".

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

blurifycom

blurifycom/openora

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

create-pr

This repo is on GitLab (<your-gitlab-project>). "PR" = Merge Request. Use the glab CLI (already installed). Environment branches are promoted along a fixed chain - never open an MR straight to prod from a feature/dev branch.

Promotion chain

Source (current) branch	MR target	Notes
`dev` (default working)	`stage`	Promote accumulated work to the staging env
`stage`	`prod`	Promote staging -> production
any `feat/` / `fix/` / `<KEY>-*`	`dev`	Feature/ticket work merges into dev first

If the current branch isn't in the table, target dev.

Steps

Determine source + target. git branch --show-current -> look it up in the table above to get the target.
Scope the commit. git status -s. Commit ONLY changes that belong to this unit of work. If unrelated/pre-existing edits are present, do NOT bundle them - stage your files explicitly and tell the user what you left out. Never git add -A blindly when foreign changes are in the tree.
Commit. Conventional-commit message (feat:, fix:, docs:, refactor:, chore:); for ticket work prefix the ticket key (e.g. feat(<KEY>-123): ...).
Verify before pushing (cheap insurance): run the repo's check (e.g. pnpm check:types && pnpm check:lint). Don't push a red tree.
Push the current branch - but STOP and get an explicit per-action "yes push" from the user FIRST. Report the commit SHA, then ask. Invoking this skill is NOT push authorization. Pushing to a shared/env branch (dev, stage, prod) without that explicit yes is forbidden. Only after the yes: git push -u origin <current>.
Open the MR with glab (only after the push is confirmed + done):
```
glab mr create --source-branch <current> --target-branch <target> \
  --title "<type>: <summary>" --description "<body>" --yes --remove-source-branch=false
```
For a long-lived env branch (dev, stage, prod) NEVER pass --remove-source-branch. Reuse an existing open MR for the same source->target instead of creating a duplicate (glab mr list --source-branch <current> --target-branch <target>).
Report the MR URL back to the user.

Rules

NEVER push without an explicit per-action "yes push" from the user. Invoking this skill does NOT authorize a push. Report the commit SHA, ask, then push only on yes.
The repo check must pass before the push.
Keep the MR scoped to one concern; split unrelated changes into separate MRs.

이 저장소의 다른 Skills

같은 저장소

add-feature

blurifycom/openora

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.

2026-07-2618

oss-review

blurifycom/openora

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.

2026-07-2618

review

blurifycom/openora

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>".

2026-07-2618

add-feature

blurifycom/openora

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.

2026-07-2618

create-plugin

blurifycom/openora

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>".

2026-07-2618

create-ui-module

blurifycom/openora

Create a frontend feature module in apps/backoffice or apps/web following ADR-0001's modular architecture: standard folder shape, co-located locales, DI hooks, pure components, barrel entry, route wiring. Use on "create module", "new feature module", "add a backoffice/web module", "/create-ui-module <app> <name>".

2026-07-2618

create-pr

Promotion chain

Source (current) branch

MR target

Notes

dev (default working)

stage

Promote accumulated work to the staging env

stage

prod

Promote staging -> production

any feat/* / fix/* / <KEY>-*

dev

Feature/ticket work merges into dev first

If the current branch isn't in the table, target dev.

Steps

Determine source + target. git branch --show-current -> look it up in the table above to get the target.

Scope the commit. git status -s. Commit ONLY changes that belong to this unit of work. If unrelated/pre-existing edits are present, do NOT bundle them - stage your files explicitly and tell the user what you left out. Never git add -A blindly when foreign changes are in the tree.

Commit. Conventional-commit message (feat:, fix:, docs:, refactor:, chore:); for ticket work prefix the ticket key (e.g. feat(<KEY>-123): ...).

Verify before pushing (cheap insurance): run the repo's check (e.g. pnpm check:types && pnpm check:lint). Don't push a red tree.

Push the current branch - but STOP and get an explicit per-action "yes push" from the user FIRST. Report the commit SHA, then ask. Invoking this skill is NOT push authorization. Pushing to a shared/env branch (dev, stage, prod) without that explicit yes is forbidden. Only after the yes: git push -u origin <current>.

Open the MR with glab (only after the push is confirmed + done):

glab mr create --source-branch <current> --target-branch <target> \
  --title "<type>: <summary>" --description "<body>" --yes --remove-source-branch=false

For a long-lived env branch (dev, stage, prod) NEVER pass --remove-source-branch. Reuse an existing open MR for the same source->target instead of creating a duplicate (glab mr list --source-branch <current> --target-branch <target>).

Report the MR URL back to the user.

Rules

NEVER push without an explicit per-action "yes push" from the user. Invoking this skill does NOT authorize a push. Report the commit SHA, ask, then push only on yes.

The repo check must pass before the push.

Keep the MR scoped to one concern; split unrelated changes into separate MRs.

name	create-pr
description	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>".