Imported from ak110/dotfiles (agent-toolkit/skills/wi-standards/SKILL.md). Install upstream with npx skills add ak110/dotfiles --skill wi-standards. Copyright stays with the author.

AWIとUWIの共通規範

AWIとUWIは、ユーザーとエージェントが非同期に作業要求と確認事項を共有する人間向け文書である。 AWIは未完了の作業要求を、UWIはユーザーの判断を要する確認事項を表す。 UWIは、回答を得るまで元の作業を再開又は確定できない事前承認型と、最善と判断する対応を実施したうえで当該対応の可否を問う事後承認型に分かれる。 回答不要の通知、完了報告、別項目の完了待ち及び時間経過待ちをUWIにしない。

本文はagent-toolkit:writing-standardsに従い、技術的な実装へ寄り過ぎず、単独で対象と期待結果を特定できる粒度で書く。 本文の短縮は、重複の除去と、判断を変えない記述の削除だけで行う。略語の新設と用語の圧縮による短縮は行わない。文字数と行数の機械的な上限は設けない。

通常AWIの本文

通常AWIはH1と、次の順序で並べたH2の節で構成する。H1のタイトルは、対応内容や理由などがユーザーへ伝わりやすい表現で書く。H1直下の本文には目的を書き、必要に応じて手段の概要と、当該目的が生じた観測事象又は要件を併記する。手段の詳細と判断材料はH2の各節へ置き、各節は本文だけで判断できる具体性を持たせる。

# <対応内容や理由などがユーザーへ伝わりやすいタイトル>

<目的。必要に応じて手段の概要と、当該目的が生じた観測事象又は要件を併記する>

## 反映内容と反映先

<何をどう変えるかと、対象リポジトリ、文書、機能などの反映先>

## 適用範囲

<エージェント由来では必須>

## 実現性

<エージェント由来では必須>

## メリット

<採用時に得られる効果>

## デメリット

<費用、副作用又は「なし」>

## 完成条件

<変更後に消費主体が達成できる状態>

## ユーザー指摘の逐語引用

<ユーザーの指摘又は要求を起点とする場合は必須>

sourceを持つエージェント由来の通常AWIは## 適用範囲を必須とし、## 反映内容と反映先の次へ置く。 誤りの機構が依存する条件と、観測事象と表面構造が異なる該当例を1件以上書く。 観測事象のファイル名、工程名又は識別子が条件へ現れる場合は、機構が当該属性へ依存する根拠を併記する。 人間由来の本文には適用範囲を要求しない。

エージェント由来の通常AWIには、影響範囲と改修規模の見込みを1行か2行で任意に記載できる。 この見込みのために時間をかけて推定しない。 人間由来の本文には影響範囲と改修規模の見込みを要求しない。

sourceを持つエージェント由来の通常AWIは## 実現性を必須とし、## 適用範囲の次へ置く。 ## 実現性には、実現方式が依存する公開契約、実行環境の機能又は対象実装の存在を実測して確認した根拠を書く。 あわせて、当該確認が保証する範囲を書く。 APIやCLIが存在することだけを根拠にしない。 要求が依存する消費側、開始から完了までの状態遷移、途中失敗時の状態のそれぞれについて、確認した根拠と確認できた範囲を対応付ける。 確認していない範囲がある場合は、その範囲を同じ節へ書く。 確認していない範囲へ記述できるのは、当該事項が未確定のままでも実現方式の成立と## 完成条件の判定が変わらない事項に限る。 実現方式の成立と## 完成条件の判定のいずれかを変える事項は、投入前に実測して確定するか、当該要求を本文の範囲から外す。 実施の有無が条件節（「…できない場合は…する」の形）で分岐する要求は、## 反映内容と反映先と## 完成条件へ書かない。 当該条件節は条件の成否を確認していないことを示し、## 投入と取得の手順4が投入を認めない状態に当たる（厳守規定。条件の成否が未確定の要求を投入すると、次に当該項目を処理する主体が条件の調査からやり直す）。 実現できることだけで採用を確定しない。 採用案が当初の目的に無かった永続状態、周辺機能、運用手順のいずれかを必要とする場合は、当該追加が元の目的に対して必要かを同じ節へ書く。 既存機能で代替できるかも同じ節へ書く。 実現方式を変える本文の改訂でも、同じ基準で## 実現性を書き直す。 人間由来の本文には## 実現性を要求しない。

