---
name: add-feedback
description: >
  フィードバックまたはTBDを投入するすべての経路で起動する。
  完成済み本文の非対話投入と、通常型本文を対話で確定して投入する経路を提供する。
---

# フィードバック投入

本スキルは、フィードバックまたはTBDを投入する手順を提供する。

## 入力

- 完成済み本文は問い直さず、本文、対象リポジトリ、種別、source、plan file、依存関係を受け取る。ユーザー発話を原文とする投入では、受領した`source`を改変せず、受領していない場合は推測しない
- エージェント自身が投入元で人間由来の指示が無い場合は、`source`を必須とし、本スキルが自ら確定する。生成経路名を持つ起票は当該経路名（`session-review`・`alert-monitor`）を用い、経路名を持たない起票は`agent`を用いる
- ユーザーが本スキルを手動起動した投入と、対話中のユーザー指示による登録は人間由来とし、`human`を用いる。`plan-and-add-feedback`から計画実装型として投入する場合は、呼び出し元が指定した`plan`を保持する。ユーザーが`atk mq add`を直接実行した投入の`source`欠落は人間由来として扱い、`source`欄の遡及付与は行わない
- `depends_on`は本文が述べる外部待ち条件に対応するものだけを受け取る。外部待ち条件は未回答TBDの回答待ちと`cooldown_until`による待機とする。解除時刻と観測経路が確定する外部状態の解除待ちと別リポジトリの先行変更の完了待ちも含める。ユーザーが本文で明示した完了待ちと日付境界も含める。実装順序の前後だけを理由に受け取らない
- 完成済みの通常型本文では、投入元が同じ対象と技術主張について完了した調査の証拠を持つ場合に受け取る。
  証拠には計画、調査結果、実行結果を含み、再利用できない範囲の調査は本スキルが担う
- 計画実装型では、投入元が計画作成に使ったworktreeの絶対パスと計画base commitを受け取る。
  計画ファイルに記録された`../plan-mode/SKILL.md`の調査成果を証拠として再利用する。
  リポジトリ本体や別worktreeへ解決し直さず、同じ絶対パスを作業ディレクトリと対象リポジトリ引数へ渡す
- 通常型でも対象の正確なローカルworktreeが既知なら、その絶対パスを`atk mq add --target-repo`へ渡し、
  CLIに正規の対象リポジトリと作成時点のHEAD完全OIDを同時に確定させる。
  worktreeを推測せず、利用できるローカルworktreeがない場合だけURLを渡す
- 通常型の主題だけを受け取った場合は、本スキルが調査を担い、ユーザー向け結果を現在の対話で確定する
- 計画実装型では、計画へ統合する元項目のファイル名を投入元から受け取る

## 手順

1. 複数リポジトリへ投入する時は`agent-toolkit/skills/add-feedback/references/cross-repository-submission.md`を全文読む
2. 複数項目の本文を一括取得する時は`agent-toolkit/skills/add-feedback/references/managed-temp-bulk-show.md`を全文読む
3. 通常型は、適用規範、対象全文、定義・参照・呼び出し元、関連テスト、生成・配布経路、履歴から、
   技術主張に該当する証拠集合を調査する。
   完成済み本文は投入元の証拠を同じ対象と主張へ照合し、不足する範囲だけ同じ証拠集合を調査する。
   技術主張は実装、実行結果、公式一次資料のいずれかで裏付ける。
   規範・設定の現行記述について欠陥・誤り・誤解釈を主張する通常型本文に限り、`git log -S`で当該記述を導入した変更を特定し、`atk config show`が出力する`private_notes`配下の`adopted/`にある対応するキュー項目の本文とユーザー追記を確認する。ユーザーの逐語指示の有無を証拠へ含める。この追加確認は当該主張を含む本文に限って適用し、他の投入へ確認工程を課さない
   技術的未確定が残る間は保存せず、ユーザー依存事項は確認又はTBDへ分離する
4. 本文の起草前に、観測した欠陥を起点とする通常型本文は`agent-toolkit:bugfix`の「初動と深掘り判定」を適用し、事象、期待する契約、実際の結果、発生条件、直接的原因及び深掘り条件を確認する。TBDは判断を求める問いであり、原因分析の対象外とする。深掘り条件に該当する場合だけ同スキルをSkill機能で起動する。起動後は同スキルの深掘り経路へ進む
5. 本文の起草前に`agent-toolkit:writing-standards`をSkill機能で起動する。
   本文冒頭に、何をどう変えるかの結論（提案・依頼・確認事項）を1〜3文で置き、
   観測事象・裏付け・代替案などの詳細は結論の後へ簡潔に置く。
   簡潔化は表現の圧縮で行い、採否を左右する判断材料（代替案・費用・副作用・重複判定など）の削除で行わない
6. 各本文を単体で意味が完結する形にし、対象、観測事象、期待結果、出典、関連提案との関係を含める
   投入後に変化する自己言及的な値（レビューのラウンド数、収束状態、素材件数）は本文へ書かず、計画ファイルの該当節へ委ねる
