详解 Pollinations issue-maker 技能：按仓库约定创建 Issue，以及背后的自动分类机制

• AI 应用
• 媒体生成
• 后端
• 前端

issue-maker 是 Pollinations 仓库内置的一份"Agent 技能"约定，规定 AI 助手在为团队"记录工作"时应如何在 GitHub 上创建或更新 Issue。读完本篇，你将掌握：该技能的完整操作准则与团队 ownership 表、它在仓库中的存放位置与镜像机制，以及它与project_manager机器人、CI 触发器、Express 优先级作业之间的真实协作关系——即为什么技能里强调"不要替机器人加 Area/Type/Priority 标签"，这些字段最终由谁、按什么规则自动写入 Dev 项目。

一、issue-maker 技能是什么

issue-maker是一份 Claude Code / Codex 可直接加载的技能文件，采用标准的SKILL.md格式：头部为 YAML front-matter，正文为面向 Agent 的指令。其 front-matter 声明为：

--- name: issue-maker description: Create or update Pollinations GitHub issues when asked to track work, using current repository conventions. ---

也就是说，当用户要求"把这件事记成一个 Issue / 跟进某项工作"时，Agent 应调用本技能，遵循"当前仓库约定"（current repository conventions）来落地，而不是凭感觉随意写。

按根目录 AGENTS.md 的约定（"Maintain project skills in.claude/skills/… expose them to Codex through relative directory links in.agents/skills/"），技能的主维护副本放在 .claude/skills/issue-maker/SKILL.md，并通过相对目录链接暴露给 Codex 的镜像位置 .agents/skills/issue-maker/SKILL.md。两份内容保持一致，避免"复制一份工作流"造成的漂移。

技能正文是 5 条指令加一张团队 ownership 表。下面逐条继承并展开。

二、技能定义的五条核心准则

技能正文（.claude/skills/issue-maker/SKILL.md）原文以要点列表给出：

1. 使用pollinations/pollinations仓库；在创建重复项或复活过期工作之前，先检查相关的 open 与 closed 的 issues/PRs，包括最新讨论与关闭原因。
2. 用简短标题 + 至多 3 个具体要点描述当前问题或期望结果；关联相关工作；当 Issue 覆盖多个步骤时使用 checklist。area、type、priority 由 project manager 机器人设置（见operations/github/project-manager.md），不要为它们加标签。
3. 遵循用户的 assignee 偏好；否则使用下文团队 ownership 表，不确定时核对当前仓库上下文。根AGENTS.md定义了 app-submission 状态。
4. 返回 Issue 链接与简洁摘要；在被要求时使用 Discord 兼容的格式。
5. 仅做 Issue 的工作时，不要创建或修改任何本地文件。

下面按主题拆分，并结合仓库给出每条准则的落地依据。

2.1 固定仓库 + 创建前去重（准则 1）

技能明确要求落在pollinations/pollinations仓库。这一取值与分诊机器人代码中的常量一致——operations/github/project_manager.py 中REPO_OWNER = "pollinations"、REPO_NAME = "pollinations"，机器人对同一仓库的 Issue/PR 事件做响应。

"先去重"不是建议而是硬性要求：Agent 在动手创建前，必须先检索相关的已开与已关闭的 issues/PRs，并阅读最新讨论和关闭原因（close reason）。这与 AGENTS.md 中"Before reviving old work, check its discussion, close reason, and remaining user-visible gap; an absent feature alone is not evidence that it is needed"的告诫互为印证——单纯"某功能不存在"并不构成"需要它"的证据，避免把早已讨论过、甚至被主动关闭的工作重新开出来。

2.2 标题 + ≤3 个要点 + 关联链接 + checklist（准则 2）

Issue 正文的格式被限制得相当克制：一个短标题，至多 3 个具体（concrete）要点，并主动链接相关工作；当 Issue 需要分步骤完成时改用 checklist（勾选列表）。

这一风格与 AGENTS.md 的"Communication Style"一致：PRs/comments/issues: bullets, <200 words, no fluff，Issue comments: bullets only; facts not opinions; link code; be direct。换句话说，仓库整体推崇"要点化、事实导向、无营销废话"的沟通，issue-maker 只是把这套风格固化成 Agent 可执行的规则。

2.3 不要替机器人加 Area/Type/Priority 标签（准则 2 的后半句）

技能特别强调：area、type、priority 由 project manager 机器人设置，不要为它们添加标签。这条准则是整个技能的"分工边界"，其依据见 AGENTS.md 的"GitHub Project Manager"一节：