根拠として足りない記載の例は、パッケージの導入機能が存在することだけを根拠として、更新を含む利用シナリオ全体が成立すると書くものである。 実行中の旧版と更新後の新版が参照するコード、依存、資源の対応を確認していないため、消費側と状態遷移への対応付けが無い。 根拠として足りる記載の例は、対象コマンドのヘルプで受理形式を確認し、実際の対象範囲へ適用して出力量を実測したものである。 この例では、消費側の経路と当該経路が入力とする値を挙げ、実測値が要求の目的を満たすかまで書く。

## 完成条件には、実装方式ではなく外部可視の終了状態を一意に書く。 複数の実装方式を許容する場合も、達成する状態と消費主体へ要求する操作の要否は一意にする。 完成条件を確定できない本文は登録しない。

## 完成条件と判断材料へ実測を要求してよいのは、当該実測を低コストの実行1回で得られる場合とする。 事象の発生の待機、専用の計測手順の構築、又は複数のセッションにわたる蓄積を要する実測は## 完成条件へ書かない。 当該実測を得られた場合に用いる任意の判断材料として書くか、要求そのものを書かない。 実測を得られないことを理由に当該項目が実施されない構造を生じさせない。 agent-toolkit/rules/01-agent.md「調査と検証」が求める実測は、成果物へ書く主張の裏付けを対象とする。 本項は次に当該項目を処理する主体へ課す作業の費用を対象とし、当該規定の裏付けの要求を緩和しない。

## 反映内容と反映先が挙げる反映先が配置規約を持つ対象である場合は、当該配置規約の正本を起草前にSkill機能で起動し、その判定を適用して反映先を確定する。 配置規約を持つ対象とは、置き場所の選択によって読み込み契機又は適用範囲が変わる文書群及びコード群を指す。 規範文書では常時読み込まれる層と場面ごとに起動する層の別をagent-toolkit:writing-standardsが定め、コマンドラインツールでは配置先ディレクトリの別を対象リポジトリの配置規約が定める。 当該正本の判定をそのまま用いる。

既存の実装、設計又は規範を過去の形へ戻す提案と、過去の契約を撤去する提案では、当該箇所を現在の形にした変更の導入目的を調べ、提案する案がその目的を満たすかを確定する。満たさない場合は両方を満たす案へ改める。調べた変更の識別子と判定結果をH1直下の本文へ記録する。判定の手順はagent-toolkit:plan-modeのreferences/plan-file-standards.md「復元・巻き戻し型の変更」を正本とする。

詳細な証拠、代替案又は再現手順は、前掲の節だけでは完成条件と採否を判定できない場合に限り、独自のH2として## 完成条件と## ユーザー指摘の逐語引用の間へ置く。

本文の記載量は、次に当該項目を処理する主体が、当該項目を誤って不採用と判定せず、意図と異なる実装へ進まないために必要十分な情報を残すことを基準に決める。 残す対象は、次に処理する主体が計画と実装を確定するために要する変更対象、根拠、完成条件及びユーザー要求の逐語引用とする。 書かない対象は、## 完成条件が## 反映内容と反映先を言い換えて繰り返す記述、採否と実装を変えない## メリットと## デメリットの列挙、実現方式の成立確認のうち結論と典拠以外の経過、並びに他のキュー項目及び過去のセッションの経緯とする。

