okffs

okffs

将与 Claude 的对话转化为 GitHub issue、分支和拉取请求——全程无需离开 Claude Code。

okffs 是一个 Model Context Protocol 服务，可为 Claude Code 提供简洁的 GitHub issue → 分支 → PR → 关闭工作流。用通俗的语言讨论工作内容；okffs 会一次性创建 issue、对应的分支和拉取请求，将它们相互关联，并（可选）同步 GitHub Projects 看板。

• 一次性规划——描述一项工作，即可创建所有 issue 和分支，并设置好关联关系。
• 完整工作闭环——创建、评论、提交、发起 PR、处理审核反馈并关闭，每项操作都只需简单提出要求。
• 合理的默认值——Claude 会根据任务推断标签、优先级和工作量；GitHub 始终是唯一可信来源。
• 几乎无需配置——已在仓库中通过 gh CLI 登录？即可开始使用。

快速开始

1. 在项目根目录运行设置向导：

npx @neturely/okffs setup

向导会引导你完成身份验证、仓库和任何可选功能的设置，写入 .env，然后快速检查 GitHub 状态。随时可以重新运行（例如升级 okffs 后）——它只会询问自上次运行以来新增的选项。如果你愿意使用 GitHub CLI（gh auth login），并在要管理的仓库中操作，则可以完全跳过此步骤——okffs 无需任何配置即可运行。

已经在使用 Claude Code？ 连接 okffs 后，你也可以通过对话进行配置——运行斜杠命令 /okffs:setup，Claude 会询问所需信息并为你写入 .env（无需使用终端）。升级后如果新增了选项，okffs 也会提醒你运行该命令。

2. 在项目根目录添加 .mcp.json：

{
  "mcpServers": {
    "okffs": {
      "command": "npx",
      "args": ["@neturely/okffs@latest"]
    }
  }
}

就是这样——首次使用时，npx 会获取 okffs，Claude Code 会自动加载这些工具。如果要使用令牌或其他仓库，而不是采用 gh/自动检测的默认设置，请运行 okffs setup（见上文）或手动编辑 .env——参见配置。

现在只需向 Claude 提出要求：

• “创建一个名为‘修复登录按钮’的 issue，并为它创建分支。”
• “规划添加用户身份验证的工作，并创建相应的 issue。”
• “根据这份任务列表创建 issue：……”
• “列出所有未关闭的 issue。”
• “将 issue #5 标记为被 issue #3 阻塞。”
• “issue #42 已完成——发起 PR 并关闭它。”
• “处理 PR #42 上的审核评论。”

Claude 会根据标题和描述推断标签（bug、enhancement 等），并与设置为默认值的标签合并。

工具

