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 bodytesting
--- 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