# User Context

> 会話に収穫できそうな関心事・開発手法・好み・ドメイン知識・開発上の暗黙知があれば、 プロジェクトルートの PROFILE/ に新規 md として蓄積する。 Domain knowledge and development tacit knowledge must be harvested whenever they appear. Use when the user states priorities, constraints, workflows, domain facts/jargon/business rules, design/implementation/debug/review/ops intuition, placement rules, review/quality bars, or adopts a practice into skills — even without saying 「PROFILE更新」. Also use before planning, to read PROFILE/ and stay aligned. Do not use hooks; opportunistic harvest only when signals are present.

- Skill: `fatricepaddyyyy/user-context` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add fatricepaddyyyy/user-context`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fatricepaddyyyy/user-context/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: FatRicePaddyyyy (https://skillmd.com/u/fatricepaddyyyy)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fatricepaddyyyy/user-context

---


# ユーザー文脈の蓄積

ゴール: ユーザーが特別に指示しなくても、**収穫できそうな知見があるときだけ** プロジェクトルートの `PROFILE/` に **新しい md ファイル** として残す。毎ターン必須ではない。hooks は使わない。

**ドメイン知識と開発の暗黙知は必ず入れる。** 業務用語・制約・仕様・「このプロダクト／チームではこう」、設計〜運用の勘が出たら、他の信号が薄くても収穫対象にする。

- 置き場: [PROFILE/](../../PROFILE/)（リポジトリ直下）
- sub-agent 用: [agents/harvester.md](agents/harvester.md)
- 観点の詳細: [references/dev-tacit-knowledge.md](references/dev-tacit-knowledge.md)

## Hard rules

1. **根拠があるものだけ** — 発言・明示ルール・採用した成果物のみ
2. **原文優先** — 短い方針は verbatim
3. **矛盾は確認** — 既存ファイルと食い違うときだけ聞く（既存を勝手に上書き・削除しない）
4. **薄い要約** — 1 ファイルは 1 知見（または密接な一塊）。本文は短く。手順全文は別 skill へ
5. **秘密を書かない**
6. **本業を邪魔しない** — 収穫は本回答のついで。無ければスキップ。進捗報告はしない（矛盾確認以外）
7. **置き場所** — 常にリポジトリ直下の `PROFILE/`。単一の `PROFILE.md` や `skills/user-context/` 配下には置かない
8. **追記ではなく新規ファイル** — 収穫のたびに新しい `.md` を作る。既存ファイルの編集は誤記修正や矛盾解消の合意時のみ
9. **ドメイン知識・開発暗黙知は必須収穫** — 一般論より優先。出てきたらスキップしない

## いつ収穫するか

次のような信号が**今回のやり取りに含まれる**ときだけ動かす。なければ `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`

## 各ファイルの形

```markdown
# 短いタイトル

- **種別**: ドメイン知識 | 開発暗黙知 | 気にしていること | 開発手法 | 品質基準 | コミュニケーション | 置き場所 | やらないこと | 関連スキル
- **サブ種別**: 要件・ドメイン | 設計 | 実装 | デバッグ・品質 | レビュー・協働 | プロセス運用 | 運用・障害 | 負の知識（開発暗黙知のとき）
- **内容**: …
- **出典**: 会話 YYYY-MM-DD / 要旨
- **関連スキル**: `skill-name`（あれば）
```

## 収穫のやり方

1. `PROFILE/` を一覧し、重複しそうな既存がないかざっと見る
2. 上記「開発の暗黙知」表＋ドメイン知識でスキャンし、知見ごとに **新規ファイルを作成**（1 収穫で複数可）
3. 短い 1–2 件なら親が直接 `Write` してよい
4. まとまっていそう / 会話が長いなら **Task**（`generalPurpose`、`run_in_background: true`、可能なら `resume: "self"`）で [agents/harvester.md](agents/harvester.md) に従わせる。`description`: `知見収穫`
5. ユーザー向け本文には収穫の話を混ぜない

大きな計画・設計の前は `PROFILE/` 内の最近・関連ファイルを読み、方針に反する提案をしない。

## やらないこと

- hooks / 定期 follow-up / 毎入力の収穫保証
- 「PROFILE 更新して」を待つこと（信号があるのに放置）
- 収穫のたびに「更新しました」と長々報告すること
- ユーザーが言っていないベストプラクティスの追加
- ルートの単一 `PROFILE.md` や skill 配下への集約
- 既存 PROFILE ファイルへの無言マージ（履歴が潰れる）