工具	功能
create_issue	创建一个议题及对应分支（Epic 不会创建分支或草稿 PR——工作会落在其子议题上）。根据任务推断标签、看板 priority/effort 和原生 Issue Type（使用 OKFFS_INFER_PRIORITY/OKFFS_INFER_EFFORT/OKFFS_INFER_TYPE 切换）。可选参数：assignees、labels、milestone、priority、effort、type。当 OKFFS_AUTO_PR=true 时立即打开草稿 PR。
create_issues_from_list	一次性根据任务列表创建多个议题和分支。会先确认。每项任务可设置 labels、assignees、milestone、priority、effort、type。
plan	提供自由文本描述和 Claude 生成的拆解（标题、描述、标签、priority/effort/type、关系）；它会创建所有议题和分支、关联各项关系，并在 OKFFS_AUTO_PR=true 时打开草稿 PR。会先确认。
list_issues	列出未关闭的议题及其分支、关联 PR、看板列、priority:/effort:、原生 type: 和树状关系——按优先级排序，让最重要的工作排在最前面。
get_issue	获取单个议题的完整详情：标题、正文、标签、受指派人、分支和状态。
comment_issue	发布评论——便于记录分支完成的工作。
link_issues	关联两个议题（blocked_by、blocking、parent），并将关联关系存储在 ## Relationships 部分中。
close_issue	关闭一个议题，并提示你在处理下一个议题前运行 /clear。
create_pull_request	为议题分支打开 PR——生成标题和正文、推送分支、始终包含 Closes #N，并发布评论。OKFFS_UPDATE_DOCS=true 时可写入变更日志片段。传入 allow_empty: true，可在没有提交的分支上补建一个用于跟踪的草稿 PR（会推送一个空的初始提交，使分支产生差异）。
commit_and_update	暂存已跟踪的更改（未跟踪文件需设置 include_untracked: true），创建提交（原样使用你的 message，或自动生成提交信息）、推送，并在议题中发布进度评论。会拒绝处理看起来像包含密钥的文件。
merge_pull_request	使用 OKFFS_BASE_MERGE_METHOD，自动将检查通过且评审已解决的议题 PR 合并到基础分支（例如 develop），然后关闭议题。需主动启用（OKFFS_AUTO_MERGE_BASE=true），并设有严格限制——绝不会触碰 OKFFS_PROTECTED_BRANCH，且会独立验证检查、可合并性和讨论线程。
fix_into_base	打开一个不关联议题的修复 PR，并在满足相同的 OKFFS_AUTO_MERGE_BASE 条件时将其合并到基础分支——适用于修复评审评论等小型清理工作。绝不会将目标设为 OKFFS_PROTECTED_BRANCH。
promote_branch	打开不关联议题的晋级 PR（例如 develop → main）、将其加入看板、可选择请求评审者，并列出该 PR 所包含的各应用发布版本。再次运行时会报告尚未解决的评审讨论线程，并在你主动启用后合并门禁 PR（OKFFS_AUTO_MERGE_PROTECTED）及标记已合并的发布版本（OKFFS_TAG_RELEASE）。参见发布和晋级门禁。
list_pr_review_comments	获取 PR 的行内评审讨论线程和摘要。
reply_to_review_comment	根据 ID 回复行内评审讨论线程。
resolve_review_thread	解决评审讨论线程——仅当 OKFFS_RESOLVE_THREADS=true 时执行。
prepare_release	升级版本号（使用 package.json；如果不存在，则使用普通 VERSION 文件，该文件会在首次发布时创建）、滚动更新 CHANGELOG、在发布分支上创建提交，并打开 PR。会先确认；不会标记版本或发布。适用于 multisite 中的各个应用。
update_project_status	在看板列（Backlog、Ready、In Progress、Review）之间移动议题。需要启用 OKFFS_PROJECT_ENABLED。
set_issue_fields	为现有议题设置看板 Priority/Effort 和／或原生 Issue Type。Priority/Effort 支持项目原生和组织级 Issue Fields（需要启用 OKFFS_PROJECT_ENABLED）；type 是组织原生字段，可独立使用。create_issue 仅在创建时设置这些字段；之后可使用此工具。状态仍由 update_project_status 管理。
update_issue	通过一次 PATCH 使用已配置的令牌编辑现有议题的核心字段——title、assignees、labels、milestone、body。labels/assignees 会替换整个集合（[] 表示清空）。Priority/Effort/Type 请使用 set_issue_fields；状态请使用 update_project_status。
configure	将 okffs 配置写入 .env——这是 /okffs:setup 提示词的后端。复用 okffs setup 向导的清单／序列化器：仅更新 okffs 标记的区块，并保留你自己的变量和注释。设置 app: "finance" 则改为写入 finance/.env；同时确保 .gitignore 会忽略任意目录层级的 .env。通常由 /okffs:setup 驱动，不会直接调用。
delete_issue	关闭议题并删除其分支。此操作具有破坏性——需要设置 confirmed: true。
delete_branch	删除分支并关闭其议题。此操作具有破坏性——需要设置 confirmed: true。
破坏性工具（delete_issue、delete_branch）在首次调用时始终会发出警告，只有再次调用并设置 confirmed: true 才会执行操作；执行任何操作前，会先在 issue 中发布评论。

处理 PR 评审

okffs 内置了处理评审反馈的循环流程——只需提出请求（“处理 PR #42 上的评审意见”）。Claude 会读取讨论串、修复有效的问题、提交并推送更改、逐个回复讨论串，并发布摘要。Claude 负责判断和修复；okffs 负责处理 GitHub 流程。此外，还有一个斜杠命令 /okffs:address_pr_review（接受 PR 编号），可运行相同的流程。

默认情况下，评审讨论串会保持开放，供你处理；设置 OKFFS_RESOLVE_THREADS=true 后，okffs 会在处理完后解决这些讨论串。

自动驾驶（最低干预）

