gitcode-issue-workflow

End-to-end GitCode issue workflow covering issue pickup, analysis, code modification, and PR submission. Use when user asks to handle/fix/resolve a GitCode i...

Security Scan

The skill's instructions match an end-to-end GitCode issue workflow, but the package metadata omits expected requirements (gc/git binaries, GitCode token or config path), and the runtime guidance references a MEMORY.md token and local-file access — inconsistencies that warrant caution before installation.

Purpose & Capability

The skill's name and SKILL.md describe an appropriate GitCode issue->PR workflow. However, the registry metadata declares no required binaries, no primary credential, and no config paths, while the SKILL.md explicitly requires the gc CLI, git, and a GitCode access token. This mismatch (metadata under-reporting required capabilities) is incoherent and should be corrected.

Instruction Scope

The instructions are mostly scoped to the stated purpose: fetching issues, reading repo files, proposing diffs, editing files, committing, pushing to a fork, and creating PRs. It correctly requires user confirmation before applying edits/pushing. Two points to watch: (1) it suggests the token may be stored in MEMORY.md (a file access not declared in metadata), and (2) it instructs use of agent 'read' and 'edit' tools to access local files — legitimate for the task, but sensitive because they access user filesystem and could read other files if misused.

Install Mechanism

This is an instruction-only skill with no install spec and no bundled code, which is lower risk. The SKILL.md recommends installing gc from gitcode.com if missing — acceptable, but installation is left to the user.

Credentials

The SKILL.md requires a GitCode access token and may read/store it in MEMORY.md or ask the user, but the skill metadata does not declare any required env vars or config paths. The expectation that a secret token could live in MEMORY.md (not documented in metadata) and that the agent will access local repo paths is disproportionate to what the registry record claims and should be declared explicitly so users know what secrets/paths the skill will use.

Persistence & Privilege

always:false (normal). The skill allows autonomous invocation by default (platform default) and will use agent tools to read/edit local files and run git/gc commands. The SKILL.md mandates user confirmation before making changes or pushing, which mitigates risk, but autonomous reads of local repos and any use of stored tokens increase attack surface — especially given the metadata omissions.

What to consider before installing

This skill appears to do what it claims (handle GitCode issues and submit PRs), but the registry metadata omits key runtime requirements. Before installing or invoking it: (1) confirm you are comfortable giving the agent access to your local repository path and to a GitCode access token — prefer pasting a temporary token at runtime rather than storing it in MEMORY.md; (2) verify the gc CLI you use is the official one from gitcode.com; (3) ensure the agent asks explicit confirmation before editing files, committing, or pushing (and be careful which remote you choose when pushing); (4) consider asking the publisher to update the package metadata to declare required binaries (gc, git) and any config paths (MEMORY.md) so the permission record matches actual behavior. If you do not want an agent reading or modifying local files or handling tokens, do not enable this skill.

End-to-end workflow: Issue → Analysis → Code Fix → PR Submission.

Prerequisites

