158 lines
4.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
name: issue
description: 获取任意 Gitea 仓库的 issue 列表和单条详情,支持状态筛选、完整仓库 URL 输入和格式化输出。
---
# Issue - 通用 Gitea Issue 查看
> **定位**:输入完整 Gitea 仓库 URL快速查看 issue 列表或单条详情。默认只输出事实结果,不主动扩展成 roadmap、主题归纳或优先级分析。
当用户调用 `issue` skill、`/issue <repo-url>``$issue <repo-url>``/issue <repo-url> <issue-number>` 或自然语言要求“用 issue skill 查看某个 Gitea 仓库的问题”时,执行以下步骤。
## 1. 解析输入
- `repo-url` 必须是完整仓库地址,例如 `https://git.example.com/owner/repo`
- 允许尾部带 `/``.git`,先规范化后再解析
- 第二个位置参数如果是纯数字,视为 `issue-number`,进入详情模式
- `--state` 仅支持 `open``closed``all`,默认 `open`
- `--limit` 默认 `50`
- 不支持只传 issue 编号;如果缺少仓库 URL先提示正确用法再停止
规范化后,从 `repo-url` 提取:
- `origin`:例如 `https://git.example.com`
- `owner`
- `repo`
- `repo_path`:例如 `owner/repo`
如果 URL 不是标准仓库地址,明确提示“仓库 URL 格式无效,需为 `https://host/owner/repo`”。
## 2. 检查环境变量
先读取环境变量 `GITEA_TOKEN`
如果缺失,输出:
```bash
❌ 缺少 GITEA_TOKEN
请先在当前 shell 或 .env 中配置:
export GITEA_TOKEN=your_gitea_token
```
然后停止,不继续请求 API。
## 3. 调用 Gitea API
不要调用仓库元信息接口,避免依赖 `read:repository` scope。仓库标题直接使用 `repo_path`
### 3.1 列表模式
请求:
```bash
curl -sS -o /tmp/gitea_issues.json -w "%{http_code}" \
-H "Authorization: token ${GITEA_TOKEN}" \
"${origin}/api/v1/repos/${owner}/${repo}/issues?state=${state}&limit=${limit}"
```
### 3.2 详情模式
先请求 issue 详情:
```bash
curl -sS -o /tmp/gitea_issue_detail.json -w "%{http_code}" \
-H "Authorization: token ${GITEA_TOKEN}" \
"${origin}/api/v1/repos/${owner}/${repo}/issues/${issue_number}"
```
再请求评论:
```bash
curl -sS -o /tmp/gitea_issue_comments.json -w "%{http_code}" \
-H "Authorization: token ${GITEA_TOKEN}" \
"${origin}/api/v1/repos/${owner}/${repo}/issues/${issue_number}/comments"
```
### 3.3 错误处理
根据 HTTP 状态码给出简短、直接的提示:
- `401``GITEA_TOKEN` 无效或未生效
- `403`token scope 不足,或当前用户无权访问该仓库/issue
- `404`:仓库不存在,或该 issue 编号不存在
- 其他非 `2xx`:输出状态码和响应中的 `message`
如果列表接口返回项里存在 `pull_request` 且非空,排除这些项,只保留 issue。
## 4. 格式化输出
优先使用 `jq` 解析 JSON如果环境没有 `jq`,再退回模型手工整理,但输出结构保持一致。
### 4.1 列表模式
输出结构固定为:
```markdown
📋 {repo_path} Issues
状态: {state} | 数量: {count} | 限制: {limit}
| # | 标题 | 优先级 | 标签 | 状态 | 提出人 |
|---|------|--------|------|------|--------|
| 35 | 小红书笔记状态查询 | P:紧急 | P:紧急, 需求 | open | zhangsan |
```
字段规则:
- `优先级`:从 labels 中提取首个匹配 `^P[:]` 的 label没有则填 `-`
- `标签`:保留全部 label 原文,用 `, ` 连接;没有则填 `-`
- `提出人`:优先显示 `user.full_name`,没有则显示 `user.login`
- `状态`:直接显示 `open``closed`
如果过滤后没有任何 issue明确输出“无符合条件的 issue”。
### 4.2 详情模式
输出结构固定为:
```markdown
## #{number} {title}
- 仓库: {repo_path}
- 状态: {state}
- 标签: {labels}
- 提出人: {author}
- 创建时间: {created_at}
- 更新时间: {updated_at}
### 正文
{body 或 “无正文”}
### 评论
- {author} | {created_at} | {1-2 句摘要}
```
规则:
- 正文为空时写“无正文”
- 评论按时间顺序输出
- 每条评论只保留 1-2 句摘要;不要整段照抄超长评论
- 没有评论时明确写“无评论”
## 5. 行为边界
- 默认只做列表和单条详情不主动做主题归纳、epic 合并、优先级建议
- 用户后续如果要求摘要、优先级排序、相似 issue 合并,再基于已拉取的数据继续分析
- 不要求 `GITEA_BASE_URL`
## 6. 用法示例
```bash
/issue https://git.internal.intelligrow.cn/intelligrow/feishu_gitea_bridge
/issue https://git.internal.intelligrow.cn/intelligrow/feishu_gitea_bridge --state=all --limit=20
/issue https://git.internal.intelligrow.cn/intelligrow/feishu_gitea_bridge 17
```