skills/gitcode-pr/SKILL.md
Handle GitCode PR workflow for OpenHarmony - commit changes, push to fork remote, create issue, create PR from fork to upstream using repo's .gitee/PULL_REQUEST_TEMPLATE.zh-CN.md with issue linking via
npx skillsauth add openharmonyinsight/openharmony-skills gitcode-prInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Handles complete GitCode PR submission for OpenHarmony repositories with intelligent remote detection and issue-PR linking. Use the gitcode mcp. If gitcode mcp is not present, warn the user and terminate the skill immediately.
Never assume remote names. Use this algorithm to identify upstream and fork:
# Step 1: List all remotes
git remote -v
# Step 2: Parse each remote
for remote in $(git remote); do
url=$(git remote get-url $remote)
# Parse owner from URL
# Format: https://gitcode.com/<owner>/<repo> or https://gitcode.com/<owner>/<repo>.git
if [[ "$url" =~ https://gitcode\.com/([^/]+)/(.+) ]]; then
owner="${BASH_REMATCH[1]}"
repo=$(echo "${BASH_REMATCH[2]}" | sed 's/\.git$//')
# Determine type
if [ "$owner" = "openharmony" ]; then
echo "$remote: UPSTREAM ($owner/$repo)"
else
echo "$remote: FORK ($owner/$repo)"
fi
fi
done
| Owner | Type | Usage |
|-------|-------|--------|
| openharmony | UPSTREAM | Source for PR template, target for PR base, issue creation |
| Other usernames | FORK | Push target, PR head source |
| Upstream Remotes | Fork Remotes | Action | |-----------------|-------------|--------| | Found | Found | Use both: create issue/PR on upstream, push to fork | | Found | None | Ask user: "Found upstream but no fork. Need to fork first?" | | None | Found | Use fork as both push target and PR target (uncommon) | | None | Multiple (no openharmony) | Ask user to select: "Which remote to use?" | | None | Single (no openharmony) | Use as fork, warn: "No upstream (openharmony) remote found" |
When remote is ambiguous, prompt user:
I found these GitCode remotes:
- **remote_name**: owner/repo (UPSTREAM/FORK)
Which remote should I use for:
- Pushing changes?
- Creating the PR?
Please specify the remote name, or press Enter to use [default].
Follow this workflow when user requests PR submission:
Check git status and branch:
git status
git branch --show-current
git remote -v
Determine:
Use gitcode_list_pull_requests to check for existing PRs:
# Get upstream owner/repo (parse from upstream remote URL)
UPSTREAM_REMOTE=$(detect_upstream_remote)
UPSTREAM_URL=$(git remote get-url $UPSTREAM_REMOTE)
# Parse: openharmony/security_code_signature from URL
# List PRs for upstream repo
gitcode_list_pull_requests --owner $UPSTREAM_OWNER --repo $UPSTREAM_REPO
# Search for PR with matching branch name and owner name
If PR exists: Only push to fork and inform user.
git push -u $FORK_REMOTE <branch-name>
If PR does not exist: Continue to steps 4-6 to create issue and PR.
Load issue template and create issue:
references/issue_template.mdgitcode_create_issue with upstream owner/repoNote: Use commit message and git diff to generate issue description automatically.
Push to your fork (the detected fork remote):
git push -u $FORK_REMOTE <branch-name>
Load PR template from upstream repository and create PR linking to issue:
Get upstream PR template:
# Try local copy first
if [ -f .gitee/PULL_REQUEST_TEMPLATE.zh-CN.md ]; then
cat .gitee/PULL_REQUEST_TEMPLATE.zh-CN.md
else
# Fetch from upstream
git fetch $UPSTREAM_REMOTE master
git show $UPSTREAM_REMOTE/master:.gitee/PULL_REQUEST_TEMPLATE.zh-CN.md
fi
Fill template: Follow the direction in the template.
Create PR using gitcode_create_pull_request:
IMPORTANT: For cross-repo PRs, the head parameter format is CRITICAL.
<fork-owner>:<branch-name> (no extra prefixes)Parameters:
owner: Upstream owner (e.g., openharmony)repo: Upstream repo (e.g., security_code_signature)title: Follow commit message formathead: <fork-owner>:<branch-name> (from fork remote parsing)base: Target branch on upstream (typically master or main)body: Template content with issue referenceExample:
# After detection
UPSTREAM_OWNER="openharmony"
UPSTREAM_REPO="security_code_signature"
FORK_OWNER="someone"
FORK_REMOTE="fork"
gitcode_create_pull_request \
--owner $UPSTREAM_OWNER \
--repo $UPSTREAM_REPO \
--title "fix(code_signature): add null check for buffer pointer" \
--head "$FORK_OWNER:$BRANCH_NAME" \
--base "master" \
--body "$(cat .gitee/PULL_REQUEST_TEMPLATE.zh-CN.md | \
sed 's/^### 关联的issue:$/### 关联的issue:\n#$ISSUE_NUMBER/')"
Located at .gitee/PULL_REQUEST_TEMPLATE.zh-CN.md in the upstream repository.
See references/issue_template.md for standard issue format.
Key sections:
Parse owner and repo from remote URLs:
# Function to parse GitCode URL
parse_gitcode_url() {
local url="$1"
# Remove .git suffix if present
url=$(echo "$url" | sed 's/\.git$//')
# Extract owner and repo
if [[ "$url" =~ https://gitcode\.com/([^/]+)/(.+) ]]; then
echo "${BASH_REMATCH[1]}|${BASH_REMATCH[2]}"
fi
}
# Usage
result=$(parse_gitcode_url "https://gitcode.com/openharmony/security_code_signature")
owner="${result%%|*}"
repo="${result##*|}"
# owner=openharmony, repo=security_code_signature
In .gitee/PULL_REQUEST_TEMPLATE.zh-CN.md, fill in issue reference:
### 关联的issue:
#123
The PR will auto-close issue #123 when merged.
Use these tools for GitCode operations:
gitcode_list_pull_requests - Check existing PRs (use upstream owner/repo)gitcode_get_pull_request - Get PR detailsgitcode_create_pull_request - Create new PR (head points to fork)gitcode_update_pull_request - Update existing PRgitcode_create_issue - Create new issue (use upstream owner/repo)gitcode_get_issue - Get issue details.gitee/PULL_REQUEST_TEMPLATE.zh-CN.md exists upstreamUser requests PR
↓
Check git status
↓
Changes uncommitted? → Yes → Commit changes
↓ No
List and parse remotes
↓
Detect upstream (owner=openharmony) and fork
↓
┌─────────────────────────────────────┐
│ Remote detection result: │
│ - Upstream found? │
│ - Fork found? │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Need user input? │
│ - No fork? │
│ - Ambiguous remotes? │
└─────────────────────────────────────┘
↓ Yes → Ask user
↓ No
Push to fork
↓
List PRs (upstream repo)
↓
PR exists for branch? → Yes → Inform user (PR already exists)
↓ No
Create issue (upstream repo)
↓
Get PR template from upstream (.gitee/PULL_REQUEST_TEMPLATE.zh-CN.md)
↓
Create PR (head: fork-owner:branch, base: upstream-branch)
↓
Done
When creating issue or PR, gather from:
git log -1 - Last commit messagegit diff HEAD~1 - Changed files and diffgit remote -v - All remotes and their URLstesting
--- name: ohos-req-value-decision description: Use after review meeting to record decision and route to next step. Triggers: 评审决策纪要, 评审结论回流, value decision, 评审接纳, 评审不接纳, 评审退回, 下次重新上会. Do NOT use for feature baseline (ohos-req-feature-baseline), review gate checks (ohos-req-review-gate), or IR generation (ohos-req-feature-to-ir). metadata: author: openharmony scope: common stage: requirements capability: value-decision version: 0.3.0 status: draft tags: - sdd - requirements
development
Use when converting an OpenHarmony requirement document, spec, or design proposal into an OpenHarmony review slide deck (需求评审 / 需求变更评审 / 设计评审 PPTX) — produces the fixed OpenHarmony-branded review-deck structure (OH logo on every page) with architecture/flow diagrams and field tables. Triggers on "需求评审PPT", "需求变更评审", "把需求文档转成评审PPT", "spec转评审PPT", "requirement/spec to review deck". NOT for arbitrary or generic slide decks unrelated to OpenHarmony requirement/design review.
testing
Use when performing the Phase 0 Step 0.5 Review Ready Gate on a 04-feature.md, especially when the user says "evaluate gate", "review readiness", "feature ready?", "should we generate IR", or when the ohos-req-intake-orchestration main session needs a structured Ready / Conditional Ready / Not Ready judgment instead of doing the check inline. Reads 01-04, runs seven fixed checks plus a conditional-items check, and returns a machine-readable JSON summary plus a human-readable table that the main session can route on. Do NOT use for feature baseline generation (ohos-req-feature-baseline), value decision recording (ohos-req-value-decision), or IR generation (ohos-req-feature-to-ir).
testing
--- name: ohos-req-requirement-intake description: Use when importing an OHOS requirement into Phase 0.1, especially for 01-requirement.md, requirement intake, background, user value, scenarios, scope, FR/NFR, affected modules, or priority. Triggers: 需求导入, 01-requirement, 需求基线, RR单号. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline). metadata: author: openharmony scope: common