用途：在改动可用之后、任何人打开 GitHub PR 之前，为 plastic-labs/honcho 的变更准备 PR 正文。输出是填好的模板正文，不创建 PR。模板位于 .github/pull_request_template.md，不要添加额外章节。
主要能力与流程：
- Issue 门禁（硬性停止）：PR 必须关联维护者批准的 issue，否则会被关闭。用 gh issue view <N> --repo plastic-labs/honcho --json number,title,labels,state 检查。若没有 issue 编号、issue 不在该仓库、issue 已关闭（除非本 PR 明确重开）、标签不含 maintainer-approved，则停止并说明哪项检查失败，不要围绕它起草正文。若尚无 issue，按 Filing an issue 提交并等待 maintainer-approved。
- 分类 diff：用 git diff main...HEAD --stat，先选一个主要类型（bug、feature、docs），再确定层级。涉及 src/（非 prompt）需匹配 tests/ 下的单元测试；涉及 deriver / dialectic / dreamer / LLM 路径需单元测试并考虑 live-llm（tests/live_llm）；涉及 queue、config 层级、多轮、SDK 契约需 unified（uv run python -m tests.unified.run）；涉及 /v3 HTTP 或 deriver 队列行为需 /verify 技能（运行时，而非仅 pytest）；涉及公共 API、SDK 导出、config.toml / settings、mintlify docs/ 需在对应文件补文档。跳过某层需给一行理由（如 docs-only、comment-only），“when appropriate” 不算理由。运行时表面变动时调用 /verify。声称测试通过前先跑：uv run ruff check src/ → uv run basedpyright → 对应层级的 pytest 命令。
- 证据：收集属于 PR 而非 commit 的证据，包括所运行命令及通过/失败结果、展示新行为的日志片段/截图/文件路径；bug 类尽量给出修复前后的失败用例。若运行了 /verify，证据即该会话输出，不要编造绿色运行。
- 写正文：填写 PR 描述模板中的 description、proofs、checklist 部分，并务必链接相关 GitHub issue，否则 PR 会被自动关闭。
适用场景：在打开 PR 前、起草 PR 正文时、被问分支是否 PR-ready 时调用。
限制：不创建 PR；不添加模板外章节；issue 未获 maintainer-approved 时不得继续起草正文；不得虚构测试通过结果。