repo/
  README.md
  .gitignore
  .env.example

  docs/
    rules/
      index.md
      workflow.md
      testing.md
      security.md
      coding.md

  prompts/
    launch.md
    onboard.md
    think.md
    spike.md
    implement.md
    test.md
    review.md
    retrospect.md

  tasks/
    current.md
    20251228-example-task.md

  experiments/
    README.md
    20251228-example_spike.md

  test-data/
    README.md
    golden/
      README.md
      case01_input.json
      case01_expected.json

  src/
    core/
    adapters/
    app/

  tests/
    unit/
    integration/

# Secrets
.env

# Logs & temp
*.log
*.tmp
*.bak
*.swp

# OS
.DS_Store
Thumbs.db

# Language/runtime (adjust as needed)
__pycache__/
.pytest_cache/
node_modules/
dist/
build/
coverage/

# Copy to .env (DO NOT COMMIT .env)
# Example:
# API_BASE_URL=https://example.com
# API_TOKEN=replace_me

# AI主導開発（プロンプトドリブン開発）テンプレ

業務改善・自動化・小規模toCを、AIと一緒に高速に開発しつつ、
「再現性」「資産化」「暴走防止」を最小コストで担保するためのテンプレです。

---

## 目的
- 速く作る（AI活用）
- 壊れにくくする（最小の安全装置）
- 後で直せる（プロンプト/調査/期待値を資産化）
- ツールに依存しない（Web UI / IDE / CLI どれでも）

---

## 重要原則（最短）
- **期待値（入力→期待出力）は人間が確定**する（AIの循環参照を防止）
- **プロンプト・タスク計画・検証コードはコミット**する（再現性の要）
- 不明点は **実装前に `experiments/` でSpike（調査）**
- ルールは **入口＋分割**（`docs/rules/index.md` は短く保つ）
- Doneには **資産更新**（golden追加/実験追加/ルール更新/README追記）を含める

---

## AIに必ず渡すファイル（ツール非依存）
開始/再開時にAIへ渡す：
1) docs/rules/index.md
2) tasks/current.md

※自動読み込みに依存しません。Web UIなら貼り付け、IDE/CLIなら参照指示を出します。

---

## ワークフロー（安全装置付き）
1) Plan & Approve
- AIが tasks/current.md を作成/更新（たたき台）
- 人間が Acceptance（期待値）を確定し、ApprovalをAPPROVEDにする
- APPROVEDになるまで実装禁止

2) Spike（必要なら）
- 不明点は experiments/ に再現・調査コードを置く
- 結果を experiments/README.md に1行で残す

3) Implement & Test
- 変更は小さく（3〜5ファイル程度が目安）
- テスト枠組みはAIでもよいが、expected（期待値）は人間が確定した test-data を使う

4) Review & Commit
- 人間が git diff を確認（余計な変更を止める）
- Conventional Commits で意味のある履歴を残す

5) Retrospect & Update（Done条件）
- 次のどれか最低1つを実施：
  - goldenテストデータ追加
  - experiment（再現/調査）追加
  - docs/rules または README を更新
- tasks/current.md を日付付きに保存（tasks/YYYYMMDD-*.md）

---

## Troubleshooting
### AIが勝手に実装を始める
tasks/current.md の Approval が APPROVED か確認。WAITING の場合は実装禁止。