如需免手动操作的会话，请让 Claude “全权处理”（或说 “最低干预”）——也可以设置 OKFFS_AUTOPILOT=true 将其设为默认模式。在自动驾驶模式下，对于可逆决策，Claude 不再询问你要选择哪个选项，而是在每个分岔点都采用推荐选项，并将 issue 一路推进到针对基础分支的 PR（当 OKFFS_AUTO_MERGE_BASE=true 时，还会合并到基础分支）——随后在 PR 和 issue 中发布一份**“自动驾驶决策”**报告（每项选择占一行，并附上一句理由），方便你通过一条消息调整任何决定。

此模式消除的是确认环节，不会赋予新权限。即使在自动驾驶模式下，硬性停止条件也始终生效：破坏性工具（delete_issue / delete_branch），以及任何涉及 OKFFS_PROTECTED_BRANCH 的操作（合并、打标签、发布）、计费操作，或你未主动选择启用的不可逆操作。明确的环境变量授权即为同意，之后不会再次询问：OKFFS_PROMOTION_AUTO_REVIEW（Copilot 评审由你自行决定是否使用 GitHub 计费），OKFFS_AUTO_MERGE_PROTECTED、OKFFS_TAG_RELEASE。正确性停止条件——检查失败、评审待处理、讨论串未解决、分支指针已移动——绝不会被标志覆盖。对于真正的缺少信息的情况——只有你掌握相关背景——Claude 仍会快速询问一个问题，而不是猜测。此功能默认关闭。

发布与晋级门控

prepare_release 会在 release/X.Y.Z 分支上更新版本号并整理变更日志，然后将其合并到基础分支。接着，promote_branch 会创建不关联 issue 的晋级 PR（例如 develop → main），将其加入看板，可选地请求 Copilot 等评审者，并列出此次晋级包含的发布版本。从这里开始，后续每一步都由你决定，或通过明确授权启用：

步骤	手动操作（默认）	主动选择启用
评审反馈	重新运行 promote_branch 查看未解决的讨论串；通过 /okffs:address_pr_review + fix_into_base 修复。	—
合并门控 PR	在 GitHub 上手动合并。	OKFFS_AUTO_MERGE_PROTECTED=true — 重新运行后，所有门控条件均通过时（检查全绿、评审已完成、讨论串已解决）即会合并。
为发布打标签	推送标签（v0.13.0，或按应用使用 finance-1.3.0）。	OKFFS_TAG_RELEASE=true — 合并后重新运行时，会在合并提交上为发布版本打标签。

启用这两个标志后，流程为：promote_branch → 评审完成 → 处理评审意见 → 重新运行 promote_branch，完成合并并打标签。如果检查失败、请求的评审尚未完成、讨论串仍未解决，或目标分支已推进到合并提交之后，okffs 仍会拒绝操作，并告知原因。打标签通常会触发 CI 发布，而发布无法撤销——请谨慎启用这些选项。

保持 CLAUDE.md 同步

斜杠命令 /okffs:update_guidance 会审查当前分支上的更改，并维护 CLAUDE.md 中由 okffs 管理的一个部分——## Project Guidance (okffs usage)，该部分由 HTML 标记界定——且绝不会改动你手写的内容。这是对使用指南（工具、环境变量、约定）的整理，不是变更日志。设置 OKFFS_UPDATE_GUIDANCE=true 后，create_pull_request 会在创建 PR 时提醒 Claude 运行此命令；该命令始终可用。

自动更新文档

设置 OKFFS_UPDATE_DOCS=true 后，create_pull_request 会将文档更新写入分支，使其显示在 PR 差异中：

• CHANGELOG.md — 为每个问题创建符合 Keep a Changelog 规范的 变更片段，存放于 .changes/unreleased/，并由 prepare_release 在发布时汇总到 CHANGELOG.md。使用唯一命名的片段可避免并行分支之间发生合并冲突。
• SECURITY.md — 检测到与安全相关的关键词时更新（仅当文件存在时）。

CLAUDE.md、CONTRIBUTING.md 和 README.md 有意留给你自行维护。使用 OKFFS_EXCLUDE_DOCS 按仓库排除特定文件（有效值：CHANGELOG.md、SECURITY.md）。

GitHub Projects v2

okffs 可以让 Projects v2 看板与工作流保持同步。此功能需主动启用；关闭时不会产生额外开销：

OKFFS_PROJECT_ENABLED=true
OKFFS_PROJECT_ID=PVT_kwHO...     # the board's GraphQL node ID

