okffs

okffs

Claude との会話から GitHub の issue、ブランチ、プルリクエストを作成できます。Claude Code を離れる必要はありません。

okffs は、Claude Code で GitHub の issue → ブランチ → PR → クローズというワークフローを実現する Model Context Protocol サーバーです。作業内容を自然な言葉で伝えるだけで、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	課題と対応するブランチを作成します（エピックにはブランチもドラフト 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	1 件の課題の詳細を取得します。タイトル、本文、ラベル、担当者、ブランチ、ステータスが含まれます。
comment_issue	コメントを投稿します。ブランチで行った作業の記録などに便利です。
link_issues	2 件の課題をリンクし（blocked_by、blocking、parent）、## Relationships セクションに保存します。
close_issue	課題をクローズし、次の課題に取りかかる前に /clear を実行するよう案内します。
create_pull_request	課題のブランチの PR を作成します。タイトルと本文を生成し、ブランチをプッシュして、必ず Closes #N を含め、課題にコメントを投稿します。OKFFS_UPDATE_DOCS=true の場合、変更履歴の断片を作成できます。コミットのないブランチにトラッキング用のドラフト PR を後から作成するには、allow_empty: true を渡します（ブランチを分岐させるため、空の初期化コミットをプッシュします）。
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 をマージ（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 を作成します。最初に確認を行います。タグ付けや公開は行いません。マルチサイトではアプリごとに実行します。
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	設定済みのトークンを使い、1 回の 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 が行い、GitHub の操作は okffs が担います。同じループを実行するスラッシュコマンド /okffs:address_pr_review（PR 番号を指定）もあります。

デフォルトでは、解決できるようレビューのスレッドは未解決のまま残ります。対応後に okffs がスレッドを解決するようにするには、OKFFS_RESOLVE_THREADS=true を設定します。

オートパイロット（介入を最小限に）

手をかけずに進めるには、Claude に*「これをすべて任せる」（または「介入を最小限に」*）と依頼します。または、OKFFS_AUTOPILOT=true を設定してデフォルトにできます。オートパイロットでは、元に戻せる判断について選択肢を選ぶよう求めるのをやめ、分岐ごとに推奨される選択肢を採用し、Issue の作業をベースブランチへの PR まで進めます（OKFFS_AUTO_MERGE_BASE=true の場合はベースブランチへのマージまで行います）。その後、PR と Issue に**「オートパイロットの判断」**レポート（選択ごとに、選択内容と理由をそれぞれ1行で記載）を投稿するため、1つのメッセージで進行方向を修正できます。

確認の手間はなくなりますが、新たな権限が与えられるわけではありません。オートパイロットでも、ハードストップは必ず割り込みます。対象は、破壊的なツール（delete_issue／delete_branch）、および OKFFS_PROTECTED_BRANCH に対する操作（マージ／タグ付け／公開）、課金が発生する操作、または明示的にオプトインしていない取り消し不能な操作です。明示的な環境変数によるオプトインは同意として扱われ、再確認されることはありません。対象は OKFFS_PROMOTION_AUTO_REVIEW（Copilot のレビューは、GitHub の課金に関するご自身の選択です）、OKFFS_AUTO_MERGE_PROTECTED、OKFFS_TAG_RELEASE です。チェックの失敗、レビュー待ち、未解決のスレッド、ブランチ先端の移動など、正確性に関わる停止条件がフラグによって無効になることはありません。また、実際に情報が不足している状況、つまり文脈を把握しているのがあなただけの場合は、Claude は推測せず、簡単な質問を1つだけします。デフォルトではオフです。

リリースとプロモーションゲート

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 が管理する1つのセクション（HTML マーカーで区切られた ## Project Guidance (okffs usage)）を更新します。手書きの内容には一切触れません。これは変更履歴ではなく、ガイダンス（ツール、環境変数、規約）の整理です。PR 作成時に Claude に実行を促すには、OKFFS_UPDATE_GUIDANCE=true を設定します。このコマンドはいつでも利用できます。

