github-repository-management

GitHub repository collaboration management

Applicable scenarios

Query based on GitHub MCP TencentBlueKing/bk-ci or other repository information
Create, update, or supplement issues
Draft or create a PR based on the current local changes
View PR comments, reviews, and check runs, and reply to review feedback
Perform pre-merge checks to confirm whether merge conditions are met

Only modifying local code implementation, without involving GitHub collaboration actions
Only discussing commit messages, commit boundaries, or local Git history cleanup
Need to perform an in-depth correctness review; in this case, switch to the code review workflow
Directly performing GitHub write operations with side effects without user confirmation

This skill focuses on the closed loop of "local repository context + GitHub MCP collaboration actions," not an overview of GitHub features.
In the BK-CI repository, the default repository context is TencentBlueKing/bk-ci, and the default baseline branch is usually master; if the user specifies otherwise, the user's specification takes precedence.
Code facts come primarily from the current local repository; collaboration facts such as issues, PRs, comments, and check runs are obtained primarily through GitHub MCP.
All write operations follow "read before write":
- First confirm owner/repo
- First search for duplicate issues / existing PRs / related comments
- First show the user the proposed submission content
- Only actually create or update after obtaining confirmation
The main PR path must also complete local information: branch name, target branch, change summary, verification results, and linked issues.
When unsure whether it can be merged directly, prefer creating a draft PR rather than assuming it is already mergeable.
Specific tool selection, templates, and process details are placed in reference/workflows.md。

GitHub MCP is responsible for remote collaboration status, and the local repository is responsible for code and test facts; do not mix the two
Before creating an issue, you must first check for duplicates; before creating a PR, you must first look at the local diff, target branch, and existing PR status
Issue comments and PR review comments are two different types of actions; do not choose the wrong tool when replying
Before merging, at least confirm review status, check runs, conflict risk, and user authorization
Only fill in labels, assignee, milestone, and issue type when they are known to be available in the repository; do not fabricate them

Filing an issue / PR based only on local code, resulting in missing remote context
Treating an ordinary PR comment as a code review comment, or vice versa
Directly performing write operations without showing the user the final title and body
Merging by default when CI has not confirmed and review has not converged