启用后，list_issues 会显示每个问题所在的列、优先级和工作量（按优先级排序）；update_project_status 会在 Backlog、Ready、In Progress 和 Review 之间移动问题；create_issue 则可以设置优先级、工作量和初始列。Done 有意交由 GitHub 的原生自动化处理（PR 合并 / 问题关闭 → Done），以避免两个系统争夺最终状态。

优先级和工作量既可以使用项目原生的单选字段（任何支持 Projects 的令牌），也可以使用 GitHub 组织级 Issue Field。组织级 Issue Field 位于项目之外，需要使用带有 admin:org 权限的 classic PAT，并设置 OKFFS_CLASSIC_PAT=true——目前细粒度 PAT 无法访问这些字段，因此 okffs 会跳过此方式，并提示你在 UI 中设置值。默认情况下，Claude 会为每项任务推断优先级和工作量；无法推断时则回退到 OKFFS_DEFAULT_* 值。

自动添加（OKFFS_PROJECT_AUTO_ADD）是针对未使用 GitHub 原生“Auto-add to project”工作流的看板的备用方案——如果你的看板已启用自动添加，请保持其值为 false。

令牌权限： Projects v2 仅支持 GraphQL，需要使用支持 Projects 的令牌——具有 Organization → Projects: Read and write 权限的细粒度 PAT，或具有 project 范围的 classic PAT。一个同时具有 repo、project 和 admin:org 权限的 classic token 即可满足所有需求，包括组织级 Issue Field。缺少权限时会显示明确的 [okffs] 错误，指出所需权限。

多站点（一个仓库中的多个应用）

一个仓库可以托管多个应用，例如 finance/ 和 health/。它们共用议题跟踪器、看板、分支和令牌，但需要各自独立的版本、变更日志、片段、标签和发布线。okffs 将此称为多站点。默认关闭，需自行配置；单应用的扁平仓库行为与以前完全相同。

repo/
├── .env            # shared: token, board, branches, merge methods, OKFFS_APPS=finance,health
├── finance/
│   ├── .env        # OKFFS_APP=finance  (inherits ../.env — a value here wins)
│   ├── package.json  or  VERSION
│   ├── CHANGELOG.md
│   └── .changes/unreleased/
└── health/
    └── …

• 每个应用目录都有自己的 .env，用于指定应用（OKFFS_APP）。它会继承 Git 根目录的 .env，因此共享值只需设置一次。在应用目录中启动 Claude Code（或 okffs），并在该目录中放置 .mcp.json，或在用户级别注册 okffs，该会话就会作为对应的应用运行。
• 根目录 .env 中的 OKFFS_APPS 是应用注册表，用于验证应用名称、触发迁移警告，并让 promote_branch 指定每个应用的发布。
• 激活应用后：标签格式为 {app}-X.Y.Z（不带 v），发布分支为 release/{app}-X.Y.Z；应用名称始终是一个议题标签和默认分支标识符（42-finance-add-budget-view）；变更日志、片段和版本文件都位于应用目录下。create_issue / plan / create_issues_from_list 支持按调用覆盖 app；list_issues 会显示每个议题的 app:。
• 版本管理：如果应用有 package.json，则使用该文件；否则使用普通的 VERSION 文件，该文件会由 prepare_release 在应用首次发布时创建。
• 将根目录作为应用：也在根目录的 .env 中设置 OKFFS_APP。如果不设置，根目录会话将继续使用普通的 v 标签和根目录变更日志。
• 设置：在根目录运行 okffs setup，会询问 OKFFS_APPS，并可选择为每个应用写入 .env；在应用目录中运行，则只配置该应用。两种方式都会确保 .gitignore 忽略所有层级的 .env——带锚点的 /.env 会导致 finance/.env 可以被提交。

迁移现有仓库。 仅在启用多站点时需要迁移。将每个应用的变更日志、.changes/unreleased/ 片段和版本文件移至对应目录；okffs 启动时会针对以下情况发出警告：有待处理的根目录片段无法由任何应用的发布组装、OKFFS_APP 未包含在 OKFFS_APPS 中，以及已配置注册表但未设置 OKFFS_APP 的根目录会话。现有的 vX.Y.Z 标签保持不变；应用首次发布时会链接其标签，而不是比较范围。单站点用户无需进行任何操作。

配置

配置 okffs 最快捷的方式是使用向导——npx @neturely/okffs setup——它会为你写入并维护下文所述的 .env。本节其余内容介绍向导（或你手动操作）可以设置的项目。

