github-task-protocol 1.0.3

Reconstruct AI coding task state from GitHub Issue records

GitHub Task Protocol

GTPは、AIへ実装を任せても、人間が目的・変更範囲・現在地・根拠を理解し、停止・再開・やり直し・mergeの判断を手放さないための小さなprotocolです。

作業はAIに任せる。判断は手放さない。

AIの説明だけを信じるのではなく、GitHub Issue上のRecordと、実際のbranch・PR・commit・Check Runからtask stateを再構成します。GTP自身は変更、完了、mergeの権限を与えません。

task固有の未確認事項は、通常のIssue本文やcommentへ人が読める形で残します。開始前から完了判断に必要な不明点はDone Conditionにし、開始後にContract変更が必要になった場合はStopと後継Issueへ移ります。GTP Recordは自由文の意味を自動評価しないため、statusはDone提示前にIssueを確認するURLを表示します。

推奨: 明示的にsetupを依頼

bare GTP repository URLだけではsetup依頼にもrepository変更のauthorizationにもなりません。URLだけを受け取ったagentは、説明または目的確認に留まり、現在のrepositoryを変更しません。

導入先repositoryを操作中のclean agentへ、変更対象とDraft setup PR作成を明示して依頼します。

このrepositoryへGTPを導入するDraft setup PRを作ってください。
GTP repository: https://github.com/shinya0x00/github-task-protocol

この明示依頼を受けたagentは、次の順序でsetupします。

agentが手順を理解できることと、実行中ずっと意図の境界内に留まり続けることは別の能力です。この手順はbranch-first順序で境界逸脱のriskを下げます。GTP単独の強制力はこの手順の受入対象にしません。repository ownerは補完策としてGitHub branch protectionまたはrulesetでdefault branchへの直接pushを拒否し、pull request経由の変更を必須にできます。setup agentは保護設定を変更せず、未設定なら人間へ報告します。

file・branch変更前のpreflight

target fileの編集、branch作成、Issue／comment／label操作、PR作成より前に、read-onlyで既存instruction、task protocol authority、必要な外部provider／runtime／Operationとその接続状態を確認します。結果は次の4つだけです。

1. instructionなし: 通常setupを続行する。
2. 両立可能: 既存instructionを保持し、adapterを非破壊で追加する通常setupを続行する。
3. 未接続dependency: test／mock providerでproduction dependencyを代用せず、変更せずに外部Operation接続のblockerを報告する。
4. 別authority／意味衝突: 自動統合や上書きをせず、人間のauthority判断へ戻す。

blockerでは、chatまたはconsoleへ「何が問題か」「どこが問題か」「なぜそう判断したか」「どこを直すか」「何を直さないか」「次の安全な一手」「最初に確認するURL」「解決したと判断する条件」の8項目を返します。外部Operationのowner URLはread-only取得で確認できた場合だけ表示し、不明なら修正先Issue未確認と表示します。

preflightとblocker報告はephemeralです。working tree、branch、commit、push、Issue、comment、label、PRを変更せず、repair Issueも自動作成しません。blocker解消後は同じ入力でpreflightを再実行します。instructionなしまたは両立可能の場合だけ、次の既存branch-first手順へ進みます。

1. GitHubのlatest stable Releaseを取得し、draft: falseかつprerelease: falseを確認する。未公開candidateやmoving mainは選ばない。
2. Releaseのtagをcommit SHAまでdereferenceし、選択したtagとexact commit SHAを記録する。
3. target fileを変更する前にrepositoryのdefault branch名とhead SHAを記録し、そのheadからgtp/setup-<tag>-<short-sha> branchを作ってswitchする。現在branchがdefault branchではなくsetup branchであることを確認できなければ停止する。
4. そのcommitのGTP.mdだけをhttps://raw.githubusercontent.com/shinya0x00/github-task-protocol/<commit-sha>/GTP.mdから取得し、導入先rootへvendorする。既存GTP.mdとSHA-256が同一なら保持する。内容が異なるfile、別のGTP authority、または既存instructionとの衝突があれば、上書きせず停止して人間へ報告する。
5. root AGENTS.mdがなければ作成する。存在する場合は本文を変更・削除せず、下のexact adapterがなければ## GitHub Task Protocol adapter heading付きで追記する。既に同じadapterがあれば重複追加しない。
6. commitとpushはsetup branchだけに行い、default branchへ直接pushしない。push後にdefault branch headを再取得し、setup開始前に記録したSHAから予期せず変化していたら停止して報告する。Draft setup PRのbodyにはrelease tag、exact commit SHA、immutable GTP.md URL、変更file、保持した既存instruction、次に必要な人間判断を書く。
7. 人間がsetup PRをmergeするまで導入完了としません。merge後、taskごとにGitHub Issueを1件作り、agentへそのIssue URLだけを渡します。

共通adapter文:

このrepositoryはrootのGTP.mdをtask protocolの唯一の正本とする。GitHub Issue URLを受け取ったら、Issue commentをServer Orderで読み、4 Record、6 state、7 halt reasonに従って既存branch・PR・次のprotocol actionを再構成する。Recordを推測、編集、独自拡張せず、矛盾時は原因URLを示して止まり、取得不能はhaltと混同しない。GTPの表示やRecordは変更・完了・mergeの権限を与えない。

