CtrlK
BlogDocsLog inGet started
Tessl Logo

github-repository-management

通过 GitHub MCP 管理仓库协作时使用,例如检索仓库、提 Issue、起草或创建 PR、查看评论、回复评审和做合并前检查。当用户要操作 GitHub 仓库协作流程而不是修改本地代码实现时优先使用。

64

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

63%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-organized, concise orchestration overview with a genuine read-before-write workflow and explicit user-confirmation checkpoints. Its main weaknesses are the missing reference/workflows.md file — which leaves the promised templates, tool choices, and process details undeliverable — and the absence of any inline concrete examples to fall back on. Deduping the read-before-write rule across three sections would also tighten it.

Suggestions

Create the referenced reference/workflows.md (or fix the path to an existing references/ directory) with the tool-selection guidance, Issue/PR templates, and workflow details the body promises — right now the only detailed reference is a dead link.

Add minimal inline concrete guidance (e.g., the specific GitHub MCP tool names for creating issues vs. PR review comments, and a skeleton Issue/PR template) so the skill remains actionable even without the external file.

Consolidate the read-before-write rule, which is currently stated three times across 快速指导, 高信号规则, and 关键陷阱, into a single authoritative statement.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — no padding explaining what GitHub, PRs, or Issues are. However, the read-before-write rule appears in three places ("先搜索重复 Issue / 现有 PR", "创建 Issue 前必须先查重", and the trap "只看本地代码就直接提 Issue / PR"), so minor tightening is possible. Fits 'Efficient; minor instances of over-explanation that could be trimmed'.

4 / 5

Actionability

Guidance is directionally concrete ("先确认 owner/repo", "优先创建 draft PR", "确认 review 状态、check runs、冲突风险") but contains no executable specifics — no tool names, commands, or templates — and defers all of them to "具体工具选择、模板和流程细节放在 reference/workflows.md", a file that does not exist in the bundle. This matches 'Some concrete guidance but incomplete; missing key details' rather than the mostly-executable level 4.

3 / 5

Workflow Clarity

The 快速指导 section gives a clear read-before-write sequence with checkpoints: 确认 owner/repo → 查重 → 向用户展示拟提交内容 → 获得确认后再写, and the merge gate (review 状态、check runs、冲突风险、用户授权) is explicit. It falls short of level 5 because there are no error-recovery loops (e.g., what to do when a duplicate Issue is found or checks fail).

4 / 5

Progressive Disclosure

The body itself is short and well-sectioned, and it clearly signals one-level-deep references ("具体工具选择、模板和流程细节放在 reference/workflows.md" and the 延伸阅读 section). However, no bundle directory exists — the referenced reference/workflows.md is missing, so navigation breaks exactly where the detail is promised. Structure is good but the dangling reference caps it at 'Some structure... references present but' effectively nonfunctional.

3 / 5

Total

14

/

20

Passed

Description

88%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete, comprehensive action list with an explicit 'use when' clause that also disambiguates against local code editing. Trigger terms are natural in both Chinese and GitHub jargon. Only slight room to improve by adding common synonyms such as the full 'pull request' phrasing.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — "检索仓库、提 Issue、起草或创建 PR、查看评论、回复评审和做合并前检查" (search repos, file issues, draft/create PRs, view comments, reply to reviews, pre-merge checks) — comprehensively covering the GitHub collaboration domain. This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage' and is not merely a domain name with generic verbs (level 3-4).

5 / 5

Completeness

Both questions are explicitly answered: what it does (the enumerated actions) and when to use it — "当用户要操作 GitHub 仓库协作流程而不是修改本地代码实现时优先使用" plus the opening "通过 GitHub MCP 管理仓库协作时使用". This matches the anchor for a clear, explicit what AND when; it exceeds level 4 where the 'when' is only loosely specified.

5 / 5

Trigger Term Quality

Natural terms users would actually say are present: "提 Issue", "创建 PR", "回复评审", "合并", "GitHub MCP". A few common variations are missing (e.g., the spelled-out 'pull request', 'code review', 'CI/check'), so it lands on 'Good keyword coverage; a few natural terms missing' rather than the fully comprehensive level 5.

4 / 5

Distinctiveness Conflict Risk

It carves a clear niche — remote GitHub collaboration via MCP — and explicitly contrasts it with local code changes ("而不是修改本地代码实现"), giving minimal overlap with local-editing skills. Minor overlap risk remains with closely related git/GitHub skills (e.g., commit-message or PR-review skills), so it fits 'Mostly distinct; minor overlap risk' rather than the level-5 clear-niche anchor.

4 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
TencentBlueKing/bk-ci
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.