本文が既存の規範の適用範囲へ言及する場合は、当該条文を再掲せず、条文を持つ文書のパスと節名を参照し、当該規範を変えない旨だけを書く。参照で完成条件を一意にできないと判断して再掲する場合は、一意にできない理由を同じ本文へ書く。当該条文自体の変更を求める項目が変更前後の文面を引用することは、本項の再掲に当たらない。

本文の消費主体は、対象リポジトリのプロジェクト文脈を持たず、受け取った本文と対象リポジトリの実体だけで独立に判断する実装担当とする。 当該主体が本文だけで着手できるよう、変更対象、判断基準及び完成条件を本文へ確定して書く。 通常AWIの本文には、[要確認]、TBDその他の未確定事項を残さない。ユーザーの選好に依存する事項はUWIへ分離し、当該事項に依存するAWIを回答まで保留する。技術調査で確定できる事項は起草者が調査してから本文を確定し、確定できるまで通常AWIを投入しない。 素材で確立した事実と、起草者が推測で補った事項を区別せずに本文を確定しない （厳守規定。推測で補った事項が確定要件として読まれると、ユーザーが求めていない実装が計画へ入る）。

UWIを起草する場合はreferences/uwi-format.mdを全文読み、現行の質問・回答欄契約を適用する。

由来と承認

sourceは本文全体の既定由来を示す。sourceの欠落だけを既定で人間由来とし、値を持つ項目は全て既定でエージェント由来とする。保存済みの値は改変せず、過去の項目も移行しない。

エージェントが投入する項目はsourceを必須とする。スキルを起動して投入する場合は、当該スキル名からプラグイン名の修飾を除いた値（add-awi、process-wi、session-reviewなど）を用いる。対応するスキルを持たない起票はagentを用いる。ユーザーの指示に基づいてエージェントが投入する項目にも同じ規則で値を付け、人間由来として扱う範囲は次の明示由来で示す。

要求単位に記録された次の明示由来は、本文全体の既定由来より優先する。

• 末尾の厳密なH2 ## ユーザーコメント配下の要求
• UWIの## 回答に記録された要求
• 関連計画の実施内容に記録された由来
• 出所と引用範囲を保持した対話回答

明示由来の有無は種類ごとに本文を確認して判定し、## ユーザーコメントの見出しの有無だけで判定しない。同見出しは末尾の厳密なH2として定義されたユーザー専用の記入欄であり、出所と引用範囲を保持した対話回答はこれとは別の明示由来として、別の見出しの下に置かれることがある。

出所と引用範囲を保持した対話回答は、当該回答の逐語引用が本節末尾の逐語転記が定める記法で本文へ存在する場合だけ成立する。ユーザーの発言を要約した記述と言い換えた記述を当該明示由来の根拠にしない。 逐語引用から直接導けない具体的な対象、範囲又は外部可視の結果をエージェントが補った場合、その補足は引用の外へ置き、エージェント由来として扱う。関連計画は、人間由来の要求とエージェントが具体化した要求を実施内容の由来欄で分けて記録する。 WIが作成されたセッションと実行環境のいずれかは、保存済み項目をセッションlocator、作成commit、作成処理の記録のいずれかへ対応付ける構造化された証拠からだけ確定する。WI本文、逐語引用、記述内容の一致は要求の出所を示す根拠であり、当該WIの作成時のセッション情報と実行環境情報の根拠にしない。構造化された証拠が無い場合は不明と記録する。

当該構造化された証拠は、atk wi addが投入時にfrontmatterへ保存するorigin_sessionとorigin_locatorの組とする。origin_sessionは当該項目を投入した実行主体のセッション識別子とする。origin_locatorは当該要求の出所となったユーザー発話の所在を<記録集合識別子>:<行番号>の形式で示す値とする。両方を保存した項目だけが当該証拠を持ち、いずれかを欠く項目は作成セッションと実行環境を不明として扱う。対象リポジトリの基準commitを示すtarget_commitと、投入元の識別子を示すsourceは、当該証拠に用いない。

