FatRicePaddyyyy ユーザー文脈の蓄積
ゴール: ユーザーが特別に指示しなくても、収穫できそうな知見があるときだけ プロジェクトルートの PROFILE/ に 新しい md ファイル として残す。毎ターン必須ではない。hooks は使わない。
ドメイン知識と開発の暗黙知は必ず入れる。 業務用語・制約・仕様・「このプロダクト／チームではこう」、設計〜運用の勘が出たら、他の信号が薄くても収穫対象にする。
- 置き場: PROFILE/（リポジトリ直下）
- sub-agent 用: agents/harvester.md
- 観点の詳細: references/dev-tacit-knowledge.md
Hard rules
- 根拠があるものだけ — 発言・明示ルール・採用した成果物のみ
- 原文優先 — 短い方針は verbatim
- 矛盾は確認 — 既存ファイルと食い違うときだけ聞く（既存を勝手に上書き・削除しない）
- 薄い要約 — 1 ファイルは 1 知見（または密接な一塊）。本文は短く。手順全文は別 skill へ
- 秘密を書かない
- 本業を邪魔しない — 収穫は本回答のついで。無ければスキップ。進捗報告はしない（矛盾確認以外）
- 置き場所 — 常にリポジトリ直下の
PROFILE/。単一のPROFILE.mdやskills/user-context/配下には置かない - 追記ではなく新規ファイル — 収穫のたびに新しい
.mdを作る。既存ファイルの編集は誤記修正や矛盾解消の合意時のみ - ドメイン知識・開発暗黙知は必須収穫 — 一般論より優先。出てきたらスキップしない
いつ収穫するか
次のような信号が今回のやり取りに含まれるときだけ動かす。なければ PROFILE/ に触れない。
ただし ドメイン知識と開発の暗黙知は見落とし禁止（他が無くてもファイル化する）。
- ドメイン知識（必須）: 業務ルール、用語の定義、エンティティ関係、「うちでは〜」、仕様の前提、禁止事項、境界ケース、業界固有の約束
- 開発の暗黙知（必須）: 下表の各要素に当てはまる経験知・勘・「なぜそうするか」
- 優先・評価軸（「これが大事」「チェックして」）
- 開発手法・プロセス（「こうやって」「分割してから」）
- 品質基準・やらないこと
- ツール・ファイルの置き場所
- 記事やプラクティスを skills 化した／採用した
- コミュニケーション好み
明示の「PROFILE 更新」「まとめて」があれば、そのときまとめて収穫し、作ったファイル名だけ短く報告してよい。
開発の暗黙知（収穫観点）
会話を次の要素でスキャンする。当てはまったら種別 開発暗黙知（必要ならサブ種別）で残す。
| 要素 | 拾うもの（例） |
|---|---|
| 要件・ドメイン | 仕様の行間、本当の優先、例外、「言わなくても当然」、用語の現場意味、やってはいけない経緯 |
| 設計 | トレードオフの嗅覚、境界の切り方、安定／変わりやすい箇所、公式に無いアーキ慣習 |
| 実装 | コードの匂い、名前のセンス、「後で痛い」局所知、社内基盤・ライブラリの地雷 |
| デバッグ・品質 | 症状→原因の絞り方、再現の取り方、テストを厚くする判断（境界・回帰） |
| レビュー・協働 | Must にする感覚、通じる指摘の言い方、誰に何を聞くと早いか |
| プロセス運用 | 見積・粒度・レビュー可能な PR 感、リリース／ロールバック判断、表向きと実際の通し方 |
| 運用・障害 | 前兆の読み、一次切り分けの手癖、顧客・現場固有の対処順 |
| 負の知識 | 失敗した案、アンチパターン、「触るな／炎上する」、暗黙の撤退線 |
専門家の勘を言語化するとき有用な問い: 何を手がかりにしたか / 次に何が起きると見たか / 優先目標は何か / 即座に浮かんだ手は何か。
ファイル命名
PROFILE/YYYY-MM-DD-<slug>.md
slug: 英小文字・ハイフン、内容を示す短い語（例:logical-coherence,api-boundary-convention）- 同日同 slug なら
-2,-3… または時刻を足すYYYY-MM-DDThhmmss-<slug>.md
各ファイルの形
# 短いタイトル
- **種別**: ドメイン知識 | 開発暗黙知 | 気にしていること | 開発手法 | 品質基準 | コミュニケーション | 置き場所 | やらないこと | 関連スキル
- **サブ種別**: 要件・ドメイン | 設計 | 実装 | デバッグ・品質 | レビュー・協働 | プロセス運用 | 運用・障害 | 負の知識（開発暗黙知のとき）
- **内容**: …
- **出典**: 会話 YYYY-MM-DD / 要旨
- **関連スキル**: `skill-name`（あれば）
収穫のやり方
PROFILE/を一覧し、重複しそうな既存がないかざっと見る- 上記「開発の暗黙知」表＋ドメイン知識でスキャンし、知見ごとに 新規ファイルを作成（1 収穫で複数可）
- 短い 1–2 件なら親が直接
Writeしてよい - まとまっていそう / 会話が長いなら Task（
generalPurpose、run_in_background: true、可能ならresume: "self"）で agents/harvester.md に従わせる。description:知見収穫 - ユーザー向け本文には収穫の話を混ぜない
大きな計画・設計の前は PROFILE/ 内の最近・関連ファイルを読み、方針に反する提案をしない。
やらないこと
- hooks / 定期 follow-up / 毎入力の収穫保証
- 「PROFILE 更新して」を待つこと（信号があるのに放置）
- 収穫のたびに「更新しました」と長々報告すること
- ユーザーが言っていないベストプラクティスの追加
- ルートの単一
PROFILE.mdや skill 配下への集約 - 既存 PROFILE ファイルへの無言マージ（履歴が潰れる）