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 URLsdevelopment
Run local code quality checks covering a subset of OpenHarmony gate CI (copyright, CodeArts C/C++) plus additional local checks (pylint/flake8, shellcheck/bashate, gn format). Use before committing to reduce gate failures. Triggers on: /oh-precommit-codecheck, "门禁检查", "门禁预检", "检查代码", "run codecheck", "check code quality", "lint my code", "代码检查", or after completing code implementation. WHEN to use: before git commit, before creating PR, after modifying C/C++/Python/Shell/GN files, when gate CI fails with codecheck defects, or when you want to preview what gate will flag.
development
OpenHarmony PR full lifecycle workflow. Five modes: - Commit: standardized commit with DCO sign-off and Issue linking - Create PR: commit + push to fork + create Issue + create PR on upstream - Fix Codecheck: fetch gate CI codecheck defects from a PR and auto-fix them - Review PR: fetch a PR's changes to local for code review - Fix Review: fetch unresolved review comments from a PR and auto-fix them Triggers on: /oh-pr-workflow, "提交代码", "创建PR", "提个PR", "commit", "修复告警", "修复门禁", "修复codecheck", "fix codecheck", "review pr", "review这个pr", "看下这个pr", "检视pr", "修复review", "修复检视意见", "fix review", or a GitCode PR URL with fix/review intent.
testing
分析 HM Desktop PRD 文档,提取需求信息、验证完整性、检查章节顺序(需求来源→需求背景→需求价值分析→竞品分析→需求描述)、检查 KEP 定义、检测需求冲突并生成结构化分析报告。适用于用户请求:(1) 分析或审查 PRD 文档, (2) 从需求中提取 KEP 列表, (3) 检查 PRD 完整性或一致性, (4) 将需求映射到模块架构, (5) 验证 PRD 格式合规性, (6) 验证竞品分析章节完整性。关键词:PRD分析, requirement extraction, KEP验证, completeness check, chapter order validation, 竞品分析检查, analyze PRD, 需求提取, 完整性检查, 章节顺序验证
development
基于 PRD 文档自动生成鸿蒙系统设计文档,包括架构设计文档和功能设计文档。生成前会分析 OpenHarmony 存量代码结构,确保与现有架构兼容。架构设计文档第2章必须为竞品方案分析,位于需求背景之后。适用于用户请求:(1) 生成架构设计文档, (2) 生成功能设计文档, (3) 从 PRD 生成设计文档, (4) 创建系统架构设计, (5) 编写功能规格说明, (6) 分析 OH 代码结构。关键词:architecture design, functional design, design doc, 竞品方案分析, OpenHarmony code analysis, 架构设计, 功能设计, 设计文档生成, OH代码分析, analyze codebase, competitor analysis