配置例は次のとおりです。runtimeごとに異なる指示を作る必要はありません。

• Codex: AGENTS.md
• Claude Code: CLAUDE.mdまたはAGENTS.md
• Cursor: AGENTS.mdまたは.cursor/rules/gtp.md

手動導入

自動setupを使わない場合は、次の3手順で導入できます。

1. latest stable Releaseをexact commitへ固定し、file変更前にdefault branchからsetup用branchを作ってswitchする。
2. setup branch上でGTP.mdをrootへコピーし、共通adapter文を既存instructionへ非破壊で追加する。
3. commitとpushをsetup branchだけに行ってDraft PRを作り、人間が内容を確認してmergeする。

4つのRecord

Record	平易な意味
contract	目的、変更してよい範囲、完了条件を固定する
start	Contractと唯一の作業branchを結び付ける
done	PRのsource headと、条件ごとのEvidenceを提示する
stop	完了を主張せず中止し、必要なら後継Issueを示す

RecordはIssue commentへ人向け要約を先に、機械用JSONを折りたたんで記録します。1 Issue = 1 branch = 1 PRです。 Start branchへrepositoryのdefault branchは指定できません。 Startより前から存在するPRは、そのtaskのcandidateやDoneとして引き継げません。誤ったStartをStopする場合は、古いPRを対象外として安全に閉じます。

6つのstate

state	平易な意味
unmanaged	有効なContractがない
ready	ContractはあるがStart前
in_progress	作業中、Done提示後のmerge待ち、またはCheck Runの完了待ち。Check Run待ちはPRがmerge済みでもdoneにしない
halt	特定transitionを矛盾や不適合のため進められない
done	Doneのsource headへEvidence resourceが結び付き、そのPRがnative mergeされた。条件内容の十分性は人がEvidenceを読んで判断する
stopped	Stopにより、このIssueでの作業を終了した

GitHub情報を完全に取得できない場合はstateを推測しません。404だけではresource不在と権限不足を区別できないため、これはhaltではなくAcquisition Errorです。

未完了Check Runは成功Evidenceではありませんが、それだけでhaltにはしません。変更やmergeを行わず、完了後に同じURLをread-onlyで再確認します。

CLIは任意の検証器

人間がGTPを使うためにCLIをinstallする必要はありません。gtpはagentや自動検査がRecordと現在stateを確認するための、runtime dependency 0の任意toolです。

CLI 1.0.2はPyPIとGitHub Releaseへ公開済みです。再downloadとhash・clean install・live statusの検証結果はacceptance/public-release-v1.0.2.jsonにあります。GTPを使うだけならCLIのinstallは不要です。

pyproject.tomlは、このsourceからbuildするpackage versionとして1.0.3を宣言しています。この値はpublicationのEvidenceでも、exact source commitのidentityでもありません。別のX.Y.Zを使うのは、PyPIのversion pageとGitHub Releaseの両方が解決できることを確認した後だけです。そのとき、下の2つのcommandの1.0.2だけを確認したexact versionに置き換えます。

uvx --from github-task-protocol==1.0.2 gtp status <issue-url>
uvx --from github-task-protocol==1.0.2 gtp check <comment.md>

• 公開済み1.0.2のstatusはGitHubへGETだけを行い、日本語6項目の後にmachine JSONを出します。Evidenceの存在・種類・状態・source headとの結び付きを検査しますが、完了条件の自然言語上の充足までは自動判定しません。
• source version 1.0.3は、state: haltのとき先頭6項目の直後に8項目の「問題の整理」を表示します。 この表示追加はmachine JSONのkey集合、exit code規則、authority: noneを変更しません。
• 未完了Check Runのstate、next_action、exit codeは、上記の非終端境界へ訂正します。
• checkは投稿前のMarkdown comment全文をoffline検査します。Issue上でもvalidだとは主張しません。
• exit code、緑色のCheck Run、Evidence URLは、変更やmergeの許可ではありません。

仕様と判断記録

protocolの唯一の正本は400行以内のGTP.mdです。Record作成やstate判断に、他の文書は必要ありません。

DECISIONS.mdは、設計変更の理由と履歴です。GTP.mdと意味が衝突する場合はGTP.mdを優先します。

実GitHubで観測した引き継ぎ結果はacceptance/level0/にあります。これは仕様の代わりではありません。

GTPが証明しないこと

GTPは、actor本人性、credential安全性、コード品質そのもの、Evidence内容の真実性を証明しません。filesystem削除や本番database操作を物理的に防ぐものでもありません。

サンドボックス、最小権限、不可逆操作前の確認、reviewと組み合わせてください。最終的な受理は、人間がPRとEvidenceを読み、GitHubのnative mergeで判断します。

License: MIT

GTPを試して、分かりにくかった所・詰まった所があれば、一言だけでも教えてもらえると助かります。IssueでもXでも。