okffs 会通过回退机制解析令牌和目标仓库，因此大多数用户无需进行太多配置。

令牌（采用第一个匹配项）：

1. .env 文件中的 GITHUB_TOKEN——可以是 细粒度 PAT（推荐，权限最小化），并在该仓库上拥有 Issues、Contents、Pull requests（读写）、Metadata（读取）和 Administration（读写）权限；也可以是带有 repo 作用域的经典 PAT（权限更广，可访问你的所有仓库）。
2. 否则使用 GitHub CLI 令牌——如果你运行过 gh auth login，即可直接使用。

仓库（采用第一个匹配项）：

1. .env 中的 GITHUB_OWNER / GITHUB_REPO。
2. 否则，从 okffs 运行所在目录的 origin Git 远程地址中自动检测。

okffs 会自动从该目录加载 .env，无需使用 --env-file 标志。最简的显式 .env：

GITHUB_TOKEN=ghp_your_token_here
# Optional — auto-detected from the git origin remote when omitted:
GITHUB_OWNER=your-github-username
GITHUB_REPO=your-repo-name

可选设置

所有项目均为可选；除非另有说明，否则默认不设置。按用途分组——同样的分组也出现在 .env.example 中，可复制用作模板。（GITHUB_TOKEN / GITHUB_OWNER / GITHUB_REPO 已在上文的设置部分介绍。）

分支与拉取请求

变量	默认值	用途
OKFFS_BASE_BRANCH	仓库默认值	创建新的 Issue 分支时所基于的分支。
OKFFS_PROTECTED_BRANCH	—	okffs 不会自主向其合并、打标签或发布的分支（例如 main），除非你通过 OKFFS_AUTO_MERGE_PROTECTED / OKFFS_TAG_RELEASE 选择启用。此项管控的是合并，而非 PR 创建：okffs 可以自由地创建以该分支为目标的 PR（创建是安全的——合并已由分支保护和你的手动合并把关），并只会提醒你自行处理合并和打标签。
OKFFS_IDENTIFIER	—	分支名称前缀：{number}-{identifier}-{slug}。
OKFFS_AUTO_PR	false	创建新的 Issue 分支时，创建一个草稿 PR。
OKFFS_BASE_MERGE_METHOD / OKFFS_PROTECTED_MERGE_METHOD	squash / merge	按分支层级指定 PR 合并方式（squash/merge/rebase）。仅记录约定，不授予合并权限。
OKFFS_AUTO_MERGE_BASE	false	允许 merge_pull_request 自主将检查通过且讨论串已解决的 Issue PR 合并到基础分支。绝不会合并到 OKFFS_PROTECTED_BRANCH。

Issue 默认值与推断

变量	默认值	用途
OKFFS_DEFAULT_ASSIGNEES	—	分配给每个新 Issue 的用户名，使用逗号分隔。
OKFFS_DEFAULT_LABELS	—	与推断出的标签合并的标签，使用逗号分隔。
OKFFS_DEFAULT_PRIORITY / OKFFS_DEFAULT_EFFORT	—	未推断或未提供时，作为看板 Priority/Effort 的后备值。
OKFFS_INFER_PRIORITY / OKFFS_INFER_EFFORT	true	允许 Claude 根据任务推断优先级/工作量。
OKFFS_INFER_TYPE	true	允许 Claude 根据任务推断原生 GitHub Issue Type（Task/Bug/Feature/…）。适用于组织级别；在用户仓库中会自动跳过。
OKFFS_DEFAULT_TYPE	—	未推断或未提供时，作为原生 Issue Type 的后备值（例如 Task）。
OKFFS_PROMPT_METADATA	true	设为 false 可隐藏分配对象/标签提示。

PR 审查

变量	默认值	用途
OKFFS_RESOLVE_THREADS	false	在 PR 审查讨论串得到处理后自动将其标记为已解决。

文档与变更日志

变量	默认值	用途
OKFFS_UPDATE_DOCS	false	执行 create_pull_request 时自动更新 CHANGELOG/SECURITY。
OKFFS_EXCLUDE_DOCS	—	要跳过的文档，使用逗号分隔（CHANGELOG.md、SECURITY.md）。
OKFFS_UPDATE_GUIDANCE	false	提醒 Claude 在创建 PR 时保持 CLAUDE.md 同步。

GitHub Projects v2（看板）