エージェントがWIを投入する場合、当該要求の出所となったユーザー発話のlocatorを保持しているときはatk wi addの--origin-locatorへ当該値を渡す。保持していないときは渡さず、当該項目は当該証拠を持たない項目として扱う。 由来を分離できない要求は人間由来として扱う。人間由来の要求を全部又は一部不採用にする場合は、原文との差異、技術的理由及び代替案を示してユーザーへ確認する。回答を得られない場合はUWIを保存し、当該項目に採用済みの範囲があるかで終端を確定する。 採用済みの範囲が無い項目は、暫定判断でrejectedへ終端してよい。 採用済みの範囲がある項目はrejectedへ終端せず、当該範囲をadoptで終端し、確認を得られない不採用の範囲だけを内容とする新しい項目を登録して当該UWIをdepends_onへ加える。 rejectedは全要求の不採用を確定した終端であり、採用済みの範囲を持つ項目へ用いると当該範囲の完了が終端の意味と一致しないためである。 UWIの回答が採用を示した場合は、return-to-inboxでrejectedからinboxへ戻して再処理する。エージェント由来だけの独立した要求は、技術的根拠により自律的に不採用と判断できる。

人間由来のWI本文、ユーザーコメント、UWI回答、対話回答のいずれかに、外部操作、対象及び範囲が明記されていれば、その範囲の承認として扱う。source値だけの場合、空のコメント欄、エージェントの推奨、一般的な「進めて」は承認にしない。読み書きする主体はユーザーとエージェントだけとする。署名、認証、監査用の仕組みは追加しない。

UWIの## 回答節とAWIの## ユーザーコメント節はユーザーだけが書き込む欄とし、エージェント環境から起動したatkはこれらの節を含む本文の投入と編集を拒否する。 atk wi editが本文を--body-fileで受け取る場合は、## ユーザーコメント節を編集の対象から外し、保存済みの内容をそのまま残す。 エージェント環境から起動したatk wi editは、processingの項目の本文置換を拒否する。処理中の要求を書き換えると、当該要求が当該セッションで処理されるかが変わるためである。エージェントは、書き換えたい内容を新しい項目として投入し、当該項目へは--appendによる追記だけを行う。ユーザーの操作は拒否しない。 エージェントがユーザーの要求を起点としてWIを投入する場合は、当該要求の採否と実装方針の根拠となったユーザーの発言を、本文中へ出所と引用範囲を示して逐語で転記する。転記する本文はagent-toolkit:writing-standardsの「ユーザー入力素材の取扱い」が定める逐語引用の記法で囲み、原文を改変しない。要約と言い換えを当該転記に代えない。本規定はsourceの値によらず、全ての投入経路へ適用する。転記にあたり前掲の2つの見出しを作成しない。転記はエージェントが書いた記述であり、ユーザー自身の記入欄と同じ扱いにしない。

状態と依存

型、保存状態、導出判定及び一覧集合を区別する。

エージェントが実行できる状態遷移を次に示す。ユーザーはブラウザーUIから任意の状態へ遷移させられる。

inboxとholdの項目はatk wi rmで削除できる。本文の編集はinbox、processing、holdの各状態で行える。 投入済み項目の本文を修正する主体は、当該項目の修正が必要と判断した時点でatk wi holdを実行する。調査・ユーザーとの認識合わせ・本文の起草は保留の後に行う。保存本文の照合を終えた時点でatk wi unholdを実行する。常駐するatk wi process-loopが、修正の必要が判明した後の本文を取得することを防ぐためである。書き換えの直前に保留して直後に解除する順序では、修正が必要と判断してから本文を確定するまでの区間が保護されない。 agent-toolkit:process-wiはprocessableの項目だけを処理の対象とし、holdの項目を候補、優先度、依存判断及び固有指示の入力から除外する。