7. 新規項目は`atk mq add`で保存し、計画実装型は統合元のファイル名を本文へ記録する。
   別リポジトリ移管では、投入前処理で入力メッセージの予約frontmatterキー`target_repo`だけを
   移管先の値へ一時的に置き換えてから、元項目のfrontmatterと本文を含むメッセージ全体を渡す。
   通常の`atk mq add`はfrontmatterの`target_repo`をCLI値で置き換えず、frontmatterの値を優先する。
   sourceを受領又は確定した場合は同じ値を`atk mq add --source=<source>`へ渡す。
   エージェント自身の投入で人間由来の指示が無い場合は、確定したsourceを省略しない。
   ユーザー発話を原文とする投入でsourceを受領していない場合は`--source`を省略し、sourceを推測せず、必須化せず、別値へ置換しない
8. 完了表示のファイル名、`target_repo`、`target_commit`、`plan_file`、`depends_on`を入力と照合する。sourceを受領又は確定した場合は、
   保存後に既存の`atk mq show <filename> --target-repo=<repo-path> --skip-pull`で項目を再取得し、frontmatterのsourceが入力値と一致することを照合する。
   照合対象のsourceが欠落しているか入力値と一致しない場合は完了扱いにせず、同じ経路で修復する。ユーザー発話を原文とする投入でsourceを受領していない場合は追加のsource照合をしない。
   警告やエラーが出た場合も、終了コード0であっても`atk mq show <filename> --target-repo=<repo-path>`で保存内容を再取得し、欠落を同じ経路で修復する
   別リポジトリ移管では、移管先の`target_repo`と本文を照合する。
   元項目の非予約frontmatter（`alert_keys`など）も照合する。
   予約frontmatterは`atk mq add`の管理値と照合する

## 終端の使い分け

`atk mq reject`は、process-loop内で要求の全てを不採用と確定した項目だけに用いる。採用済み内容を別項目へ統合した元項目は、統合先をnoteへ記録して`atk mq rm`で除去する。別リポジトリへ移管して投入先を検収した元項目は、移管先をnoteへ記録して`atk mq rm`で除去する。技術的な失敗、入力不足又は外部条件待ちは不採用へ変換せず、TBD依存を追加してactive状態に保つ。

本スキルは、登録結果の検収に失敗した元項目をreject又はrmで終端せず、登録済みの内容と元項目をactiveのまま保持して失敗を返す。TBDを投入する場合は、`agent-toolkit:add-feedback`のTBD入力契約に従い、元項目へ依存を設定して`blocked`を確認する。

本文へ引用符・改行を含む場合は、本文をファイルへ保存し`atk mq add --body-file <path>`で渡す
（複数回指定可。位置引数との併用は拒否される）。

`atk config show`が出力する`private_notes`配下の`inbox/`又は`processing/`にあるキュー管理ファイルを
専用サブコマンド以外で変更した場合は、作業を終える前に`atk mq commit`を実行する。

## セッション主タスクとしての完了報告

本スキルを起動したセッションの追加指示は、同一主題のフィードバック本文又はTBD本文へ反映する。
対象リポジトリの実装は開始しない。
完了報告後も同一主題が続く限りこの扱いを維持する。
別主題か直接実装かの判定が不明な場合は投入前にユーザーへ確認する。

ユーザーが本スキルを直接起動し、投入がセッションの主タスクである場合は、手順8のsource照合後に次の構成で完了報告を提示する。
他スキルから呼び出された場合は呼び出し元の報告形式に従い、本節を適用しない。
完了報告のメッセージはこの構成だけとし、枠の前後へ地の文を加えない。
`## 振り返り`節は書かない（session-review完了後の最終報告だけが置く）。

```text
<冒頭1文: 投入完了の言い切り>

## 成果

- 投入フィードバック: `<ファイル名>`（<種別>、対象: `<target_repoの値>`）
- タイトル: <本文H1の見出し文（H1が無い場合は本文冒頭の要点1行）>
- 要旨: <本文の要点1、2行>
- 依存: `<depends_onの値>`（無い場合は`なし`）
```

複数件を投入した場合は`## 成果`の項目一式をファイルごとに繰り返す。
本文の全文は転記しない（コードフェンス転記は見出しがレンダリングされず、モバイルで横スクロールになるため）。
全文は`atk mq show <ファイル名> --target-repo=<対象リポジトリ>`又はビューアーで確認する。

## TBD本文の必須要素

TBD本文を起草する時点で`references/tbd-format.md`を全文読み、同文書の必須要素を適用する。

## 完成条件

- ユーザー向け結果に影響する未確定事項が通常型本文へ残っていない
- 通常型は入力形態を問わず、本文の技術主張を実装、実行結果又は公式一次資料で裏付け、
  該当する証拠集合の調査を完了している
- 技術的未確定が通常型本文へ残っていない
- 深掘り条件に該当する通常型本文が4原因区分、原因起点の類似見直し、是正・横展開・再発防止の3処置の結果を含んでいる
- 規範・設定の現行記述について欠陥・誤り・誤解釈を主張する通常型本文では、ユーザーの逐語指示の有無を含む決定記録の確認を完了している
- 完了表示のファイル名、`target_repo`、`target_commit`、`plan_file`、`depends_on`が入力と一致し、
  投入時のエラーを解消済みで、警告があれば再取得により保存内容に欠落が無いことを確認済みで、
  processing項目を変更していない
- エージェント自身が投入元で人間由来の指示が無い場合は、sourceを確定して保存し、保存後にfrontmatterのsourceが確定値と一致することを確認している