### テストは通るのに仕様がおかしい
expected がAI起点になっていないか確認。test-data/golden/*expected* は人間が確定する。

### 依存ライブラリの挙動がわからない
experiments/ に Spike を作って観測してから本実装へ。

### .envをコミットしそうで怖い
.gitignore に .env が入っているか確認。.env.example のみコミットする。

### GitHub操作の自動化（任意）
gh CLI を使うなら認証が必要：
- ローカル：gh auth login
- CI/コンテナ：GH_TOKEN をセットして gh auth status で確認

# AI Working Agreement (Index)

## Read order (start/resume)
1) tasks/current.md
2) docs/rules/workflow.md
3) docs/rules/testing.md
4) docs/rules/security.md (if touching auth/data/secrets)
5) docs/rules/coding.md

## Hard rules (must follow)
- Do NOT code until tasks/current.md shows `Approval: APPROVED`.
- Human owns expected outputs (golden data). Do not invent expectations.
- If behavior is unclear, create a Spike under experiments/ before implementing.
- Never commit secrets (.env is forbidden). Use .env.example only.
- Touch only files related to the current task.
- Use Conventional Commits. Every commit should be meaningful.

# Workflow Rules (Small Project)

## Phases
1) Plan & Approve
- Generate/Update tasks/current.md
- Wait for human approval (APPROVED)

2) Spike (optional)
- Add experiments/ repro or investigation code
- Record result in experiments/README.md (1 line is enough)

3) Implement & Test
- Small changes per step (3-5 files, reasonable diff)
- Add/Update tests and/or test-data

4) Review & Commit
- Human checks git diff
- Conventional Commits

5) Retrospect & Update (Done requirement)
- Add at least one of:
  - new golden test-data case, or
  - new experiment/repro, or
  - rule update in docs/rules/ or README
- Archive tasks/current.md into tasks/YYYYMMDD-*.md

# Testing Rules

## Source of truth
- Truth = tests/ + test-data/
- Expected outputs (golden) are HUMAN-OWNED.

## Human-owned artifacts
- test-data/golden/*_expected.*  (or snapshots)
- tasks/current.md Acceptance section

## AI responsibilities
- Create test harness and assertions that compare actual vs human-provided expected.
- Do NOT modify expected outputs unless explicitly instructed by human.

## When adding a feature/fix
- Add/Update at least one golden test-data case.
- Cover boundaries and error cases (empty, null, malformed, large input).

## Anti-cheat rules
- Avoid writing tests that only mirror current implementation.
- Prefer black-box tests using golden input/output.

# Security & Privacy Rules (Small project baseline)

## Secrets
- Never commit .env. Only commit .env.example.
- No secrets in code, comments, tests, or logs.
- If a secret is found, STOP and warn the user.

## Data handling
- Do not add real customer/user data to repo.
- Use masked or synthetic datasets in test-data/ if needed.

## Token usage (optional tools)
- If using gh CLI, authentication is required:
  - local: `gh auth login`
  - CI/container: set `GH_TOKEN` and verify `gh auth status`
- Keep scopes minimal. Prefer read-only scopes unless needed.

## External tools / integrations
- Avoid introducing new external agents/tools without noting risks in tasks/current.md.

# Coding Rules

## Structure
- src/core: pure logic (no I/O)
- src/adapters: external I/O (API/DB/files)
- src/app: entrypoints (CLI/HTTP/job)

## Change scope
- Only edit files needed for current task.
- If broader refactor is needed, propose it in tasks/current.md and wait for approval.

## Style
- Keep functions small and single-responsibility.
- Prefer explicit error handling for external calls.

## Commit messages (Conventional Commits)
- feat: ...
- fix: ...
- refactor: ...
- test: ...
- docs: ...
- chore: ...

あなたは開発計画を作るアシスタントです。
次を読んで、tasks/current.md を作成または更新してください。

読む順番:
1) docs/rules/index.md
2) README.md
3) 既存の tasks/current.md（あれば）

出力要件:
- tasks/current.md は「人間が承認する計画書」です。
- 先頭に Goal / Non-goals / Acceptance(Human-owned) を置いてください。
- Plan は「AIが1回のコンテキストで扱える粒度」で分割してください：
  - 変更対象ファイル 3〜5 個程度
  - 差分が大きくなる場合は分割
- 不明点がある場合は Spike を Plan に入れ、experiments/ に出す前提で書いてください。
- Approval は必ず `WAITING` にしてください（人間がAPPROVEDに変えるまで実装禁止）。
- 期待出力（expected）は人間が確定するので、勝手に作らず「人間が記入する欄」を残してください。

作業を再開します。次を実行してください。

1) docs/rules/index.md と tasks/current.md を読み、現在の状況を要約する
2) 次にやるチェック項目を tasks/current.md から 1つ選ぶ（ApprovalがAPPROVEDであること）
3) その1項目の「影響ファイル候補」「実装方針」「確認方法」を短く提示する
4) まだコードは書かない（ここでは計画だけ）

次のサブタスクについて、実装前の方針を短くまとめてください。

- 変更する責務（core/adapters/appのどこか）
- 例外・境界条件
- 依存が不明なら Spike が必要か
- テストデータ（golden）で何を追加すべきか（期待値は人間が書く前提）

Spike（調査）を行います。

- experiments/YYYYMMDD-<topic>.* を作る想定で、調査手順と期待する観測結果を整理してください。
- 何が分かれば本実装に進めるか（Go/No-Go条件）を書いてください。
- 結果メモを experiments/README.md に追記する文案も出してください。

実装に入ります。ルール:

- tasks/current.md の APPROVED 範囲だけを実装する
- 変更ファイルは最小限（3-5ファイル目安）
- 期待値（test-dataのexpected）は人間が確定するまで変更しない
- 外部I/Oは adapters に閉じ込める
- 実装後に「どう確認するか（コマンド/観測点）」を提示する

テストを整備します。

- tests/ 側のテストコード（比較の枠組み）を作る
- test-data/golden の input/expected を読む形にする
- expectedの中身は人間が用意する前提なので、プレースホルダ扱いにする
- 境界/異常系のケース追加提案をする（ただし期待値は作らない）

レビュー準備をします。

- 変更したファイル一覧を出す
- 想定外の変更が混ざっていないか自己点検する
- 仕様（Acceptance）に対して満たしている/いないを表で示す
- コミットメッセージ案を Conventional Commits で提案する

振り返りをして、資産化してください。

- うまくいったこと / いかなかったこと
- 次回同種タスクで守るべきルール（docs/rulesのどこに追記すべきか提案）
- 追加すべき golden test-data ケース、または experiments の再現コード案
- tasks/current.md を tasks/YYYYMMDD-<short>.md に保存するためのリネーム案

# Goal
（人間が書く）このタスクで達成することを1〜3行で。

# Non-goals
（人間が書く）今回やらないこと。スコープ逸脱を防ぐ。

# Acceptance (Human-owned)
※期待値は人間が確定する。AIは作らない。
- Case01: input = test-data/golden/case01_input.json -> expected = test-data/golden/case01_expected.json
- Case02: input = ... -> expected = ...

# Plan (AI drafts, Human approves)
- [ ] Spike: （必要なら）依存/既存コードの挙動確認を experiments/ に追加
- [ ] Implement: src/... を変更（対象ファイル：）
- [ ] Test: tests/... を追加（golden比較）
- [ ] Review: 変更点サマリとコミットメッセージ案作成
- [ ] Retrospect: goldenケース追加 or ルール更新 or experiment追加（Done条件）

# Notes
- 制約、落とし穴、メモ

# Approval
Status: WAITING
Approved by:
Approved at:

# experiments/

依存ライブラリの挙動確認、バグ再現、境界条件の確認などを置きます。
ここは「動くドキュメント」です。使い捨てにしません（コミット対象）。

## Index
- 20251228-example_spike.md: 例

# Spike: Example

目的:
- ライブラリXの入力フォーマットを確認する

Go/No-Go:
- 入力Aで例外が出ない
- 入力Bでこの形式の出力になる（観測）

結果:
- （実行後に追記）

# test-data/

人間が確定する「期待値」を置きます。
AIの循環参照を防ぐため、expectedは人間がレビューして確定します。

- golden/: ブラックボックスの入力/期待出力ペア

# golden test-data

命名:
- caseNN_input.*
- caseNN_expected.*

運用:
- expectedは人間が確定する（AIが勝手に作らない）
- 境界/異常系のケースを追加する

{
  "example": "input"
}

{
  "example": "expected"
}