变量	默认值	用途
OKFFS_PROJECT_ENABLED	false	启用 GitHub Projects v2 集成。
OKFFS_PROJECT_ID	—	看板的 GraphQL 节点 ID（启用时必填）。
OKFFS_PROJECT_AUTO_ADD	false	将新 Issue 添加到看板（当看板没有原生自动添加功能时作为后备）。
OKFFS_PROJECT_INITIAL_STATUS	—	新添加的 Issue 所进入的列（例如 Backlog）。
OKFFS_CLASSIC_PAT	false	仅在使用经典 admin:org PAT 时设为 true——启用组织级 Issue Field Priority/Effort（令牌权限范围较广，需权衡安全性）。

分支晋升与发布（promote_branch）

变量	默认值	用途
OKFFS_PROMOTION_STATUS	—	推广 PR 卡片所处的看板 Status 列（例如 Review）。需要启用 OKFFS_PROJECT_ENABLED。
OKFFS_PROMOTION_REVIEWERS	—	要求在 gate PR 上进行审查的用户，以逗号分隔（例如 copilot-pull-request-reviewer[bot]）。仅当 OKFFS_PROMOTION_AUTO_REVIEW=true 时才会生效。
OKFFS_PROMOTION_AUTO_REVIEW	false	选择启用自动要求上述审查者审查，仅在创建 gate PR 时生效（重新运行时绝不生效）。⚠️ 费用： Copilot 代码审查按量收费，因此每新建一个推广 PR 都会产生费用。
OKFFS_TAG_RELEASE	false	合并推广 PR 后，重新运行 promote_branch 会在合并提交上为其包含的发布版本打标签（vX.Y.Z，或按应用使用 {app}-X.Y.Z）。⚠️ 不可撤销： 打标签通常会触发 CI 发布。
OKFFS_AUTO_MERGE_PROTECTED	false	允许重新运行 promote_branch 在所有 gate 均通过后（检查为绿色、没有待处理的已请求审查、讨论线程已解决）将 gate PR 合并到 OKFFS_PROTECTED_BRANCH。如果设置了 OKFFS_TAG_RELEASE，随后还会打标签——完成整个推广流程。这是 okffs 合并受保护分支的唯一方式。

多站点（一个仓库中有多个应用）

变量	默认值	用途
OKFFS_APPS	—	根目录 .env：应用目录的逗号分隔注册表（finance,health）。
OKFFS_APP	—	某个应用目录的 .env（继承根目录配置）：标识此目录所属的应用。设置标签前缀 {app}-、发布分支前缀、默认标签和标识符。仅当根目录本身也是一个应用时，才在根目录 .env 中设置。

自动驾驶（最大限度减少干预）

变量	默认值	用途
OKFFS_AUTOPILOT	false	默认让会话进入自动驾驶模式：在每个可逆的分岔点选择推荐选项，持续推进到创建针对基础分支的 PR，并报告所做决定。硬性停止项（破坏性工具，以及任何你未选择启用的受保护、计费或不可撤销操作）仍会中断流程。每次请求单独启用（“全权处理”）始终有效。

约定

• 分支： {issue-number}-{kebab-title-slug}（标题截断至约 5 个词），例如 42-add-hero-section-to-homepage。
• PR： 标题为 Close #42 - Add hero section to homepage；正文始终包含 Closes #42。PR 合并到仓库的默认分支时，GitHub 会自动关闭 issue。如果 OKFFS_BASE_BRANCH 指向非默认分支（例如 develop），则需通过 close_issue 手动关闭 issue——create_pull_request 会对此发出提示。
• 破坏性工具需要 confirmed: true；批量创建类工具会先请求确认。
• issue 状态始终以 GitHub 为准——绝不使用本地状态。
• 优先使用 okffs 工具，而非原始 git/gh。 如果 okffs 工具支持某项操作——issue、PR、评论、审查线程（resolve_review_thread / address_pr_review）、发布版本、项目状态——就使用该工具，并遵循其环境变量开关（OKFFS_RESOLVE_THREADS、OKFFS_BASE_BRANCH、OKFFS_PROTECTED_BRANCH，等等），不要自行重新推导行为。只有在没有合适的 okffs 工具时，才回退到原始 git/gh。

贡献

欢迎提交错误报告、功能建议和 PR——开发环境设置、如何添加工具、提交/分支约定及发布方式，请参阅 CONTRIBUTING.md。发布说明见 CHANGELOG.md 和 Releases 页面。

许可证

MIT