ドキュメントの自動更新

OKFFS_UPDATE_DOCS=true にすると、create_pull_request がブランチにドキュメントの更新を書き込み、PR の差分に反映されます。

• CHANGELOG.md — .changes/unreleased/ に作成される、課題ごとの Keep a Changelog フラグメントです。リリース時に 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）。これにより、2 つのシステムが最終状態をめぐって競合することはありません。

優先度と工数は、プロジェクト標準の単一選択フィールド（Projects に対応する任意のトークン）か、GitHub 組織レベルの Issue Field のどちらでも利用できます。組織レベルの Issue Field はプロジェクトの外部にあり、admin:org 権限を持つクラシック PAT と OKFFS_CLASSIC_PAT=true が必要です。ファイングレイン PAT ではまだアクセスできないため、okffs はその方法をスキップし、UI で値を設定するよう案内します。Claude はデフォルトで各タスクの優先度と工数を推測し、推測できない場合は OKFFS_DEFAULT_* の値を使用します。

自動追加（OKFFS_PROJECT_AUTO_ADD）は、GitHub 標準の「プロジェクトへの自動追加」ワークフローを利用できないボード向けの代替手段です。ボードがすでに自動追加に対応している場合は、false のままにしてください。

トークンの権限： Projects v2 は GraphQL 専用であり、Projects に対応するトークンが必要です。ファイングレイン PAT の場合は Organization → Projects: Read and write、クラシック PAT の場合は project スコープが必要です。repo、project、admin:org を備えた 1 つのクラシックトークンで、組織レベルの Issue Field を含むすべての機能を利用できます。権限が不足している場合は、必要な権限を明示した [okffs] エラーが表示されます。

マルチサイト（1つのリポジトリ内に複数のアプリ）

1つのリポジトリで、たとえば 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/
    └── …

• 各アプリのディレクトリには、アプリ名（OKFFS_APP）を指定する独自の .env があります。 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_APPS にない OKFFS_APP、レジストリはあるものの OKFFS_APP が設定されていないルートのセッションについて警告します。既存の vX.Y.Z タグはそのまま維持されます。アプリの初回リリースでは、比較範囲ではなくそのタグにリンクされます。シングルサイトのユーザーは何もする必要はありません。

設定

okffs を設定する最も手軽な方法はウィザード — npx @neturely/okffs setup — です。以下で説明する .env を作成し、管理します。このセクションの残りでは、ウィザード（または手動）で設定できる項目を説明します。

okffs はフォールバックを使ってトークンと対象リポジトリを解決するため、ほとんどのユーザーは最低限の設定で済みます。

トークン（最初に見つかったものを使用）：

1. .env ファイルの GITHUB_TOKEN — fine-grained PAT（推奨。最小権限）または classic PAT を使用します。fine-grained PAT には、リポジトリに対する Issues、Contents、Pull requests（読み取り／書き込み）、Metadata（読み取り）、Administration（読み取り／書き込み）の権限が必要です。classic PAT には repo スコープが必要です（より広範な権限で、すべてのリポジトリへのアクセスが許可されます）。
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	リポジトリのデフォルト	新しいイシューブランチの作成元となるブランチです。
OKFFS_PROTECTED_BRANCH	—	OKFFS_AUTO_MERGE_PROTECTED / OKFFS_TAG_RELEASE でオプトインしない限り、okffs が自律的にマージ、タグ付け、または公開を行わないブランチです（例：main）。対象となるのはマージであり、PR の作成ではありません。okffs はこのブランチをターゲットとする PR を自由に作成します（作成は安全です。マージはブランチ保護と手動でのマージによってすでに制御されており、マージやタグ付けはご自身で行うようリマインダーを追加します）。
OKFFS_IDENTIFIER	—	ブランチ名のプレフィックスです：{number}-{identifier}-{slug}。
OKFFS_AUTO_PR	false	新しいイシューブランチの作成時にドラフト PR を作成します。
OKFFS_BASE_MERGE_METHOD / OKFFS_PROTECTED_MERGE_METHOD	squash / merge	ブランチ階層ごとの PR マージ方法（squash/merge/rebase）です。規約を記録するもので、マージ権限は付与されません。
OKFFS_AUTO_MERGE_BASE	false	merge_pull_request に、チェックが成功し、スレッドが解決済みのイシュー PR をベースブランチに自律的にマージさせます。OKFFS_PROTECTED_BRANCH は決してマージしません。

