feat(skills): add GitLink maintainer copilot
This commit is contained in:
parent
fde322669a
commit
204e70ebe7
11
README.md
11
README.md
|
|
@ -5,7 +5,7 @@
|
|||
[](https://golang.org)
|
||||
[](https://www.npmjs.com/package/@gitlink-ai/cli)
|
||||
|
||||
The official [GitLink](https://www.gitlink.org.cn) CLI tool — built for humans and AI Agents. Supports **macOS, Linux, and Windows**. Covers repository management, issue tracking, pull requests, CI/CD, and AI-powered workflows, with 40+ commands and 12 AI Agent [Skills](./skills/).
|
||||
The official [GitLink](https://www.gitlink.org.cn) CLI tool — built for humans and AI Agents. Supports **macOS, Linux, and Windows**. Covers repository management, issue tracking, pull requests, CI/CD, and AI-powered workflows, with 40+ commands and 13 AI Agent [Skills](./skills/).
|
||||
|
||||
**[中文文档](./README.zh-CN.md)**
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ The official [GitLink](https://www.gitlink.org.cn) CLI tool — built for humans
|
|||
|
||||
## Why gitlink-cli?
|
||||
|
||||
- **Agent-Native Design** — 12 structured [Skills](./skills/) out of the box, compatible with Claude Code, OpenClaw, and other AI platforms — Agents can operate GitLink with zero extra setup
|
||||
- **Agent-Native Design** — 13 structured [Skills](./skills/) out of the box, compatible with Claude Code, OpenClaw, and other AI platforms — Agents can operate GitLink with zero extra setup
|
||||
- **Wide Coverage** — Repository, Issue, PR, Branch, Release, CI, Org, Search, User — all core domains covered
|
||||
- **AI-Friendly & Optimized** — Every command is tested with real Agents, featuring concise parameters, smart defaults, and structured output
|
||||
- **Cross-Platform** — Runs on macOS, Linux, and Windows (x64/arm64), install via `npm install -g @gitlink-ai/cli` in one command, binary auto-downloaded
|
||||
|
|
@ -55,7 +55,7 @@ The official [GitLink](https://www.gitlink.org.cn) CLI tool — built for humans
|
|||
**From npm (recommended):**
|
||||
|
||||
```bash
|
||||
# One command: installs CLI binary + all 12 AI Agent Skills
|
||||
# One command: installs CLI binary + all 13 AI Agent Skills
|
||||
npm install -g @gitlink-ai/cli
|
||||
```
|
||||
|
||||
|
|
@ -293,7 +293,7 @@ git push gitlink
|
|||
|
||||
## AI Agent Skills
|
||||
|
||||
The `skills/` directory contains 12 Agent Skill files for AI-automated GitLink operations.
|
||||
The `skills/` directory contains 13 Agent Skill files for AI-automated GitLink operations.
|
||||
|
||||
See [skills/README.md](skills/README.md) for details.
|
||||
|
||||
|
|
@ -311,6 +311,7 @@ See [skills/README.md](skills/README.md) for details.
|
|||
| `gitlink-user` | User management (profile info, etc.) |
|
||||
| `gitlink-pm` | Project management (sprints, kanban, weekly reports, etc.) |
|
||||
| `gitlink-workflow` | AI-powered workflows (issue triage, PR review, release notes, etc.) |
|
||||
| `gitlink-maintainer-copilot` | Maintainer dashboard, evidence pack, governance playbooks, and confirmed governance Issue creation |
|
||||
|
||||
## Project Structure
|
||||
|
||||
|
|
@ -423,7 +424,7 @@ gitlink-cli uses Windows Credential Manager for secure token storage. If Credent
|
|||
|
||||
### Q: Where can I find the full API reference?
|
||||
|
||||
See [skills/gitlink-shared/REFERENCE.md](skills/gitlink-shared/REFERENCE.md).
|
||||
See [skills/gitlink-shared/references/api-reference.md](skills/gitlink-shared/references/api-reference.md).
|
||||
|
||||
## License
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
[](https://golang.org)
|
||||
[](https://www.npmjs.com/package/@gitlink-ai/cli)
|
||||
|
||||
[GitLink（确实开源）](https://www.gitlink.org.cn) 官方 CLI 工具 — 为人类和 AI Agent 双重设计。支持 **macOS、Linux、Windows**，覆盖仓库管理、Issue 追踪、Pull Request、CI/CD 和 AI 自动化工作流，包含 40+ 命令和 11 个 AI Agent [Skills](./skills/)。
|
||||
[GitLink（确实开源）](https://www.gitlink.org.cn) 官方 CLI 工具 — 为人类和 AI Agent 双重设计。支持 **macOS、Linux、Windows**，覆盖仓库管理、Issue 追踪、Pull Request、CI/CD 和 AI 自动化工作流，包含 40+ 命令和 13 个 AI Agent [Skills](./skills/)。
|
||||
|
||||
**[English](./README.md)**
|
||||
|
||||
|
|
@ -13,7 +13,7 @@
|
|||
|
||||
## 为什么选择 gitlink-cli？
|
||||
|
||||
- **Agent-Native 设计** — 开箱即用 11 个结构化 [Skills](./skills/)，兼容 Claude Code — Agent 零配置即可操作 GitLink
|
||||
- **Agent-Native 设计** — 开箱即用 13 个结构化 [Skills](./skills/)，兼容 Claude Code — Agent 零配置即可操作 GitLink
|
||||
- **广泛覆盖** — 仓库、Issue、PR、分支、Release、CI、组织、搜索、用户 — 核心功能全覆盖
|
||||
- **AI 友好 & 优化** — 每条命令都经过真实 Agent 测试，简洁参数、智能默认值、结构化输出
|
||||
- **跨平台** — macOS、Linux、Windows (x64/arm64) 全支持，`npm` 一条命令安装
|
||||
|
|
@ -273,7 +273,7 @@ git push gitlink
|
|||
|
||||
## AI Agent Skills
|
||||
|
||||
`skills/` 目录包含 11 个 Claude Code Agent Skill 文件，支持 AI 自动化操作 GitLink 平台。
|
||||
`skills/` 目录包含 13 个 Claude Code Agent Skill 文件，支持 AI 自动化操作 GitLink 平台。
|
||||
|
||||
详见 [skills/README.md](skills/README.md)
|
||||
|
||||
|
|
@ -290,6 +290,7 @@ git push gitlink
|
|||
| `gitlink-user` | 用户管理（个人信息等） |
|
||||
| `gitlink-pm` | 项目管理（Sprint、看板、周报等） |
|
||||
| `gitlink-workflow` | AI 自动化工作流（Issue 分类、PR Review、Release Notes 等） |
|
||||
| `gitlink-maintainer-copilot` | 维护者驾驶舱、证据包、治理剧本和确认后创建治理 Issue |
|
||||
|
||||
## 项目结构
|
||||
|
||||
|
|
@ -402,7 +403,7 @@ gitlink-cli 使用 Windows Credential Manager 安全存储 Token。如果 Creden
|
|||
|
||||
### Q: 如何查看完整的 API 参考？
|
||||
|
||||
查看 [skills/gitlink-shared/REFERENCE.md](skills/gitlink-shared/REFERENCE.md)
|
||||
查看 [skills/gitlink-shared/references/api-reference.md](skills/gitlink-shared/references/api-reference.md)
|
||||
|
||||
## 许可证
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
},
|
||||
"scripts": {
|
||||
"postinstall": "node scripts/install.js",
|
||||
"test": "node test/install.test.js && node test/cli.test.js"
|
||||
"test": "node test/install.test.js && node test/cli.test.js && node test/skills.test.js"
|
||||
},
|
||||
"keywords": [
|
||||
"gitlink",
|
||||
|
|
|
|||
|
|
@ -0,0 +1,106 @@
|
|||
"use strict";
|
||||
|
||||
const assert = require("assert");
|
||||
const fs = require("fs");
|
||||
const path = require("path");
|
||||
|
||||
const skillsDir = path.resolve(__dirname, "..", "..", "skills");
|
||||
|
||||
const requiredSkillFiles = {
|
||||
"gitlink-maintainer-copilot": [
|
||||
"SKILL.md",
|
||||
"references/evidence-pack.md",
|
||||
"references/playbooks.md",
|
||||
"references/governance-issue-template.md",
|
||||
"examples/maintainer-copilot-workflow.md",
|
||||
"examples/sample-dashboard-report.md",
|
||||
],
|
||||
};
|
||||
|
||||
function readText(file) {
|
||||
return fs.readFileSync(file, "utf8");
|
||||
}
|
||||
|
||||
function parseFrontmatter(markdown, file) {
|
||||
const match = markdown.match(/^---\n([\s\S]*?)\n---\n/);
|
||||
assert.ok(match, `${file} must start with YAML frontmatter`);
|
||||
|
||||
const fields = {};
|
||||
for (const line of match[1].split("\n")) {
|
||||
const fieldMatch = line.match(/^([A-Za-z0-9_-]+):\s*(.*)$/);
|
||||
if (fieldMatch) {
|
||||
fields[fieldMatch[1]] = fieldMatch[2].replace(/^["']|["']$/g, "");
|
||||
}
|
||||
}
|
||||
return fields;
|
||||
}
|
||||
|
||||
function markdownFiles(root) {
|
||||
const files = [];
|
||||
for (const entry of fs.readdirSync(root, { withFileTypes: true })) {
|
||||
const fullPath = path.join(root, entry.name);
|
||||
if (entry.isDirectory()) {
|
||||
files.push(...markdownFiles(fullPath));
|
||||
} else if (entry.isFile() && entry.name.endsWith(".md")) {
|
||||
files.push(fullPath);
|
||||
}
|
||||
}
|
||||
return files;
|
||||
}
|
||||
|
||||
function localMarkdownLinks(markdown) {
|
||||
const links = [];
|
||||
const linkPattern = /\[[^\]]+\]\(([^)]+)\)/g;
|
||||
let match;
|
||||
while ((match = linkPattern.exec(markdown)) !== null) {
|
||||
const target = match[1].trim();
|
||||
if (
|
||||
target.startsWith("http://") ||
|
||||
target.startsWith("https://") ||
|
||||
target.startsWith("#") ||
|
||||
target.startsWith("mailto:")
|
||||
) {
|
||||
continue;
|
||||
}
|
||||
links.push(target.split("#")[0]);
|
||||
}
|
||||
return links.filter(Boolean);
|
||||
}
|
||||
|
||||
for (const [skillName, files] of Object.entries(requiredSkillFiles)) {
|
||||
for (const file of files) {
|
||||
assert.ok(
|
||||
fs.existsSync(path.join(skillsDir, skillName, file)),
|
||||
`${skillName} must include ${file}`
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
const skillDirs = fs
|
||||
.readdirSync(skillsDir, { withFileTypes: true })
|
||||
.filter((entry) => entry.isDirectory() && entry.name.startsWith("gitlink-"))
|
||||
.map((entry) => entry.name)
|
||||
.sort();
|
||||
|
||||
const names = new Set();
|
||||
|
||||
for (const dirName of skillDirs) {
|
||||
const skillFile = path.join(skillsDir, dirName, "SKILL.md");
|
||||
assert.ok(fs.existsSync(skillFile), `${dirName} must include SKILL.md`);
|
||||
|
||||
const frontmatter = parseFrontmatter(readText(skillFile), skillFile);
|
||||
assert.equal(frontmatter.name, dirName, `${dirName} frontmatter name must match directory`);
|
||||
assert.ok(frontmatter.description, `${dirName} must include description`);
|
||||
assert.ok(!names.has(frontmatter.name), `${frontmatter.name} must be unique`);
|
||||
names.add(frontmatter.name);
|
||||
}
|
||||
|
||||
for (const file of markdownFiles(skillsDir)) {
|
||||
const markdown = readText(file);
|
||||
for (const link of localMarkdownLinks(markdown)) {
|
||||
const targetPath = path.resolve(path.dirname(file), link);
|
||||
assert.ok(fs.existsSync(targetPath), `${file} links to missing file: ${link}`);
|
||||
}
|
||||
}
|
||||
|
||||
console.log("skills structure tests passed");
|
||||
|
|
@ -32,7 +32,7 @@ gitlink-cli auth status
|
|||
gitlink-cli user +me
|
||||
```
|
||||
|
||||
详见: [gitlink-shared/examples/auth-workflow.md](gitlink-shared/examples/auth-workflow.md)
|
||||
详见: [gitlink-shared/SKILL.md](gitlink-shared/SKILL.md)
|
||||
|
||||
### 2. 查看可用命令
|
||||
|
||||
|
|
@ -64,52 +64,41 @@ skills/
|
|||
├── README.md # 本文件
|
||||
├── gitlink-shared/ # 共享基础规则
|
||||
│ ├── SKILL.md # 认证、全局参数、安全规则、分支约定
|
||||
│ ├── REFERENCE.md # API 详细参考、错误处理
|
||||
│ ├── TROUBLESHOOTING.md # 常见问题排查
|
||||
│ └── examples/
|
||||
│ └── auth-workflow.md # 认证工作流示例
|
||||
│ └── references/ # API 参考、错误处理
|
||||
├── gitlink-repo/ # 仓库管理
|
||||
│ ├── SKILL.md # 仓库操作指南
|
||||
│ ├── REFERENCE.md # 仓库 API 参考
|
||||
│ └── examples/
|
||||
│ └── repo-workflow.md # 仓库管理工作流
|
||||
│ └── references/ # 仓库 API 参考
|
||||
├── gitlink-issue/ # Issue 管理
|
||||
│ ├── SKILL.md # Issue 操作指南
|
||||
│ ├── REFERENCE.md # Issue API 参考
|
||||
│ └── examples/
|
||||
│ └── issue-workflow.md # Issue 全流程工作流
|
||||
│ └── references/ # Issue API 参考
|
||||
├── gitlink-pr/ # Pull Request
|
||||
│ ├── SKILL.md # PR 操作指南
|
||||
│ ├── REFERENCE.md # PR API 参考
|
||||
│ └── examples/
|
||||
│ └── pr-workflow.md # PR 工作流
|
||||
│ └── references/ # PR API 参考
|
||||
├── gitlink-branch/ # 分支管理
|
||||
│ ├── SKILL.md # 分支操作指南
|
||||
│ └── examples/
|
||||
│ └── branch-workflow.md # 分支工作流
|
||||
├── gitlink-release/ # 版本发布
|
||||
│ ├── SKILL.md # Release 操作指南
|
||||
│ ├── REFERENCE.md # Release API 参考
|
||||
│ └── examples/
|
||||
│ └── release-workflow.md # Release 工作流
|
||||
│ └── references/ # Release API 参考
|
||||
├── gitlink-search/ # 搜索功能
|
||||
│ ├── SKILL.md # 搜索操作指南
|
||||
│ └── examples/
|
||||
│ └── search-workflow.md # 搜索工作流
|
||||
│ └── references/ # 搜索参考
|
||||
├── gitlink-user/ # 用户管理
|
||||
│ └── SKILL.md # 用户操作指南
|
||||
├── gitlink-org/ # 组织管理
|
||||
│ ├── SKILL.md # 组织操作指南
|
||||
│ └── examples/
|
||||
│ └── org-workflow.md # 组织工作流
|
||||
│ └── references/ # 组织参考
|
||||
├── gitlink-ci/ # CI/CD
|
||||
│ ├── SKILL.md # CI 操作指南
|
||||
│ └── examples/
|
||||
│ └── ci-workflow.md # CI 工作流
|
||||
│ └── SKILL.md # CI 操作指南
|
||||
├── gitlink-pm/ # 项目管理
|
||||
│ └── SKILL.md # PM 操作指南
|
||||
└── gitlink-workflow/ # AI 自动化工作流
|
||||
└── SKILL.md # 工作流模板（Issue 分类、PR Review、Release Notes）
|
||||
├── gitlink-workflow/ # AI 自动化工作流
|
||||
│ └── SKILL.md # 工作流模板（Issue 分类、PR Review、Release Notes）
|
||||
└── gitlink-maintainer-copilot/ # 维护者驾驶舱
|
||||
├── SKILL.md # 证据包、治理剧本、写入确认
|
||||
├── references/ # 证据包、剧本、治理 Issue 模板
|
||||
└── examples/ # 演示流程和样例报告
|
||||
```
|
||||
|
||||
---
|
||||
|
|
@ -137,6 +126,7 @@ skills/
|
|||
| **gitlink-ci** | CI/CD | `ci +builds`, `ci +logs` |
|
||||
| **gitlink-pm** | 项目管理 | 通过 Raw API 访问 |
|
||||
| **gitlink-workflow** | AI 工作流 | Issue 分类、PR Review、Release Notes |
|
||||
| **gitlink-maintainer-copilot** | 维护者驾驶舱 | 证据包、治理剧本、确认后创建治理 Issue |
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -153,7 +143,7 @@ gitlink-cli repo +info
|
|||
gitlink-cli repo +info --owner wbtiger --repo gitlink-cli
|
||||
```
|
||||
|
||||
详见: [gitlink-repo/examples/repo-workflow.md](gitlink-repo/examples/repo-workflow.md)
|
||||
详见: [gitlink-repo/SKILL.md](gitlink-repo/SKILL.md)
|
||||
|
||||
### 场景 2：创建和管理 Issue
|
||||
|
||||
|
|
@ -162,19 +152,19 @@ gitlink-cli repo +info --owner wbtiger --repo gitlink-cli
|
|||
gitlink-cli issue +create -t "Bug: 登录失败" -b "复现步骤..."
|
||||
|
||||
# 查看 Issue
|
||||
gitlink-cli issue +view -i 123
|
||||
gitlink-cli issue +view -n 123
|
||||
|
||||
# 添加评论
|
||||
gitlink-cli issue +comment -i 123 -b "已修复"
|
||||
|
||||
# 关闭 Issue
|
||||
gitlink-cli issue +close -i 123
|
||||
gitlink-cli issue +close -n 123
|
||||
|
||||
# 预览批量关闭 Issue
|
||||
gitlink-cli issue +batch-close --numbers 123,124 --dry-run
|
||||
```
|
||||
|
||||
详见: [gitlink-issue/examples/issue-workflow.md](gitlink-issue/examples/issue-workflow.md)
|
||||
详见: [gitlink-issue/SKILL.md](gitlink-issue/SKILL.md)
|
||||
|
||||
### 场景 3：管理分支和发布
|
||||
|
||||
|
|
@ -192,7 +182,7 @@ gitlink-cli release +create -t v1.0.0 -n "v1.0.0 正式版" -b "更新内容..."
|
|||
gitlink-cli release +view -i <version_id>
|
||||
```
|
||||
|
||||
详见: [gitlink-release/examples/release-workflow.md](gitlink-release/examples/release-workflow.md)
|
||||
详见: [gitlink-release/SKILL.md](gitlink-release/SKILL.md)
|
||||
|
||||
### 场景 4：搜索和发现
|
||||
|
||||
|
|
@ -208,7 +198,18 @@ gitlink-cli org +list
|
|||
gitlink-cli org +info -i Gitlink
|
||||
```
|
||||
|
||||
详见: [gitlink-search/examples/search-workflow.md](gitlink-search/examples/search-workflow.md)
|
||||
详见: [gitlink-search/SKILL.md](gitlink-search/SKILL.md)
|
||||
|
||||
### 场景 5：生成维护者驾驶舱
|
||||
|
||||
```bash
|
||||
# Agent 会先只读采集证据，再输出治理计划
|
||||
gitlink-cli repo +info --owner Gitlink --repo gitlink-cli --format json
|
||||
gitlink-cli issue +list --owner Gitlink --repo gitlink-cli --state open --format json
|
||||
gitlink-cli pr +list --owner Gitlink --repo gitlink-cli --state open --format json
|
||||
```
|
||||
|
||||
详见: [gitlink-maintainer-copilot/SKILL.md](gitlink-maintainer-copilot/SKILL.md)
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -217,8 +218,8 @@ gitlink-cli org +info -i Gitlink
|
|||
### 快速查找
|
||||
|
||||
- **我想了解认证**: [gitlink-shared/SKILL.md](gitlink-shared/SKILL.md)
|
||||
- **我想查看 API 细节**: [gitlink-shared/REFERENCE.md](gitlink-shared/REFERENCE.md)
|
||||
- **我遇到了错误**: [gitlink-shared/TROUBLESHOOTING.md](gitlink-shared/TROUBLESHOOTING.md)
|
||||
- **我想查看 API 细节**: [gitlink-shared/references/api-reference.md](gitlink-shared/references/api-reference.md)
|
||||
- **我遇到了错误**: [gitlink-shared/references/troubleshooting.md](gitlink-shared/references/troubleshooting.md)
|
||||
- **我想看工作流示例**: 查看各 Skill 下的 `examples/` 目录
|
||||
|
||||
### 按功能分类
|
||||
|
|
@ -226,12 +227,10 @@ gitlink-cli org +info -i Gitlink
|
|||
**仓库操作**:
|
||||
- [gitlink-repo/SKILL.md](gitlink-repo/SKILL.md) - 仓库命令
|
||||
- [gitlink-branch/SKILL.md](gitlink-branch/SKILL.md) - 分支命令
|
||||
- [gitlink-repo/examples/repo-workflow.md](gitlink-repo/examples/repo-workflow.md) - 完整工作流
|
||||
|
||||
**Issue 和 PR**:
|
||||
- [gitlink-issue/SKILL.md](gitlink-issue/SKILL.md) - Issue 命令
|
||||
- [gitlink-pr/SKILL.md](gitlink-pr/SKILL.md) - PR 命令
|
||||
- [gitlink-issue/examples/issue-workflow.md](gitlink-issue/examples/issue-workflow.md) - Issue 工作流
|
||||
|
||||
**发布和搜索**:
|
||||
- [gitlink-release/SKILL.md](gitlink-release/SKILL.md) - Release 命令
|
||||
|
|
@ -241,6 +240,10 @@ gitlink-cli org +info -i Gitlink
|
|||
- [gitlink-org/SKILL.md](gitlink-org/SKILL.md) - 组织命令
|
||||
- [gitlink-user/SKILL.md](gitlink-user/SKILL.md) - 用户命令
|
||||
|
||||
**维护者驾驶舱**:
|
||||
- [gitlink-maintainer-copilot/SKILL.md](gitlink-maintainer-copilot/SKILL.md) - 维护者诊断
|
||||
- [gitlink-maintainer-copilot/examples/maintainer-copilot-workflow.md](gitlink-maintainer-copilot/examples/maintainer-copilot-workflow.md) - 演示流程
|
||||
|
||||
---
|
||||
|
||||
## ❓ 常见问题
|
||||
|
|
@ -272,11 +275,11 @@ gitlink-cli auth login
|
|||
|
||||
### Q: 如何查看完整的 API 参考？
|
||||
|
||||
A: 查看 [gitlink-shared/REFERENCE.md](gitlink-shared/REFERENCE.md)
|
||||
A: 查看 [gitlink-shared/references/api-reference.md](gitlink-shared/references/api-reference.md)
|
||||
|
||||
### Q: 遇到错误怎么办？
|
||||
|
||||
A: 查看 [gitlink-shared/TROUBLESHOOTING.md](gitlink-shared/TROUBLESHOOTING.md)
|
||||
A: 查看 [gitlink-shared/references/troubleshooting.md](gitlink-shared/references/troubleshooting.md)
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -301,6 +304,7 @@ AI 代理可以：
|
|||
- ✅ 自动分类 Issue
|
||||
- ✅ 自动生成 Release Notes
|
||||
- ✅ 自动执行代码审查
|
||||
- ✅ 自动生成维护者驾驶舱和治理 Issue 草稿
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -312,7 +316,7 @@ AI 代理可以：
|
|||
- 所有边界情况处理正确
|
||||
- 完整的文档和示例
|
||||
|
||||
详见: [../doc/SKILLS_TEST_REPORT_2026-04-02.md](../doc/SKILLS_TEST_REPORT_2026-04-02.md)
|
||||
可通过 `cd npm && npm test` 验证 Skill 结构和安装脚本。
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -320,8 +324,6 @@ AI 代理可以：
|
|||
|
||||
- [主项目 README](../README.md) - gitlink-cli 项目说明
|
||||
- [设计文档](../doc/design.md) - 架构设计和开发计划
|
||||
- [测试报告](../doc/SKILLS_TEST_REPORT_2026-04-02.md) - 功能测试报告
|
||||
- [代码同步方案](../doc/CODE_SYNC_STRATEGY_FINAL.md) - GitHub ↔ GitLink 同步设计
|
||||
- [gitlink-bisync](https://www.gitlink.org.cn/wbtiger/gitlink-bisync) - 代码双向同步系统
|
||||
|
||||
---
|
||||
|
|
@ -329,8 +331,8 @@ AI 代理可以：
|
|||
## 📞 获取帮助
|
||||
|
||||
- **命令帮助**: `gitlink-cli <command> --help`
|
||||
- **故障排查**: [gitlink-shared/TROUBLESHOOTING.md](gitlink-shared/TROUBLESHOOTING.md)
|
||||
- **API 参考**: [gitlink-shared/REFERENCE.md](gitlink-shared/REFERENCE.md)
|
||||
- **故障排查**: [gitlink-shared/references/troubleshooting.md](gitlink-shared/references/troubleshooting.md)
|
||||
- **API 参考**: [gitlink-shared/references/api-reference.md](gitlink-shared/references/api-reference.md)
|
||||
- **工作流示例**: 查看各 Skill 下的 `examples/` 目录
|
||||
|
||||
---
|
||||
|
|
@ -338,7 +340,7 @@ AI 代理可以：
|
|||
## 🎓 下一步
|
||||
|
||||
1. 阅读 [gitlink-shared/SKILL.md](gitlink-shared/SKILL.md) 了解基础
|
||||
2. 查看 [gitlink-shared/examples/auth-workflow.md](gitlink-shared/examples/auth-workflow.md) 完成认证
|
||||
2. 查看 [gitlink-shared/SKILL.md](gitlink-shared/SKILL.md) 完成认证
|
||||
3. 根据需求选择相应的 Skill 文档
|
||||
4. 参考 `examples/` 目录中的工作流示例
|
||||
5. 使用 AI 代理自动化你的工作流
|
||||
|
|
|
|||
|
|
@ -0,0 +1,143 @@
|
|||
---
|
||||
name: gitlink-maintainer-copilot
|
||||
version: 1.0.0
|
||||
description: "Use when a maintainer wants a GitLink project diagnosis, governance plan, contributor-readiness check, or a confirmed governance Issue for a repository."
|
||||
metadata:
|
||||
requires:
|
||||
bins: ["gitlink-cli"]
|
||||
cliHelp: "gitlink-cli --help"
|
||||
---
|
||||
|
||||
# gitlink-maintainer-copilot
|
||||
|
||||
**CRITICAL - 开始前必须先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，其中包含认证、权限处理、JSON 输出和 GitLink 工具边界。**
|
||||
**CRITICAL - 默认只读。只有用户明确确认后，才允许创建治理 Issue 或发表评论。**
|
||||
**CRITICAL - 所有结论必须绑定证据；无法采集的数据必须标记为“数据缺失”，不得猜测。**
|
||||
|
||||
## 目标
|
||||
|
||||
本 Skill 帮助 Agent 把 GitLink 仓库数据转化为维护者可执行的驾驶舱：
|
||||
|
||||
- Maintainer Evidence Pack：采集仓库、Issue、PR、Commit、贡献者、Release、CI、README 等证据。
|
||||
- Playbook Diagnosis：根据证据匹配维护剧本，解释风险来源。
|
||||
- 30/60/90 天治理计划：把风险变成可执行任务。
|
||||
- Governance Issue Draft：生成可确认落地的治理 Issue 草稿。
|
||||
|
||||
详细规则见：
|
||||
|
||||
- [`references/evidence-pack.md`](references/evidence-pack.md)
|
||||
- [`references/playbooks.md`](references/playbooks.md)
|
||||
- [`references/governance-issue-template.md`](references/governance-issue-template.md)
|
||||
|
||||
## 适用场景
|
||||
|
||||
当用户提出以下需求时使用本 Skill：
|
||||
|
||||
- “帮我分析这个 GitLink 仓库是否健康”
|
||||
- “给项目做维护者驾驶舱”
|
||||
- “找出 Issue/PR 堵塞点”
|
||||
- “给开源项目生成治理计划”
|
||||
- “帮我创建一个项目治理 Issue”
|
||||
- “比赛演示需要一个可落地的 GitLink Skill”
|
||||
|
||||
不要用于：
|
||||
|
||||
- 单纯查看某个 Issue、PR、Release 的详情；改用对应领域 Skill。
|
||||
- 直接批量修改 Issue、关闭 PR、删除资源。
|
||||
- GitHub/GitLab 仓库；本 Skill 只面向 GitLink。
|
||||
|
||||
## 工作流
|
||||
|
||||
### 1. 建立上下文
|
||||
|
||||
1. 阅读 `gitlink-shared`。
|
||||
2. 确认 `owner` 和 `repo`。如果当前目录是 GitLink 仓库，可以依赖 `gitlink-cli` 自动从 remote 解析。
|
||||
3. 说明默认只读，并告诉用户写入治理 Issue 前会二次确认。
|
||||
|
||||
### 2. 采集证据
|
||||
|
||||
优先使用 Shortcuts，所有命令都加 `--format json`。
|
||||
|
||||
```bash
|
||||
gitlink-cli repo +info --owner <owner> --repo <repo> --format json
|
||||
gitlink-cli issue +list --owner <owner> --repo <repo> --state open --limit 100 --format json
|
||||
gitlink-cli issue +list --owner <owner> --repo <repo> --state closed --limit 100 --format json
|
||||
gitlink-cli pr +list --owner <owner> --repo <repo> --state open --limit 100 --format json
|
||||
gitlink-cli pr +list --owner <owner> --repo <repo> --state merged --limit 100 --format json
|
||||
gitlink-cli pr +list --owner <owner> --repo <repo> --state closed --limit 100 --format json
|
||||
gitlink-cli release +list --owner <owner> --repo <repo> --format json
|
||||
gitlink-cli ci +builds --owner <owner> --repo <repo> --format json
|
||||
```
|
||||
|
||||
Shortcuts 未覆盖时使用 Raw API：
|
||||
|
||||
```bash
|
||||
gitlink-cli api GET /v1/<owner>/<repo>/commits --query 'page=1&limit=100' --format json
|
||||
gitlink-cli api GET /v1/<owner>/<repo>/contributors/stat --format json
|
||||
gitlink-cli api GET /<owner>/<repo>/languages --format json
|
||||
gitlink-cli api GET /<owner>/<repo>/readme --format json
|
||||
```
|
||||
|
||||
如果某个命令失败，不要中断整个诊断。记录：
|
||||
|
||||
- 命令
|
||||
- 失败原因
|
||||
- 该缺失会影响哪些判断
|
||||
|
||||
### 3. 生成 Evidence Pack
|
||||
|
||||
按 [`references/evidence-pack.md`](references/evidence-pack.md) 汇总证据。每条结论都必须能追溯到至少一个证据项。
|
||||
|
||||
证据引用格式：
|
||||
|
||||
```text
|
||||
[E3: open_prs] open PR count = 8, oldest updated_at = 2026-03-10
|
||||
```
|
||||
|
||||
### 4. 匹配治理剧本
|
||||
|
||||
按 [`references/playbooks.md`](references/playbooks.md) 选择 1-3 个剧本。优先选择证据最充分、对维护者最有行动价值的剧本。
|
||||
|
||||
输出时必须包含：
|
||||
|
||||
- 匹配剧本名称
|
||||
- 触发证据
|
||||
- 风险等级：High / Medium / Low
|
||||
- 本周可执行动作
|
||||
- 30/60/90 天治理计划
|
||||
|
||||
### 5. 生成驾驶舱报告
|
||||
|
||||
报告必须包含：
|
||||
|
||||
1. 项目维护状态总览
|
||||
2. Evidence Pack 摘要
|
||||
3. 3-5 个关键风险
|
||||
4. 匹配到的治理剧本
|
||||
5. 30/60/90 天治理计划
|
||||
6. Governance Issue 草稿
|
||||
7. 数据缺失和可信度说明
|
||||
|
||||
参考 [`examples/sample-dashboard-report.md`](examples/sample-dashboard-report.md)。
|
||||
|
||||
### 6. 写入确认闸门
|
||||
|
||||
默认不要写入 GitLink。只有当用户明确说“创建治理 Issue”“发布这个 Issue”“确认写入”等同义指令后，才可以执行写入。
|
||||
|
||||
写入前必须展示将执行的命令和完整 Issue 内容：
|
||||
|
||||
```bash
|
||||
gitlink-cli issue +create --owner <owner> --repo <repo> \
|
||||
--title "<governance issue title>" \
|
||||
--body "<governance issue body>"
|
||||
```
|
||||
|
||||
用户确认后只创建一个治理 Issue。不要批量创建 Issue，不要关闭 Issue，不要评论 PR，除非用户另行明确要求。
|
||||
|
||||
## 输出准则
|
||||
|
||||
- 用中文输出，保留 Evidence Pack、Playbook、Governance Issue 等少量英文术语。
|
||||
- 风险判断要克制：有证据就判断，无证据就标注缺失。
|
||||
- 建议必须能被维护者执行，避免“加强管理”“优化流程”这类空话。
|
||||
- 治理任务要有验收标准，例如“关闭或回复 10 个超过 14 天未更新的 Issue”。
|
||||
- 如果仓库是新项目或数据量很少，报告重点转为“治理基线补齐”，不要给出虚假的趋势分析。
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
# Maintainer Copilot Workflow
|
||||
|
||||
本示例展示 Agent 如何使用 `gitlink-maintainer-copilot` 生成维护者驾驶舱，并在用户确认后创建治理 Issue。
|
||||
|
||||
## 1. 用户请求
|
||||
|
||||
```text
|
||||
帮我给 Gitlink/gitlink-cli 生成一个维护者驾驶舱，并准备一个可落地的治理 Issue。
|
||||
```
|
||||
|
||||
## 2. Agent 声明只读采集
|
||||
|
||||
```text
|
||||
我会先使用 gitlink-cli 只读采集仓库、Issue、PR、Release、CI、Commit 和贡献者数据。不会写入 GitLink；如果需要创建治理 Issue，我会先展示完整草稿并等待你确认。
|
||||
```
|
||||
|
||||
## 3. 采集证据
|
||||
|
||||
```bash
|
||||
gitlink-cli repo +info --owner Gitlink --repo gitlink-cli --format json
|
||||
gitlink-cli issue +list --owner Gitlink --repo gitlink-cli --state open --limit 100 --format json
|
||||
gitlink-cli issue +list --owner Gitlink --repo gitlink-cli --state closed --limit 100 --format json
|
||||
gitlink-cli pr +list --owner Gitlink --repo gitlink-cli --state open --limit 100 --format json
|
||||
gitlink-cli pr +list --owner Gitlink --repo gitlink-cli --state merged --limit 100 --format json
|
||||
gitlink-cli pr +list --owner Gitlink --repo gitlink-cli --state closed --limit 100 --format json
|
||||
gitlink-cli release +list --owner Gitlink --repo gitlink-cli --format json
|
||||
gitlink-cli ci +builds --owner Gitlink --repo gitlink-cli --format json
|
||||
gitlink-cli api GET /v1/Gitlink/gitlink-cli/commits --query 'page=1&limit=100' --format json
|
||||
gitlink-cli api GET /v1/Gitlink/gitlink-cli/contributors/stat --format json
|
||||
gitlink-cli api GET /Gitlink/gitlink-cli/languages --format json
|
||||
gitlink-cli api GET /Gitlink/gitlink-cli/readme --format json
|
||||
```
|
||||
|
||||
## 4. 输出驾驶舱报告
|
||||
|
||||
报告结构：
|
||||
|
||||
```markdown
|
||||
# GitLink Maintainer Copilot Report
|
||||
|
||||
## 维护状态总览
|
||||
...
|
||||
|
||||
## Evidence Pack
|
||||
...
|
||||
|
||||
## 关键风险
|
||||
...
|
||||
|
||||
## 匹配 Playbooks
|
||||
...
|
||||
|
||||
## 30/60/90 天治理计划
|
||||
...
|
||||
|
||||
## Governance Issue 草稿
|
||||
...
|
||||
|
||||
## 数据缺失与可信度
|
||||
...
|
||||
```
|
||||
|
||||
完整样例见 [`sample-dashboard-report.md`](sample-dashboard-report.md)。
|
||||
|
||||
## 5. 请求写入确认
|
||||
|
||||
Agent 展示完整治理 Issue 草稿后询问：
|
||||
|
||||
```text
|
||||
以上是将创建的治理 Issue 内容。请明确回复“确认创建治理 Issue”，我才会执行写入。
|
||||
```
|
||||
|
||||
## 6. 用户确认后创建 Issue
|
||||
|
||||
```bash
|
||||
gitlink-cli issue +create --owner Gitlink --repo gitlink-cli \
|
||||
--title "chore: 建立 gitlink-cli 项目维护治理计划" \
|
||||
--body "<完整治理 Issue 正文>"
|
||||
```
|
||||
|
||||
## 7. 完成后回报
|
||||
|
||||
```text
|
||||
治理 Issue 已创建。后续维护者可以按 30/60/90 天计划逐项勾选，并在下次运行 Maintainer Copilot 时对比进度。
|
||||
```
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
# GitLink Maintainer Copilot Report
|
||||
|
||||
> 样例报告使用模拟数据，适合比赛 README、截图或录屏展示。真实执行时必须使用 `gitlink-cli` 采集 Evidence Pack。
|
||||
|
||||
## 维护状态总览
|
||||
|
||||
项目：`Gitlink/gitlink-cli`
|
||||
|
||||
总体判断：维护状态为 **Medium Risk**。项目已有清晰 CLI 能力和 Agent Skills 基础，但 PR 响应、Release 节奏和新人引导材料需要进一步稳定。
|
||||
|
||||
可信度：High。已采集仓库详情、Issue、PR、Release、Commit、贡献者和 README 数据；CI 数据缺失。
|
||||
|
||||
## Evidence Pack
|
||||
|
||||
| 编号 | 摘要 |
|
||||
|---|---|
|
||||
| E1 repo_profile | 仓库有 README、默认分支为 `master`，License 存在，watchers=42，forked=18 |
|
||||
| E2 open_issues | open Issue 16 个，其中 5 个超过 14 天未更新 |
|
||||
| E3 closed_issues | 最近关闭 Issue 22 个，说明仍有维护活动 |
|
||||
| E4 open_prs | open PR 7 个，其中 3 个超过 7 天未更新 |
|
||||
| E5 merged_prs | 最近合并 PR 11 个，主要集中在 CLI bugfix 和文档 |
|
||||
| E7 releases | 最近 Release 距今 45 天 |
|
||||
| E8 ci_builds | 数据缺失，无法判断 CI 稳定性 |
|
||||
| E9 commits | 最近 100 个提交中包含 18 个 fix、9 个 docs、6 个 feat |
|
||||
| E10 contributors | 贡献者 6 人，前 2 名贡献占比约 76% |
|
||||
| E12 readme | README 有安装说明，但贡献入口和新人任务入口不明显 |
|
||||
|
||||
## 关键风险
|
||||
|
||||
1. **PR 堵塞风险中等**：[E4] open PR 7 个，3 个超过 7 天未更新，可能降低外部贡献者反馈体验。
|
||||
2. **新人转化不足**：[E12] README 缺少明确新人入口；[E2] open Issue 中可领取任务标识不足。
|
||||
3. **Release 节奏不稳定**：[E7] 最近 Release 距今 45 天；[E9] 已累计多项 fix/feat/docs 变更。
|
||||
4. **贡献者集中度偏高**：[E10] 前 2 名贡献占比约 76%，存在维护者负载集中风险。
|
||||
5. **CI 可信度缺失**：[E8] 未采集到 CI 数据，无法确认基础自动化质量。
|
||||
|
||||
## 匹配 Playbooks
|
||||
|
||||
### P2 PR 堵塞清理
|
||||
|
||||
触发证据：[E4] open PR 7 个，其中 3 个超过 7 天未更新。
|
||||
|
||||
本周动作：
|
||||
|
||||
- 对所有 open PR 留下最新维护者反馈。
|
||||
- 将 PR 分为“可合并 / 需要修改 / 已过期”三组。
|
||||
- 优先处理文档和低风险 bugfix PR。
|
||||
|
||||
### P3 新人友好改造
|
||||
|
||||
触发证据：[E12] README 新人入口不足；[E2] open Issue 缺少可领取标识。
|
||||
|
||||
本周动作：
|
||||
|
||||
- 在 README 增加“首次贡献”小节。
|
||||
- 选择 3 个低风险 Issue 补充复现步骤和验收标准。
|
||||
- 给新人任务添加清晰标签或标题前缀。
|
||||
|
||||
### P4 Release 稳定化
|
||||
|
||||
触发证据：[E7] Release 间隔较长；[E9] 最近已有多项用户可见变更。
|
||||
|
||||
本周动作：
|
||||
|
||||
- 生成下一版 Release Notes 草稿。
|
||||
- 将最近合并变更归类为 Added / Fixed / Docs。
|
||||
- 确认 CI 或手工验证结果后再发布。
|
||||
|
||||
## 30/60/90 天治理计划
|
||||
|
||||
30 天：
|
||||
|
||||
- [ ] 所有 open PR 都有维护者反馈，超过 14 天未更新的 PR 降到 0。
|
||||
- [ ] README 增加首次贡献入口和本地运行最短路径。
|
||||
- [ ] 建立下一个 Release 的变更清单草稿。
|
||||
|
||||
60 天：
|
||||
|
||||
- [ ] 固化 PR 评审 SLA，例如 7 天内首次响应。
|
||||
- [ ] 整理 3-5 个适合新人领取的 Issue。
|
||||
- [ ] 补齐 Issue/PR 模板，降低沟通成本。
|
||||
|
||||
90 天：
|
||||
|
||||
- [ ] 形成每月维护节奏，固定回顾 Issue、PR、Release 状态。
|
||||
- [ ] 将基础检查纳入 CI 或公开验证说明。
|
||||
- [ ] 复盘新人 Issue 的领取和合并情况。
|
||||
|
||||
## Governance Issue 草稿
|
||||
|
||||
标题：
|
||||
|
||||
```text
|
||||
chore: 建立 gitlink-cli 项目维护治理计划
|
||||
```
|
||||
|
||||
正文摘要：
|
||||
|
||||
```markdown
|
||||
## 背景
|
||||
|
||||
本 Issue 由 GitLink Maintainer Copilot 根据仓库数据生成，用于跟踪项目维护治理动作。
|
||||
|
||||
## 诊断结论
|
||||
|
||||
风险等级：Medium
|
||||
|
||||
匹配治理剧本：
|
||||
|
||||
- P2 PR 堵塞清理：[E4] open PR 7 个，3 个超过 7 天未更新。
|
||||
- P3 新人友好改造：[E12] README 新人入口不足。
|
||||
- P4 Release 稳定化：[E7] Release 距今 45 天。
|
||||
|
||||
## 本周建议动作
|
||||
|
||||
- [ ] 回复所有超过 7 天未更新的 open PR。
|
||||
- [ ] 补 README 首次贡献入口。
|
||||
- [ ] 生成下一版 Release Notes 草稿。
|
||||
```
|
||||
|
||||
## 数据缺失与可信度
|
||||
|
||||
| 缺失项 | 影响 | 建议 |
|
||||
|---|---|---|
|
||||
| E8 ci_builds | 无法判断 CI 稳定性 | 维护者可补充 CI 权限或手工验证记录 |
|
||||
|
||||
确认写入前，Agent 必须展示完整 Issue 正文并等待用户明确确认。
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
# Maintainer Evidence Pack
|
||||
|
||||
Evidence Pack 是维护者驾驶舱的证据层。Agent 必须先采集证据，再给诊断和建议。
|
||||
|
||||
## 采集原则
|
||||
|
||||
- 优先只读命令。
|
||||
- 每条诊断至少引用一个证据编号。
|
||||
- 采集失败时记录缺失，不猜测。
|
||||
- 同一个指标来自多个命令时，以更具体的数据为准，并说明来源。
|
||||
|
||||
## 证据清单
|
||||
|
||||
| 编号 | 名称 | 命令 | 主要字段 | 用途 |
|
||||
|---|---|---|---|---|
|
||||
| E1 | repo_profile | `gitlink-cli repo +info --format json` | `full_name`, `description`, `default_branch`, `license_name`, `watchers_count`, `forked_count`, `issues_count`, `pull_requests_count`, `empty` | 判断基础治理、项目吸引力、默认分支和公开信息 |
|
||||
| E2 | open_issues | `gitlink-cli issue +list --state open --limit 100 --format json` | `subject`, `project_issues_index`, `created_at`, `updated_at`, `status_name`, `priority_name`, `assigners`, `tags`, `comment_journals_count` | 判断 Issue 积压、无人响应、分类质量 |
|
||||
| E3 | closed_issues | `gitlink-cli issue +list --state closed --limit 100 --format json` | 同 E2 | 判断处理节奏、关闭质量、近期维护痕迹 |
|
||||
| E4 | open_prs | `gitlink-cli pr +list --state open --limit 100 --format json` | `title`, `pull_request_number`, `created_at`, `updated_at`, `pull_request_status`, `user`, `head`, `base` | 判断 PR 堵塞、评审延迟、分支目标 |
|
||||
| E5 | merged_prs | `gitlink-cli pr +list --state merged --limit 100 --format json` | 同 E4 | 判断合并效率、近期协作活跃度 |
|
||||
| E6 | closed_prs | `gitlink-cli pr +list --state closed --limit 100 --format json` | 同 E4 | 判断拒绝/关闭模式 |
|
||||
| E7 | releases | `gitlink-cli release +list --format json` | `name`, `tag_name`, `created_at`, `description`, `version_id` | 判断发布成熟度 |
|
||||
| E8 | ci_builds | `gitlink-cli ci +builds --format json` | `id`, `status`, `created_at`, `duration`, `branch`, `commit` | 判断自动化质量 |
|
||||
| E9 | commits | `gitlink-cli api GET /v1/<owner>/<repo>/commits --query 'page=1&limit=100' --format json` | `sha`, `commit_message`, `commit_time`, `author`, `files` | 判断近期活跃、提交分布和变更主题 |
|
||||
| E10 | contributors | `gitlink-cli api GET /v1/<owner>/<repo>/contributors/stat --format json` | `total_count`, `contributors[].login`, `contributions`, `additions`, `deletions` | 判断贡献者集中度和协作风险 |
|
||||
| E11 | languages | `gitlink-cli api GET /<owner>/<repo>/languages --format json` | language map | 判断技术栈和 README/CI 建议 |
|
||||
| E12 | readme | `gitlink-cli api GET /<owner>/<repo>/readme --format json` | `content`, `encoding`, `sha` | 判断新手上手信息 |
|
||||
|
||||
## 缺失数据处理
|
||||
|
||||
记录格式：
|
||||
|
||||
```markdown
|
||||
| 缺失项 | 命令 | 影响 | 后续建议 |
|
||||
|---|---|---|---|
|
||||
| E8 ci_builds | `gitlink-cli ci +builds ...` | 无法判断 CI 稳定性 | 在报告中把 CI 结论标为“未验证” |
|
||||
```
|
||||
|
||||
常见处理：
|
||||
|
||||
- `401`：提示用户运行 `gitlink-cli auth login`，继续公开数据诊断。
|
||||
- `403`：说明权限不足，避免输出内部治理判断。
|
||||
- `404`：确认 owner/repo 是否正确。
|
||||
- 空数组：这不是失败。应解读为“当前样本为空”，例如暂无 Release 或暂无 open PR。
|
||||
|
||||
## 证据引用格式
|
||||
|
||||
在报告中使用紧凑引用：
|
||||
|
||||
```markdown
|
||||
- PR 堵塞风险高：[E4] open PR 8 个，其中 3 个超过 14 天未更新。
|
||||
- 发布成熟度不足：[E7] 未发现 Release；[E9] 最近 100 个提交中已有 12 个 feat/fix 变更。
|
||||
```
|
||||
|
||||
## 可信度等级
|
||||
|
||||
| 等级 | 条件 |
|
||||
|---|---|
|
||||
| High | E1-E7 至少 6 项可用，且 E9 或 E10 至少 1 项可用 |
|
||||
| Medium | E1-E7 至少 4 项可用 |
|
||||
| Low | 少于 4 项可用，或关键数据仅来自单一来源 |
|
||||
|
||||
可信度低时，输出应以“建议先补齐数据采集/权限”为主。
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
# Governance Issue Template
|
||||
|
||||
创建治理 Issue 前，必须先把完整草稿展示给用户并获得明确确认。
|
||||
|
||||
## 标题模板
|
||||
|
||||
```text
|
||||
chore: 建立 <repo> 项目维护治理计划
|
||||
```
|
||||
|
||||
## 正文模板
|
||||
|
||||
```markdown
|
||||
## 背景
|
||||
|
||||
本 Issue 由 GitLink Maintainer Copilot 根据仓库公开/授权数据生成，用于跟踪项目维护治理动作。
|
||||
|
||||
## Evidence Pack
|
||||
|
||||
- [E1: repo_profile] <仓库基础信息摘要>
|
||||
- [E2: open_issues] <open Issue 摘要>
|
||||
- [E4: open_prs] <open PR 摘要>
|
||||
- [E7: releases] <Release 摘要>
|
||||
- [E9: commits] <提交活跃摘要>
|
||||
- [E10: contributors] <贡献者摘要>
|
||||
|
||||
数据缺失：
|
||||
|
||||
- <如无缺失，写“无关键缺失”。>
|
||||
|
||||
## 诊断结论
|
||||
|
||||
风险等级：<High / Medium / Low>
|
||||
|
||||
匹配治理剧本：
|
||||
|
||||
- <Playbook 名称>：<触发证据>
|
||||
|
||||
关键风险：
|
||||
|
||||
1. <风险 1，引用证据>
|
||||
2. <风险 2，引用证据>
|
||||
3. <风险 3，引用证据>
|
||||
|
||||
## 30/60/90 天计划
|
||||
|
||||
30 天：
|
||||
|
||||
- [ ] <任务，含验收标准>
|
||||
- [ ] <任务，含验收标准>
|
||||
|
||||
60 天：
|
||||
|
||||
- [ ] <任务，含验收标准>
|
||||
- [ ] <任务，含验收标准>
|
||||
|
||||
90 天：
|
||||
|
||||
- [ ] <任务，含验收标准>
|
||||
- [ ] <任务，含验收标准>
|
||||
|
||||
## 本周建议动作
|
||||
|
||||
- [ ] <最小可执行动作 1>
|
||||
- [ ] <最小可执行动作 2>
|
||||
- [ ] <最小可执行动作 3>
|
||||
|
||||
## 验收标准
|
||||
|
||||
- <可验证标准 1>
|
||||
- <可验证标准 2>
|
||||
- <可验证标准 3>
|
||||
|
||||
---
|
||||
|
||||
生成方式：GitLink Maintainer Copilot Skill
|
||||
```
|
||||
|
||||
## 写入命令
|
||||
|
||||
用户确认后执行：
|
||||
|
||||
```bash
|
||||
gitlink-cli issue +create --owner <owner> --repo <repo> \
|
||||
--title "chore: 建立 <repo> 项目维护治理计划" \
|
||||
--body "<上方正文>"
|
||||
```
|
||||
|
||||
## 禁止事项
|
||||
|
||||
- 不要批量创建多个治理 Issue。
|
||||
- 不要在未确认前执行写入。
|
||||
- 不要把 Token、私有邮箱、调试日志放入 Issue 正文。
|
||||
- 不要把缺失数据写成确定结论。
|
||||
|
|
@ -0,0 +1,166 @@
|
|||
# Maintainer Playbooks
|
||||
|
||||
Playbook 是把 Evidence Pack 转成治理动作的规则库。Agent 应选择 1-3 个最相关剧本。
|
||||
|
||||
## P1 低活跃恢复
|
||||
|
||||
触发条件：
|
||||
|
||||
- [E9] 最近 30 天提交很少或没有提交。
|
||||
- [E2] open Issue 有新增但缺少回复。
|
||||
- [E10] 贡献者集中在 1-2 人。
|
||||
|
||||
风险信号：
|
||||
|
||||
- 项目对外仍有关注、Fork 或 Issue，但维护节奏下降。
|
||||
- 新贡献者不知道项目是否还接受贡献。
|
||||
|
||||
本周动作：
|
||||
|
||||
- 回复所有超过 14 天未更新的 open Issue。
|
||||
- 创建“维护状态说明”Issue，说明当前优先级和可接受贡献范围。
|
||||
- 标记 2-3 个适合外部贡献者的小任务。
|
||||
|
||||
30/60/90 天计划：
|
||||
|
||||
- 30 天：清理过期 Issue，保留可复现、可行动的问题。
|
||||
- 60 天：补 README 的安装、运行、贡献入口。
|
||||
- 90 天：建立每月一次的维护节奏，发布一个小版本或维护公告。
|
||||
|
||||
验收标准：
|
||||
|
||||
- open Issue 中超过 14 天未回复的数量减少 70%。
|
||||
- 至少 3 个 Issue 有明确下一步。
|
||||
- README 有贡献入口或维护状态说明。
|
||||
|
||||
## P2 PR 堵塞清理
|
||||
|
||||
触发条件：
|
||||
|
||||
- [E4] open PR 数量较多。
|
||||
- [E4] 存在超过 7 天未更新或未评审的 PR。
|
||||
- [E5] merged PR 样本少于 open PR 样本。
|
||||
|
||||
风险信号：
|
||||
|
||||
- 贡献者提交后长期没有反馈。
|
||||
- PR 无法合并导致贡献热情下降。
|
||||
|
||||
本周动作：
|
||||
|
||||
- 按“可合并 / 需要修改 / 已过期”三类整理 open PR。
|
||||
- 对每个超过 7 天未更新的 PR 留下明确反馈。
|
||||
- 优先合并低风险文档、测试、修复类 PR。
|
||||
|
||||
30/60/90 天计划：
|
||||
|
||||
- 30 天：把 open PR 降到可管理数量。
|
||||
- 60 天：建立 PR 模板和评审 SLA。
|
||||
- 90 天：把常见检查迁移到 CI，减少人工评审负担。
|
||||
|
||||
验收标准：
|
||||
|
||||
- 所有 open PR 都有最新维护者反馈。
|
||||
- 超过 14 天未更新的 open PR 数量降到 0 或给出关闭理由。
|
||||
- 新 PR 平均首次响应时间少于 7 天。
|
||||
|
||||
## P3 新人友好改造
|
||||
|
||||
触发条件：
|
||||
|
||||
- [E12] README 缺少安装、运行、测试、贡献指南中的任意两项。
|
||||
- [E2] open Issue 缺少标签或优先级。
|
||||
- [E10] 贡献者数量少，但项目仍有 Issue 或关注。
|
||||
|
||||
风险信号：
|
||||
|
||||
- 潜在贡献者无法判断从哪里开始。
|
||||
- Issue 内容对新人不可执行。
|
||||
|
||||
本周动作：
|
||||
|
||||
- 在 README 补充最短运行路径。
|
||||
- 给 2-5 个简单 Issue 加上“good first issue”或等价说明。
|
||||
- 为新人任务补充复现步骤、预期行为和验收标准。
|
||||
|
||||
30/60/90 天计划：
|
||||
|
||||
- 30 天：补齐 README、CONTRIBUTING 或 Issue 模板。
|
||||
- 60 天：形成新人任务池。
|
||||
- 90 天：复盘新人贡献转化，保留有效标签和模板。
|
||||
|
||||
验收标准：
|
||||
|
||||
- README 包含安装、运行、测试、贡献四个入口。
|
||||
- 至少 3 个 Issue 可被新人独立领取。
|
||||
- 新 Issue 模板能引导用户提供复现信息。
|
||||
|
||||
## P4 Release 稳定化
|
||||
|
||||
触发条件：
|
||||
|
||||
- [E7] 没有 Release，或最近 Release 距今较久。
|
||||
- [E9] 最近提交包含多项功能或修复。
|
||||
- [E5] 已合并 PR 有明显用户可见变更。
|
||||
|
||||
风险信号：
|
||||
|
||||
- 用户无法判断可用版本。
|
||||
- 变更沉淀在提交记录中，没有形成版本说明。
|
||||
|
||||
本周动作：
|
||||
|
||||
- 生成下一版 Release Notes 草稿。
|
||||
- 梳理已合并变更为 `Added / Fixed / Changed / Docs`。
|
||||
- 明确是否需要补充测试或 CI 后再发布。
|
||||
|
||||
30/60/90 天计划：
|
||||
|
||||
- 30 天：发布一个维护版本或明确下个版本计划。
|
||||
- 60 天：固定 Release Notes 模板。
|
||||
- 90 天：把 Release 与里程碑、Issue、PR 建立关联。
|
||||
|
||||
验收标准：
|
||||
|
||||
- 至少有一个可追溯 Release 或版本计划。
|
||||
- Release Notes 能关联主要 Issue/PR/Commit。
|
||||
- 用户能从 README 找到最新稳定版本。
|
||||
|
||||
## P5 基础治理补齐
|
||||
|
||||
触发条件：
|
||||
|
||||
- [E1] `license_name` 为空。
|
||||
- [E1] description 为空或项目元信息不足。
|
||||
- [E8] CI 数据缺失或持续失败。
|
||||
- [E12] README 缺失或内容过短。
|
||||
|
||||
风险信号：
|
||||
|
||||
- 项目难以被搜索、复用、评审或贡献。
|
||||
- 比赛/开源收录时材料不完整。
|
||||
|
||||
本周动作：
|
||||
|
||||
- 补项目描述、License、README 快速开始。
|
||||
- 确认默认分支和基础 CI 状态。
|
||||
- 建立一个“项目治理基线”Issue 追踪补齐事项。
|
||||
|
||||
30/60/90 天计划：
|
||||
|
||||
- 30 天：补齐 README、License、基础元信息。
|
||||
- 60 天：补 Issue/PR 模板和贡献说明。
|
||||
- 90 天：形成版本发布、CI、维护响应的固定节奏。
|
||||
|
||||
验收标准：
|
||||
|
||||
- 仓库详情中项目描述、License、README 均可见。
|
||||
- CI 至少覆盖构建或测试中的一项。
|
||||
- 维护者能用一个治理 Issue 跟踪剩余事项。
|
||||
|
||||
## 选择规则
|
||||
|
||||
- High 风险剧本优先。
|
||||
- 同类风险只选择一个主剧本，避免输出重复建议。
|
||||
- 如果数据样本少，优先选择 P5 基础治理补齐。
|
||||
- 如果用户明确关注新人、Release 或 PR，则用户目标优先于自动排序。
|
||||
Loading…
Reference in New Issue