depends_onは、当該項目より先に終端すべきキュー項目のファイル名を保持する。用途は、未回答UWIによる外部待ちと、先に終端すべきAWIへの先行成果依存の2つとする。依存先はtarget_repoが異なるキュー項目でもよく、着手可否はリポジトリを横断して判定する。値は保存済みのメタデータを正本とし、本文の記述から依存を再構築しない。

depends_onはatk wi set-dependencies <filename> --depends-on <filename>で登録する。同コマンドはinbox、processing及びholdの項目の依存を更新する。依存の更新は保存状態を変えないため、前段が定めるholdの区間の内側で本文と依存の双方を確定できる。本文へ依存を記述してメタデータの代わりにしない。本文の記述はreadyとblockedの導出判定へ反映されない。

着手不能の要因は、解除される契機で分類する。時間経過だけで解除される要因はcooldown_untilで表し、レート制限のバックオフ、再試行間隔及び期日到来待ちがこれに当たる。実在する先行キュー項目の終端で解除される要因は、当該項目のファイル名をdepends_onへ直接加えて表す。他リポジトリの成果待ちも、待つ対象がキュー項目として実在する場合はこの直接依存で表す。人間の回答がなければ解除できない要因は、解除条件と再開工程を本文へ持つUWIをdepends_onへ加えて表す。UWIへ分類する前に、回答者へ提示する問いを1文で記述できることを確認する。問いを記述できない要因をUWIにしない。外部環境の制約と別環境での実施は要因の発生場所を示すに過ぎず、それだけではUWIの根拠にならない。対処方針の選択若しくは実施可否の判断をユーザーへ求める場合だけUWIとし、必要な認可を既に得ている実施はagent-toolkit:process-wiの外部操作の経路で扱う。cooldown_untilを設定する主体は、当該要因が時間経過で解消することを実測又は公式一次資料で確認してから設定する。確認できない要因をcooldown_untilで表さない（厳守規定。時間経過で解消しない要因をcooldown_untilで表すと、選定側が期日まで当該項目を除外し続け、解除の契機が発生しない）。

事後承認型UWIは元の作業を待たせないため、depends_onへ加えず、元項目を当該UWIの回答前に終端する。 回答が是正を求めた場合は、当該UWI自体を作業要求として処理し、新しいAWIを起票しない。

事前承認型のUWI待ちは物理的なholdへ移さず、元項目の既存依存を保持してUWIをdepends_onへ加え、inboxかつblockedにする。inboxへ戻した後に着手可否がblockedであることを確認する。回答を保存したUWIを先に終端し、依存解除を確認した後に元項目を次の処理対象へ戻す。回答を保存した別セッションが終端まで到達しなかった場合は、次に当該キューを処理するagent-toolkit:process-wiのpickerが、AWIをprocessingへ移す前に当該UWIを終端する。メインは${CLAUDE_PLUGIN_ROOT}/share/pick-wi.parent.mdの「出力の受領」に従ってadoptedへの存在を検収し、「選定工程の完了」へ進む。

rejectedはエージェントが全要求を不採用と判断した時点で使用できる終端とし、後からreturn-to-inboxでinboxへ復元できる。技術的失敗、入力不足、外部条件待ち又は計画不備は不採用へ変換せず、必要なUWI依存を付けてactiveのまま保持する。

対象リポジトリの成果物を変更しても満たせず、対象リポジトリが依存する上流リポジトリの改訂を要する要求は、外部条件待ちとして据え置かず、当該上流リポジトリへ同じ要求のAWIを投入する。元項目はholdと終端のいずれへも移さずinboxへ戻し、1つの項目を要求ごとに異なる保存状態へ分けない。対象リポジトリで実施できる要求を併せ持つ項目は、当該要求の実装を終えてからinboxへ戻す。投入したファイル名の依存への追加、状態の確認及び上流項目の終端後の進め方はreferences/cross-repository-submission.mdに従う。

