---
name: issue
description: 获取任意 Gitea 仓库的 issue 列表和单条详情，支持状态筛选、完整仓库 URL 输入和格式化输出。
---

# Issue - 通用 Gitea Issue 查看

> **定位**：输入完整 Gitea 仓库 URL，快速查看 issue 列表或单条详情。默认只输出事实结果，不主动扩展成 roadmap、主题归纳或优先级分析。

当用户调用 `/issue <repo-url>`、`/issue <repo-url> --state=open|closed|all --limit=<N>`、`/issue <repo-url> <issue-number>`、`$issue <repo-url>`、`$issue <repo-url> --state=open|closed|all --limit=<N>`、`$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

$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
```