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

push-code

스타3

포크0

업데이트2026년 6월 24일 21:42

Stage, commit, and push uncommitted code with a well-structured conventional commit message. Use when the user asks to push code, commit and push, save changes to remote, or sync local changes with GitHub.

설치

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

Manus에서 실행

출처

percy-g2

percy-g2/kmp_utxo

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

다운로드

Manus에서 실행

Push Code

Stage all changes, generate a conventional commit message, and push to the remote branch.

Prerequisites

Git repository initialized
Remote origin configured
GitHub CLI authenticated (gh auth status)

Workflow

1. Branch protection check (MANDATORY FIRST STEP)

CURRENT_BRANCH=$(git branch --show-current)

If $CURRENT_BRANCH is main, master, dev, develop, production, or matches release/*:

STOP — do not commit or push.
Analyze changes to determine an appropriate branch name.
Create feature branch: git checkout -b <type>/<short-description>.
Inform the user: "Protected branch detected. Created <branch> to keep <protected> safe."
REFUSE even if the user explicitly asks to push to the protected branch.

2. Check working tree

git status
git diff --stat

Verify there are uncommitted changes.
Check for merge conflicts and resolve before proceeding.
Ensure no secrets or sensitive files (.env, *.jks, credentials) are staged.

3. Code quality validation (if CI is not configured)

./gradlew ktlintCheck   # Lint
./gradlew test           # Unit tests
./gradlew build          # Full build

If any check fails, report the errors and stop.

4. Generate commit message

Use the conventional commit format:

<type>(<scope>): <subject>

<body>

<footer>

Types: feat, fix, refactor, docs, style, test, chore, perf

Subject: imperative mood, max 50 chars, no trailing period.

Body: explain WHAT changed and WHY. List modified files/modules. Document breaking changes.

Footer: Closes #<issue> if applicable.

Never add Co-Authored-By: trailers or "Generated with …" lines. The footer contains only Closes #<issue> when applicable.

Example:

feat(websocket): implement Binance WebSocket connection for crypto prices

- Added WebSocketManager class with retry logic and exponential backoff
- Created CryptoPriceModel data class for price updates
- Configured connection for BTC, ETH, and top 50 coins

Closes #12

5. Stage and commit

git add .
git commit -m "<generated-message>"

6. Verify branch again before push

CURRENT_BRANCH=$(git branch --show-current)

Double-check the branch is NOT protected. Then push:

git push origin "$CURRENT_BRANCH"

7. Post-push verification

Confirm push success.
Display commit hash, branch name, and GitHub URL.
Suggest creating a PR if one doesn't exist yet.

Safety rules

Never push to main, master, dev, develop, production, or release/* — even if the user asks.
Never commit secrets or sensitive files.
Never force push unless the user explicitly requests it and confirms the risk.

이 저장소의 다른 Skills

같은 저장소

product-video

percy-g2/kmp_utxo

Turn app screenshots into a cinematic product video — a self-contained animated HTML showcase and an exported MP4. Use when the user has app screenshots (or the raw captures from deploy-ss) and wants a "product video", "promo video", "sizzle reel", "app trailer", "launch video", or a shareable motion showcase / App Store preview. Companion to deploy-ss (which makes the static store screenshots).

2026-07-093

deploy-ss

percy-g2/kmp_utxo

Generate App Store and Play Store deployment assets — iPhone screenshots, iPad screenshots, and a Play Store feature graphic — from raw app UI screenshots. Use this skill whenever the user has app screenshots and wants to publish to the App Store or Google Play, mentions "store screenshots", "marketing screenshots", "feature graphic", "app store assets", "App Store Connect", "Play Console", "Google Play listing", or asks how to prepare their app's listing for submission. Trigger this even when the user just uploads phone screenshots and says something vague like "make these look good for the store" or "I'm submitting my app, help me with the visuals" — those are still this skill.

Create a GitHub Pull Request to merge the current branch into main with a well-structured title and description using GitHub CLI. Use when the user asks to create a PR, open a pull request, submit a merge request, or send changes for review.

2026-04-153

merge-pr

percy-g2/kmp_utxo

Merge an approved GitHub Pull Request after validating CI checks, review status, and mergeability. Use when the user asks to merge a PR, complete a pull request, or land a branch.

2026-04-153

pcr

percy-g2/kmp_utxo

Run the full push, create PR, review pipeline in sequence: stage/commit/push (push-code), create a PR into main (create-pr), then approve or request changes on that PR (review-pr). Use when the user says pcr, push commit review, push and create pr and review, or wants one workflow from local changes to an opened and reviewed pull request.

2026-04-153

name	push-code
description	Stage, commit, and push uncommitted code with a well-structured conventional commit message. Use when the user asks to push code, commit and push, save changes to remote, or sync local changes with GitHub.

Push Code

Stage all changes, generate a conventional commit message, and push to the remote branch.

Prerequisites

Git repository initialized
Remote origin configured
GitHub CLI authenticated (gh auth status)

Workflow

1. Branch protection check (MANDATORY FIRST STEP)

CURRENT_BRANCH=$(git branch --show-current)

If $CURRENT_BRANCH is main, master, dev, develop, production, or matches release/*:

STOP — do not commit or push.
Analyze changes to determine an appropriate branch name.
Create feature branch: git checkout -b <type>/<short-description>.
Inform the user: "Protected branch detected. Created <branch> to keep <protected> safe."
REFUSE even if the user explicitly asks to push to the protected branch.

2. Check working tree

git status
git diff --stat

Verify there are uncommitted changes.
Check for merge conflicts and resolve before proceeding.
Ensure no secrets or sensitive files (.env, *.jks, credentials) are staged.

3. Code quality validation (if CI is not configured)

./gradlew ktlintCheck   # Lint
./gradlew test           # Unit tests
./gradlew build          # Full build

If any check fails, report the errors and stop.

4. Generate commit message

Use the conventional commit format:

<type>(<scope>): <subject>

<body>

<footer>

Types: feat, fix, refactor, docs, style, test, chore, perf

Subject: imperative mood, max 50 chars, no trailing period.

Body: explain WHAT changed and WHY. List modified files/modules. Document breaking changes.

Footer: Closes #<issue> if applicable.

Never add Co-Authored-By: trailers or "Generated with …" lines. The footer contains only Closes #<issue> when applicable.

Example:

feat(websocket): implement Binance WebSocket connection for crypto prices

- Added WebSocketManager class with retry logic and exponential backoff
- Created CryptoPriceModel data class for price updates
- Configured connection for BTC, ETH, and top 50 coins

Closes #12

5. Stage and commit

git add .
git commit -m "<generated-message>"

6. Verify branch again before push

CURRENT_BRANCH=$(git branch --show-current)

Double-check the branch is NOT protected. Then push:

git push origin "$CURRENT_BRANCH"

7. Post-push verification

Confirm push success.
Display commit hash, branch name, and GitHub URL.
Suggest creating a PR if one doesn't exist yet.

Safety rules

Never push to main, master, dev, develop, production, or release/* — even if the user asks.
Never commit secrets or sensitive files.
Never force push unless the user explicitly requests it and confirms the risk.