A bot sets the Dev project Area on every new issue and PR, plus the issue type and Priority on issues, followingoperations/github/project-manager.md. … Labels are only for workflows (APP-*,BEE-CENSUS,HONEY-CENSUS,POLLI,NEWS,POLLEN-QUEST/DRAFT-QUEST,VOTING,MERGE-HOLD) and goals (REVENUE); don't repurpose them or create new labels ad hoc.

也就是说，标签（labels）在 Pollinations 里只服务于工作流和目标两类用途（如APP-SUBMISSION、POLLEN-QUEST、VOTING、MERGE-HOLD、REVENUE），而"这个工作属于哪个领域/是什么类型/多紧急"这三个维度由机器人写到Dev 项目的结构化字段里，而不是写成标签。若人为去加这类标签，会污染工作流标签的语义、也与机器人的字段写入产生冲突。这一机制的完整规则见下文"幕后机制"。

2.4 Assignee 偏好 + 团队 ownership 表 + app-submission 状态（准则 3）

指派规则分三级：

1. 优先遵循用户明确表达的 assignee 偏好；
2. 否则按下文的团队 ownership 表选人；
3. 拿不准时，核对当前仓库上下文（例如改动落在哪个目录、哪个服务），再决定归属。

技能同时点明：app-submission 的状态机由根AGENTS.md定义。见 AGENTS.md 的"App Submission Handling"：APP-SUBMISSION是持久类型标签，APP-NEEDS-INFO、APP-REVIEW、APP-APPROVED描述评审状态，由apps-review-submissions.yml与apps-publish-submissions.yml驱动，目录真源是operations/app-management/app.json。因此 Agent 在为"提交一个应用"这类工作建 Issue 时，不应自创标签，而应沿用这套既定状态。

2.5 返回链接与摘要 + Discord 兼容格式（准则 4）

技能要求 Agent 完成后返回 Issue 链接 + 一段简洁摘要，并且在被要求时输出"Discord 兼容的格式"。这与仓库存在 Discord 协作面（根AGENTS.md给出 Guild 用途）相契合——许多"记录工作"的请求本身就来自 Discord 场景，回复格式需要能被 Discord 正确渲染（如 markdown 链接、要点列表）。

2.6 只记录、不落地本地文件（准则 5）

"仅做 Issue 的工作时，不要创建或修改任何本地文件"是一条安全护栏：Agent 的职责是把工作登记到 GitHub，而不是在仓库里顺手生成.md或脚本。这一点与 AGENTS.md 中"Don't create.mddocs unless asked"的总体纪律一致，避免"为了记一件事而在仓库里留下杂物"。

三、团队 ownership 表

技能内置了一张三行 ownership 表，作为"用户没有指定 assignee"时的默认指派依据（原样继承自 .claude/skills/issue-maker/SKILL.md）：

使用方式：先尊重用户偏好；没有偏好时，按"这件事主要落在谁的领域"来指派。例如一条关于模型注册表 / GPU 基础设施的 Issue 倾向 Thomas，一条关于 Pollen 计费 / 后端 / 鉴权的 Issue 倾向 Joshua，一条关于社区目录 / 通讯 / 界面的 Issue 倾向 Elliot。技能还提醒：当改动边界模糊时，"checking current repository context when uncertain"——即回到"这段工作主要改哪些目录/服务"来判断，这与下文 project manager 的"按主要用途选领域"思路同源。

四、幕后机制：Project Manager 机器人如何自动分类

技能把 area/type/priority 的写入交给机器人，下面用仓库源码说明这条"自动分诊管线"的真实构成，帮助理解技能准则为何如此设计。

4.1 单一事实来源：project-manager.md分类简报

operations/github/project-manager.md 是"工作如何被组织"的唯一权威定义，机器人与团队都读同一份文件。其要点：

• Area：从 15 个领域里选一个（Models、Community models、Agents & agent tools、Developer tools、Accounts & keys、Billing & payments、Quests & rewards、Dashboard、API & reliability、CI & releases、Internal automation、Brand & news、Docs & support、App catalog & showcase、Data & insights）。
• Type：Bug/Feature/Task；Question仅用于 Issue；PR 用"Work type"（Bug/Feature/Task）。
• Priority（仅 Issue）：High/Medium/Low。简报明确"按今天对用户造成的伤害定级，而非需求价值或谁提的；Express由另一个作业稍后搬运，机器人自己永不选 Express"。
• Area rules：按"工作主要服务于哪个领域"判断；PR 按"合并后代码做什么、改了哪些文件"而非标题前缀判断；quest 工作归其工作本身所属的领域，POLLEN-QUEST本身不是归入"Quests & rewards"的理由；只 promote/sync/deploymain→production的 PR 以及 census 问卷作答，返回null（不进分类）。
• Answer：只返回 JSON，形如{"area": "Models", "type": "Bug", "priority": "High", "reasoning": "one short sentence"}；area为null时type、priority均为null。