エージェントが自身の誤りで投入した項目はrejectedへ終端せず、atk wi rmで削除するかatk wi editで本文を正しい要求へ書き直して再利用する。rejectedは要求として成立する項目の不採用だけに使う。 atk wi rmによる削除はキュー管理リポジトリのGit履歴へ残るため、復旧経路を失わない。 当該削除を確認の対象にしない。

条件付き重複判定

エージェントが新しい通常AWIを生成する場合だけ、投入前に同じ対象リポジトリのactive項目を取得し、対象、期待結果、観測事象、根本原因及び必要な処置を照合する。既存項目が全てを覆う場合は新規投入せず既存ファイル名を再利用し、部分的に覆う場合は未被覆部分だけを投入する。表現の類似又は最終結果の一致だけを重複の根拠にしない。

ユーザーが手動起動したagent-toolkit:add-awi、UWI及び移行・復元では、この重複判定を実行しない。

事後承認型UWI

agent-toolkit/rules/01-agent.md「協調と自律」が事後承認と判定した操作は、自律モードでは最善と判断する対応を実施したうえで、当該対応の可否を問う事後承認型UWIを投入する。協調モードでは当該対応の可否をその場の確認経路で確定し、事後承認型UWIを投入しない。 投入する主体は、実施した対応、当該対応を選んだ根拠及び当該対応を取り消す手段を本文へ書き、回答を待たずに元の作業を続ける。 問いは--question-type=choiceの2択とし、選択肢をその対応で問題無いと問題があるとする。 問題があるが選ばれた場合に回答者が是正内容を書く欄を、当該選択肢の説明として本文へ示す。 是正を求める回答を受領して実施した是正についても、その適否を実行主体が観測できない場合は、当該回答を保存したUWIを終端したうえで、同じ手順で新しい事後承認型UWIを投入する。

投入と取得

