skills/graphic-2d-PR/SKILL.md
The complete workflow for creating a pull request in the OpenHarmony graphic_graphic_2d repository, including creating an issue, linking them, and pushing to the fork.
npx skillsauth add openharmonyinsight/openharmony-skills graphic-2d-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.
git remote -v to check):
# Reset any staged changes and stage everything together
git reset HEAD .
git add .
git status
# Create a new branch from current branch
git checkout -b feature/descriptive-branch-name
# Commit with signoff (required)
git commit -s -m "type: brief description
Detailed explanation of the change.
Co-Authored-By: Claude Sonnet 4.5 <[email protected]>"
Note: Always use -s flag for signed commits (DCO compliance).
# Push branch to fork (remote 'z')
git push -u z feature/descriptive-branch-name
Use gitcode MCP tool to create an issue in the upstream repository:
mcp__gitcode__create_issue
- owner: openharmony
- repo: graphic_graphic_2d
- title: Brief issue title
- body: Detailed issue description with:
- Summary
- Problem
- Solution
- Impact
- Files Modified
Example issue body:
## Summary
Brief description of the issue/change.
## Problem
What problem does this solve?
## Solution
How is it solved?
## Impact
- What changes are made?
- Performance impact
- Test results
## Files Modified
- file1.h
- file2.cpp
Use gitcode MCP tool to create PR in upstream repository:
mcp__gitcode__create_pull_request
- owner: openharmony
- repo: graphic_graphic_2d
- base: master (NOT main - use master)
- head: zhoutianer:feature/descriptive-branch-name
- title: PR title (matches issue title)
- body: Detailed PR description
Critical: Use master as the base branch, not main.
Example PR body:
## Summary
Brief description.
## Problem
What problem does this solve?
## Solution
Technical details of the implementation.
## Impact
- Code quality improvements
- Performance impact
- Test results
## Test plan
- [x] Build passes
- [x] All tests pass
- [x] No new warnings
## Files Modified
- file1.h
- file2.cpp
Closes #<issue-number>
The Closes #<issue-number> at the end automatically links the PR to the issue.
Add a comment to the issue referencing the PR:
mcp__gitcode__create_issue_comment
- owner: openharmony
- repo: graphic_graphic_2d
- issue_number: <issue-number>
- body: Link to PR and summary
Example comment:
This issue is addressed by PR #<pr-number>: https://gitcode.com/openharmony/graphic_graphic_2d/merge_requests/<pr-number>
The PR implements:
- Key change 1
- Key change 2
Build passes in X:YY time with all tests passing.
master, not maingit commit -s for DCO compliancerefactor/feature-name, fix/bug-descriptionCloses #<issue-number> in PR bodygitcode - upstream (openharmony/graphic_graphic_2d)z - fork (zhoutianer/graphic_graphic_2d)# After making code changes
git reset HEAD .
git add .
git checkout -b refactor/color-picker-common-impl
git commit -s -m "refactor: Extract common implementation
- Add HandleColorUpdate to base interface
- Extract CreateColorPickerInfo helper
- Remove ~200 lines of duplication
Co-Authored-By: Claude Sonnet 4.5 <[email protected]>"
git push -u z refactor/color-picker-common-impl
Then use MCP tools to create issue #22224, PR #28311, and link them.
PR creation fails with API error (400):
master, not mainIssue not linking to PR:
Closes #<issue-number> is in PR bodydevelopment
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