file-pr 是一个用于提交拉取请求（PR）的技能，来源于 t3dotgg/tstack。它的核心用途是帮助用户在需要提交、打开或创建 PR 时，生成一个简洁且符合规范的拉取请求。
主要能力与使用方式：
提交前检查：在提交 PR 之前，先检查当前分支是否已经存在对应的 PR，避免重复提交。同时，在本地对照基础分支（通常为 origin/main）审查 diff，确认改动内容与既定目标一致。
标题规范：PR 标题通常会成为提交信息，因此需要遵循仓库的标题约定。可以查看近期已合并的 PR 和 Git 历史作为参考。标题应简洁、可读，并解释改动为何重要，而不是单纯描述实现细节。例如，不推荐“perf(server): negotiate permessage-deflate on the websocket”，推荐“perf(server): cut websocket frame size by 70%+ with gzipping”。
描述写法：描述开头应基于用户的原始提示，简单说明问题所在，然后简要说明解决方案。不要以实现清单开头。例如，不推荐罗列删除的函数和机制，推荐以用户视角说明“我的 new worktree 默认设置在已有 worktree 上启动新线程时被忽略，非常不直观，现在你的偏好始终生效”。描述结尾需要注明生成改动的公开模型名称和运行环境（harness），格式如“Created with <model> in <harness>”。如果改动由子代理模型完成，也应包含子代理模型。使用 harness 报告的模型名称；如果模型身份不可用，则只写 harness，不要猜测模型。
安全检查：提交前检查标题、描述、引用和附件中是否包含密钥或隐私细节。
提交方式：打开真实 PR 而非草稿，以便审查机器人运行。如果 gh pr create 因 GraphQL 速率限制耗尽而失败，可以通过 REST 方式创建，命令为 gh api repos/<owner>/<repo>/pulls -f title=... -f head=... -f base=... -F body=@<file>。
后续处理：如果用户还要求照看该 PR，则继续使用 babysit-pr 技能。除非符合用户请求，否则不要发布后续 PR 评论；需要评论时，使用 leaving-pr-comments 技能。
适用场景：适用于需要提交、打开或创建拉取请求的软件开发协作流程，尤其是希望 PR 标题和描述简洁、规范、可读的场景。
限制：资料未提供关于收费、价格、平台支持范围、具体效果或额外使用步骤的信息，这些内容暂未提供。