简报里每个领域都写清了"什么属于这里 / 什么不属于这里"（如"模型定价→Models；计费错误→Billing & payments"），让分类有可核对的边界。

4.2 实现：project_manager.py的执行链

operations/github/project_manager.py 把上述简报落成可运行逻辑。关键事实（含源码定位）：

• 输入来自 GitHub 事件：GITHUB_EVENT解析出pull_request或issue，取出number、title、body、作者、node_id等（见 operations/github/project_manager.py）。
• AI 分类：ask_ai()调用 Pollinations 自身的 chat completions 端点，模型为openai/gpt-6-luna，强制response_format: json_object，对传输/解析错误做最多 3 次指数退避重试（见 operations/github/project_manager.py；端点与模型常量在 L40-L41）。
• PR 的额外事实：classify()会拉取 PR 改动文件（最多列 300 个）与"被关闭关联 Issue 的类型"作为提示，喂给分类器，并要求"以 PR 实际范围为最终依据"（见 operations/github/project_manager.py）。
• 字段校验：classification_answer()校验area必须属于简报中的领域名、type属于允许集、priority属于允许集，非法即ValueError；area为null时type/priority归零（见 operations/github/project_manager.py）。
• 写入 Dev 项目：通过 GitHub GraphQL 先addProjectV2ItemById加入 Dev 项目（DEV_PROJECT_ID = "PVT_kwDOBS76fs4AwCAM"），再逐个updateProjectV2ItemFieldValue设置Area/Source/Priority/Work type；None值走clearProjectV2ItemFieldValue（见 operations/github/project_manager.py）。
• 字段必须与简报一致：dev_fields()拉取 Dev 项目的单选字段选项，并逐一对齐简报里的Area/Priority/Source（PR 再加Work type），发现缺项就fail()退出——从机制上保证"代码里的领域清单"与"Dev 项目的领域选项"不漂移（见 operations/github/project_manager.py）。
• Source 维度：item_source()按"恰好一个来源"的优先级判定——先APP-SUBMISSION→Apps、POLLEN-QUEST→Quests（含 PR 关联的 Issue 标签），否则按作者：团队账号（TEAM_IDS）→Team、Bot 账号→Agent、其余→Community；被 Discord relay 代发（正文以**Author:** … (UID: …)结尾）的不算 Agent（见 operations/github/project_manager.py）。
• 保留人工优先级：current_priority()会读该 Issue 在 Dev 项目上已有的 Priority，若已被人工/早先运行/Express 作业设置，则不覆盖（见 operations/github/project_manager.py 与 L394-L396）。
• APP-SUBMISSION特例：带该标签的 Issue 直接判为App catalog & showcase，不再走 AI（见 operations/github/project_manager.py）。
• DRY_RUN：DRY_RUN=1时只打印将发生的变更、不写 GitHub，用于人工派发的安全预演（见 operations/github/project_manager.py 与 L379-L397）。
• 联动下游：若设置了CLASSIFICATION_OUTPUT，主流程结束前会把{area, type, source}写成 JSON 供"gist 管线"复用同一份分类结果（见 operations/github/project_manager.py）。

4.3 触发与编排：repo-organize-issues-prs.yml

分类不是常驻进程，而是由 CI 触发。.github/workflows/repo-organize-issues-prs.yml 的要点：

• 事件：issues: opened / labeled、pull_request_target: opened；其中labeled仅在新增APP-SUBMISSION或POLLEN-QUEST时才处理（因为标签只会改变Source）。
• 幂等：concurrency.group: project-manager-<number>、cancel-in-progress: false，避免同一工作项并发写入。
• 凭据：用actions/create-github-app-token为pollinationsowner 临时签发 App Token，作为GITHUB_TOKEN；另注入POLLINATIONS_TOKEN（PLN_GITHUB_POLLY_KEY）。
• 常规路径：python operations/github/project_manager.py（见 workflow）。
• 回填路径（workflow_dispatch）：可输入pr_numbers/issue_numbers（空格分隔；都不填则默认全部 open PR），逐个用gh api组出GITHUB_EVENT再调用同一脚本，dry_run默认开，便于批量"重分类存量"（覆盖 Area/Source/类型、仅在为空时填 Priority）（见 workflow）。