• gc CLI: GitCode CLI (similar to GitHub's gh)
• git: Standard git CLI
• GitCode Token: Stored in MEMORY.md or provided by user
• Local repo: User must confirm the local repository path

gc CLI detection (follow this order):

1. Try gc --version
2. If command not found (not in PATH), ask user for the full path to gc executable (e.g., C:\Users\<user>\AppData\Roaming\Python\Python313\Scripts\gc.exe)
3. Use the user-provided full path for all subsequent gc calls in the session
4. If user doesn't have gc installed, prompt to install from https://gitcode.com/gitcode-cli/cli

6-Step Workflow

Step 1: Fetch & Read Issue

Fetch the issue using gc CLI:

gc issue view <number> --repo <owner>/<repo>
gc issue view <number> --repo <owner>/<repo> --comments

Parse and present to user:

• Issue title, state, author, assignees, labels
• Problem description (each numbered point)
• Comments from maintainers (especially assignment decisions and clarifications)

Step 2: Confirm Local Repository

Must confirm with user before proceeding:

1. Ask user for the local repository path (or confirm if already known)
2. Verify the repo exists and is on the correct branch:

cd <repo_path>
git status
git log --oneline -3

3. Pull latest code from the target branch (usually master):

git pull <remote> <branch>

⚠️ Constraints:

• Never assume the local repo path — always confirm with user
• Verify working tree is clean before starting work
• Identify which remote is upstream (the target org repo) vs personal fork

Step 3: Read & Analyze Target Files

Read the files that need modification based on the issue description:

# Use read tool to examine the file contents
read <file_path>

Analysis requirements:

• Understand the current structure and content of files to be modified
• Cross-reference with issue requirements and maintainer comments
• Identify the minimal change set needed

Step 4: Propose Changes

⚠️ Must get user approval before modifying any files.

Present to the user:

1. Modification target: Which file(s) will be changed
2. Modification approach: What will be changed and why
3. Expected diff: Show the before/after comparison in diff format

- old content
+ new content

4. Rationale: How this addresses the issue requirements

Wait for user confirmation before proceeding to Step 5.

If user requests adjustments, revise the proposal and re-present.

Step 5: Apply Changes

After user approval, apply the changes:

# Edit the file using edit tool
edit <file_path> oldText -> newText

Verify the changes:

cd <repo_path>
git diff <file>

Show the diff output to user for final confirmation.

Step 6: Create Branch, Commit & Submit PR

This step involves multiple sub-steps. Follow them in strict order.

6.1 Create Branch

Branch naming format: [type]_[YYYYMMDD]_[brief_description]

• type: doc, fix, feat, refactor, test, chore, etc.
• date: Current date in YYYYMMDD format
• description: 1-2 English words separated by underscores

cd <repo_path>
git checkout -b <branch_name>

Examples:

• doc_20260424_contributing_guide
• fix_20260424_null_check
• feat_20260424_export_csv

6.2 Commit

Commit message format: [type]([module]): [detailed description]

git add <changed_files>
git commit -m "<type>(<module>): <description>"

Examples:

• docs(readme): elevate contributing guide to standalone section
• fix(parser): add null check for empty input
• feat(export): add CSV export support

6.3 Push to Personal Fork

⚠️ Critical constraints:

• Must ask user which remote to push to — never assume
• Never push directly to the upstream/organization repository
• List available remotes for user to choose:

git remote -v

Then push:

git push <personal_remote> <branch_name>

6.4 Create PR (Merge Request)

Method 1: gc CLI (preferred)

gc pr create -R <upstream_owner>/<repo> \
  --fork <personal_owner>/<repo> \
  --head <branch_name> \
  --base <target_branch> \
  --title "<commit_message>" \
  --body "<pr_description>"

⚠️ Must ask user for the target branch (e.g., master, main, develop) if not already known. Do not assume.

PR body template:

## PR描述 (What this PR does / why we need it?)

<!--
- 请明确说明您提交PR的变更内容。本部分旨在概述所做的变更，以及此PR是如何解决该问题的。请尽可能地提供有助于评审人员更高效、更快速完成检视审查的实用说明。
- 请说明为何需要这些更改，例如具体的使用场景或bug描述。
- 关联issue号(如果有)

- Please clarify what changes you are proposing. The purpose of this section is to outline the changes and how this PR fixes the issue.
If possible, please consider writing useful notes for better and faster reviews in your PR.
- Please clarify why the changes are needed. For instance, the use case and bug description.
- Fixes [#<issue-number>](https://gitcode.com/<upstream_owner>/<repo>/issues/<issue-number>)
-->

## 面向用户的变更 (Does this PR introduce _any_ user-facing change)?
<!--
请注意，这里指的是**任何**面向用户的变更，包括但不限于API、用户界面或其他使用方式上的变更。
Note that it means *any* user-facing change including all aspects such as API, interface or other behavior changes.
-->

## 功能验证 (How was this patch tested?)
<!--
请确认CI已通过增量及存量的单元测试用例。
如果本次测试方式与常规单元测试不同，请详细说明您的测试步骤(最好提供完整的可复现的操作路径及关键截图)，以便Committer能够快速复现验证，也便于后续的维护。
如果未添加测试，请说明未添加的原因，以及为何难添加测试。

- [_] 功能自验
- [_] 本地自验截图(涉及个人标识符等敏感信息请注意脱敏)
- [_] 新增/变更内容是否已新增/适配UT测试用例看护

CI passed with new added/existing test.
If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future.
If tests were not added, please describe why they were not added and/or why it was difficult to add.

- [_] Self-verification of the feature.
- [_] Screenshot of local self-verification (please anonymize any sensitive information such as personal identifiers)
- [_] Have new or modified unit test (UT) cases been added or adapted to cover the newly added or changed content?
-->

Method 2: GitCode API (fallback if gc CLI fails)

See references/gitcode-api.md for the API endpoint and parameters.

curl -s -X POST "https://api.gitcode.com/api/v5/repos/<owner>/<repo>/pulls?access_token=<token>" \
  -H "Content-Type: application/json" \
  -d @<payload_file>

Payload structure:

{
  "title": "<PR title>",
  "body": "<PR description>",
  "head": "<fork_owner>:<branch_name>",
  "base": "<target_branch>",
  "fork_path": "<fork_owner>/<repo>"
}

Method 3: Manual (last resort)

If both gc CLI and API fail, provide the user with the manual creation URL:

https://gitcode.com/<fork_owner>/<repo>/merge_requests/new?source_branch=<branch_name>

And the PR description text for them to paste.

6.5 Confirm & Report

After PR creation, present a summary:

Item	Value
PR URL	<link>
PR Number	#<number>
Source	<fork_owner>/<repo>:<branch>
Target	<upstream_owner>/<repo>:<base_branch>
Linked Issue	#<issue_number>
Status	Opened

Key Constraints

Safety Rules

1. Never push to upstream/organization repos directly — always use personal fork
2. Never modify files without user approval — always show proposed changes first
3. Never assume repository paths — always confirm with user
4. Never assume target branch — always ask if unknown
5. Never assume push remote — always list remotes and ask user to choose
6. All external write operations require explicit user confirmation

Git Workflow Rules

1. Working tree must be clean before creating a new branch
2. Branch must be created from the latest target branch code
3. Commit messages must follow the format: [type]([module]): [description]
4. Branch names must follow the format: [type]_[YYYYMMDD]_[brief_description]
5. Always verify changes with git diff before committing

Asking vs Doing

Action	Ask First?
Read files, check git status	❌ Just do it
Fetch issue details	❌ Just do it
Propose changes	❌ Present proposal
Modify files	✅ Wait for approval
Push to remote	✅ Ask which remote
Create PR	✅ Ask target branch if unknown
Post issue comments	✅ Always confirm

Temp File Management

All temporary files generated during the workflow must be stored in temp/ directory under the workspace:

workspace/temp/
├── *.md          # Downloaded files for review
├── *.json        # API payloads
└── *             # Other temp files

⚠️ Clean up temp/ directory after workflow completion:

Remove-Item -Recurse -Force temp/  # Windows
rm -rf temp/                        # Linux/macOS