fetch-issues

获取议题

适用场景

当用户想查看其跟踪器中的未关闭议题时使用此方法。它会报告跟踪器返回的内容，不会更改任何议题。

如果用户要查看某个已知议题，只需读取该议题——在 GitHub 上使用 gh issue view <number>——而不是获取整个列表。

前提条件

1. 获取任何内容前，先确定跟踪器和目标：
   • 如果用户明确指定了本次要使用的仓库或项目，就使用该目标。
   • 否则，读取 docs/agents/issue-tracker.md 中的 Backend、Location 和 Reading 部分。
   • 如果缺少配置、配置未指定目标或目标不明确，请询问用户。不要根据目录名称猜测，也不要悄悄改用 Git 远程仓库。
2. 确认后端可访问：
   • **GitHub：**运行 command -v gh；如果未安装，请引导用户访问 https://cli.github.com/ 并停止。然后运行 gh auth status；如果失败，请保留错误信息中有用的部分，告知用户运行 gh auth login，然后停止。
   • **本地 Markdown：**确认记录的 Location 存在。
   • **其他后端：**使用 Reading 部分中 "List open issues" 行指定的方法。如果配置中没有 Reading 部分，请询问如何列出议题，不要猜测。如果记录的工具不可用——例如未安装 CLI 或未连接 MCP 服务——请说明情况并停止。

获取议题

**GitHub。**请求完整报告所需的字段，并设置明确的上限，避免 GitHub CLI 较小的默认上限悄悄遗漏未关闭议题：

gh issue list \
  --repo <owner>/<repo> \
  --state open \
  --limit 1000 \
  --json number,title,body,labels,author,createdAt,url

如果命令恰好返回 1,000 条议题，请说明结果可能已达到请求的上限，而不要声称这就是完整列表；可以提出继续使用分页 GitHub API 请求获取结果。

**本地 Markdown。**完整读取 Reading 部分中计为未关闭的每个意图文件。

**其他后端。**运行记录的方法并请求完整内容。如果工具会分页或限制结果数量，请说明结果停在何处，不要称其为完整结果。

对于所有后端：除非用户提出要求，否则不要添加标签、经办人、里程碑、搜索或作者筛选条件。如果获取失败，请报告错误并停止。不要将身份验证、授权、网络或目标缺失错误转换为空结果。

呈现结果

如果没有未关闭的议题，请说明这一点，并指出已检查的跟踪器和目标。

否则，报告返回的总数，并按以下格式呈现每个议题，其中 <reference> 使用跟踪器自身的标识形式——GitHub 上为 #<number>，Jira 上为 PROJ-123 这类键，本地 Markdown 上为文件路径：

## <reference> — <title>

- URL: <url or file path>
- Labels: <comma-separated labels, or None>
- Author: <login or name, or Unknown>
- Created: <creation time in an unambiguous date format, or Unknown>

### Body

<complete body, or _No body provided._>

完整保留每个议题正文。除非用户明确要求摘要，否则不要悄悄截断、用省略号替代或概述正文。如果完整结果无法放入一条回复中，只能在议题之间停止，说明已展示返回议题的数量，并在下一条回复中从下一条议题继续。

不要做的事

• 如果用户和跟踪器配置都未指定跟踪器或目标，不要猜测。
• 不要对非 GitHub 后端使用 GitHub 命令，也不要为 Reading 部分缺失的跟踪器编造命令。
• 不要依赖工具的默认分页大小或上限，并声称结果完整。
• 未经用户要求，不要省略、缩短或转述议题正文。
• 不要通过报告没有未关闭议题来掩盖命令失败。
• 不要创建、编辑、关闭、添加标签、指派或以其他方式更改议题；此技能为只读。