4.4 Express 优先级：express_priority.py

分类给出的 Priority 只有 High/Medium/Low；Express由独立的 operations/github/express_priority.py 稍后搬运。它每 30 分钟（cron*/30 * * * *）运行一次（见 .github/workflows/repo-express-priority.yml），逻辑（见 operations/github/express_priority.py）：

• 从 Tinybirdpaid_customers取"付费客户"的 GitHub ID；
• 只处理近SINCE_HOURS（默认 2）小时内新建、Source == "Community"、且已有 Priority（非空、非 Express）的 Issue；
• 命中者把 Dev 项目上的 Priority 提升到Express；团队自建、census 作答、app submission 一律不动。

这正是简报里"Express由另一个作业搬运、机器人自己永不选 Express"的具体实现，也是 4.2 中"已设置优先级不覆盖"的下游受益者。

4.5 测试佐证：test_project_manager.py

operations/github/test_project_manager.py 用单元测试固化了分类的边界行为，可作为"实现事实"的交叉验证：

• PR 的type不允许带 issue 的 Priority（test_pr_type_has_no_issue_priority）；
• Issue 的Question类型与 Priority 仍受支持（test_native_issue_question_and_priority_remain_supported）；
• area为None的工作不产生 type/priority（test_unclassified_work_does_not_get_type_or_priority）；
• 关联 Issue 的类型确实进入分类器 prompt，且包含改动文件与"hints, verify against PR scope"字样（test_linked_issue_type_reaches_classifier_prompt）；
• promote/sync 类 PR（area=None）会把已有Work type清空、且不调用原生set_issue_type（test_promotion_pr_clears_existing_work_type_through_main）；
• 拉取关联 Issue 失败时closing_issues()会失败且不被缓存（test_missing_linked_issue_node_fails_and_is_not_cached）。

五、与根 AGENTS.md 的约定衔接

issue-maker 的几条准则其实都是根 AGENTS.md 更宽约的"可执行投影"，理解这些衔接能避免 Agent 犯错：

• app-submission 状态机：技能说"根AGENTS.md定义 app-submission 状态"，即 AGENTS.md 中APP-SUBMISSION（持久类型标签）→APP-NEEDS-INFO/APP-REVIEW（评审状态）→APP-APPROVED（维护者加）的两阶段评审，真源为operations/app-management/app.json，由apps-review-submissions.yml与apps-publish-submissions.yml驱动。技能准则 2.3 里的"不拿不准就查仓库上下文"在此即指向该状态机。
• 标签纪律：技能"不要为 area/type/priority 加标签"与 AGENTS.md "Labels are only for workflows … and goals (REVENUE); don't repurpose them or create new labels ad hoc" 完全对应——标签是工作流/目标专用，分类维度走 Dev 项目字段。
• 沟通风格：技能的"短标题 + ≤3 要点 + 链接相关 + 直接返回摘要"对应 AGENTS.md 的 Communication Style（要点化、<200 词、事实非观点、链接代码、直接）。
• 贡献归属：与 Issue 关联的 PR 用Fixes #issue/Addresses #issue，社区贡献用Co-authored-by: {username} <{user_id}+{username}@users.noreply.github.com>（数字 user ID 来自 issue API）；由访问请求 Issue 触发的 publisher-allowlist PR，还要把请求者加为Co-authored-by（见 AGENTS.md 的"Contributor Attribution"）。

六、适用边界与小结

适用前提：本技能面向pollinations/pollinations仓库的 Issue/PR 工作记录；其"自动分类"依赖仓库内已部署的project_manager.py+ Dev 项目（PVT_kwDOBS76fs4AwCAM）+ 相关 CI。若你只是"登记一件事"，技能只要求你去重、按格式建 Issue、按 ownership 表指派、返回链接，并不要落地本地文件、不要替机器人加分类标签。

一句话总结：issue-maker 把"如何写一条合规的 Issue"收敛成 5 条可执行准则 + 一张 ownership 表，而"分类归谁管"的问题则交给project-manager.md单一事实来源与project_manager.py机器人、repo-organize-issues-prs.yml触发器、express_priority.py提升作业这条自动化管线——技能负责"正确地记录"，机器人负责"正确地归档"，两者边界清晰、互为依据。

• AI 应用
• 媒体生成
• 后端
• 前端