イシューのデフォルト値と推定

変数	デフォルト	説明
OKFFS_DEFAULT_ASSIGNEES	—	新しいすべてのイシューに割り当てる、カンマ区切りのユーザー名です。
OKFFS_DEFAULT_LABELS	—	推定されたラベルに追加する、カンマ区切りのラベルです。
OKFFS_DEFAULT_PRIORITY / OKFFS_DEFAULT_EFFORT	—	推定も指定もされていない場合の、ボードの優先度／作業量のフォールバック値です。
OKFFS_INFER_PRIORITY / OKFFS_INFER_EFFORT	true	Claude がタスクから優先度／作業量を推定できるようにします。
OKFFS_INFER_TYPE	true	Claude がタスクからネイティブの GitHub イシュータイプ（Task/Bug/Feature/…）を推定できるようにします。組織レベルで適用され、ユーザーのリポジトリでは問題なくスキップされます。
OKFFS_DEFAULT_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	PR の作成時に CLAUDE.md を最新の状態に保つよう Claude に促します。

GitHub Projects v2（ボード）

変数	デフォルト	説明
OKFFS_PROJECT_ENABLED	false	GitHub Projects v2 との連携を有効にします。
OKFFS_PROJECT_ID	—	ボードの GraphQL ノード ID です（有効にする場合は必須）。
OKFFS_PROJECT_AUTO_ADD	false	新しいイシューをボードに追加します（ボードにネイティブの自動追加機能がない場合のフォールバック）。
OKFFS_PROJECT_INITIAL_STATUS	—	追加されたイシューが最初に配置される列です（例：Backlog）。
OKFFS_CLASSIC_PAT	false	クラシックな admin:org PAT を使用する場合に限り true に設定します。組織レベルのイシューの優先度／作業量フィールドを有効にします（広範な権限を持つトークンを使用するため、セキュリティ上のトレードオフがあります）。

ブランチの昇格とリリース（promote_branch）

変数	デフォルト	用途
OKFFS_PROMOTION_STATUS	—	プロモーション PR のカードが配置されるボードの Status 列（例：Review）です。OKFFS_PROJECT_ENABLED が必要です。
OKFFS_PROMOTION_REVIEWERS	—	ゲート PR でレビューを依頼するレビュアーをカンマ区切りで指定します（例：copilot-pull-request-reviewer[bot]）。OKFFS_PROMOTION_AUTO_REVIEW=true の場合にのみ適用されます。
OKFFS_PROMOTION_AUTO_REVIEW	false	ゲート 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 の再実行によってゲート PR を OKFFS_PROTECTED_BRANCH にマージできるようにします。OKFFS_TAG_RELEASE が有効な場合は、その後にタグを付けます。これでプロモーション処理がすべて完了します。okffs が保護ブランチをマージする唯一の方法です。

マルチサイト（1 つのリポジトリに複数のアプリがある場合）

変数	デフォルト	用途
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 がイシューを自動的にクローズします。OKFFS_BASE_BRANCH がデフォルト以外のブランチ（例：develop）を指している場合は、close_issue でイシューを手動でクローズしてください。create_pull_request がこの点を通知します。
• 破壊的なツールでは confirmed: true が必要です。一括作成ツールは事前に確認を求めます。
• イシューの状態の正となる情報源は常に GitHub です。ローカルの状態を参照してはいけません。
• 生の git／gh より okffs のツールを優先してください。 okffs のツールで操作（イシュー、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