1. 通常AWIは技術主張を実装、実行結果又は公式一次資料で裏付け、ユーザー依存事項をUWIへ分離してから起草する。観測した欠陥を起点とする通常AWIは、本文の起草前にagent-toolkit:bugfixの初動と原因分析の要否判定を適用する。UWIは原因分析の対象にしない。 投入前に本文を単独で読み直し、「同じ」「上記」「当該」などの指示語の参照先が同一本文内にあり、変更対象、根拠となる事象・要件、対応内容及び完成条件を本文だけから確定できることを検査する。 複数のWIを連続して起草する場合も、各本文を他の本文から独立して検査する。検査に合格しない本文は投入しない。 本文が逐語引用を含む場合は、引用の原文を保持する記録（抽出器の出力、対話の記録、参照元のファイル）を特定し、当該原文と本文の引用ブロックの文字列同一性を投入前に検査する。検査は文字列比較で行い、読解による同義の確認を当該検査に代えない。原文を保持する記録を特定できない場合は、当該引用を本文から除き、要約である旨を明示した記述へ置き換える。対象は## ユーザー指摘の逐語引用と## 回答に限らず、本文中の全ての逐語引用とする。 本文が対象、適用範囲、外部可視の結果、除外内容のいずれかを新たに具体化する場合は、agent-toolkit/rules/01-agent.md「協調と自律」に従って具体化を要する軸を列挙し、軸ごとの判定結果を本文へ書く。 起草の前に、事象を観測した入力・成果物、欠陥を生成した実装、変更する定義、変更後の検収場所を分けて特定する。target_repoは変更する定義を所有するリポジトリとし、事象を観測した場所だけを根拠に選ばない。外部ツール、SDK又は共有設定の欠陥が消費側のリポジトリで表面化した場合は、生成側のリポジトリへAWIを投入し、消費側で再現する条件を完成条件へ保持する。本文が示す反映先と変更対象の所有者がtarget_repoと一致しない本文は投入しない。
2. 複数リポジトリへ投入する場合と、同じ成果の整合を要求する複数のAWIを登録する場合はreferences/cross-repository-submission.mdを全文読む。
3. 同じ対象リポジトリの複数項目を一括取得する場合はreferences/managed-temp-bulk-show.mdを全文読む。
4. 投入の前に、採用の可否と実現方式の成立を確定する。採用の可否は、要求が解決する事象が実在することと、当該要求が対象リポジトリの明文化された方針へ反しないことで判定する。実現方式の成立は、当該方式が依存する公開契約、実行環境の機能及び対象実装が現に存在することを実測して判定する。いずれかが未確定の間はAWIを投入せず、調査を続けるか、ユーザーの選好に依存する事項を確認経路へ送る。確定するのはここまでとし、当該方式の内部設計、変更対象ファイルの分解、実装単位と検証手順は投入した後の計画工程が確定する。 実現方式の成立判定には、変更対象の隣接領域と関連経路にある既存機構、共通契約、類似実装との整合検査を含める。当該検査では、要求する機構が既存の拡張点で成立するかと、同じ主題を扱う関連経路の実装と整合するかを、対象実装の読解により判定する。整合を確定できない案は投入せず、調査を続けるか確認経路へ送る。本項は、当該既存機構と類似実装が対象リポジトリに実在する要求へ適用し、実在しない主題を対象外とする。 実現方式の成立を確認した根拠と、前項の整合検査で照合した対象のファイルパス、識別子、判定結果は、sourceを持つ通常AWIの## 実現性へ記載する。当該節が無い場合と値が空の場合は、atk wi addが保存前に非0で終了して不足項目を示す。 協調モードで動作するセッションから投入する場合は、本文が確定していない対象、適用範囲、外部可視の結果と除外内容の調査を投入前に完了する。確認の要否は当該調査の結果として判明するため、当該調査を投入後の計画工程へ回さない。調査で確定できる事項は自ら確定し、ユーザーの選好に依存すると判明した事項は、agent-toolkit/rules/01-agent.md「確認を要する事項」の確認経路で回答を得てからAWIを投入する。回答を得られない事項は手順1が定めるUWIへの分離で扱う（厳守規定。投入した項目を処理する自律モードのセッションはユーザーの回答を即時に得られず、未確定の項目を受け取ると選好を推定した実装を確定させるか、着手を次の処理回以降へ延ばす）。 投入する要求と現在の作業の対象が独立する場合は、当該要求の調査と投入を1件の委譲先へまとめて渡してよい。
5. 本文はファイルへ保存し、atk wi add --body-file <path>又はatk wi edit --body-file <path>で渡す。WI本文をコマンドライン引数で渡す受理形式は存在しない。手元で短い本文を投入する場合は$EDITORを使う。
6. 登録は本文の内容が確定した時点で行い、複数件をセッション終了時までためて一括登録しない。内容が未確定の事項は登録の対象外とする。
7. 登録するAWIの対象ファイルが現在のセッションの変更対象と重なる場合は、当該セッションが対象ファイルの変更を完了してから登録する（努力目標）。常駐処理が動作する環境では登録が遅れると次の反復まで着手が遅れる一方、変更対象が重なる項目を即時に登録すると別の作業ツリーで同じファイルへ並行着手し得るため、両者を比較して時機を選ぶ。
8. 呼出元が指定した本文、対象リポジトリ、種別、source、plan file及び依存を変更せず登録する。エージェント自身の投入では前節で確定したsourceを省略しない。sourceが未指定の人間由来入力へ値を推測して追加しない。
9. 保存本文の照合は、atk wi addとatk wi editが出力する一致判定で成立を確認する。警告又はエラーが出た場合は完了扱いにせず、同じ経路で修復する。
10. 保存の完了は、atk wi add又はatk wi editが出力する成功の報告と警告の不在で判定する。当該コマンドはprivate-notesへのcommitとremoteへの反映まで行うため、atk config get private_notesが返す作業ツリーの状態、対象branch及びremoteの反映状況を別のコマンドで取得し直さない。未pushのcommitが残る旨の通知を受領した場合は、atk wi commitでpushしてから完了とする。別の作業ツリーを作成して保存する経路は使わない。