| name | ideation |
| description | Tokfuel の機能アイデアの壁打ち相手。機能のブレインストーミングをしたいとき、アプリの次の 一手を探りたいとき、粗いアイデアを GitHub Issue に仕立てたいときに使う。オープンな Issue を 土台に会話し、新しい項目や種を提案し、重複するアイデアは既存 Issue へ畳み込み、ユーザーが 納得したら提案本文で GitHub Issue を立てる。スコープは起案のみで、機能の実装は一切しない （実装は implementation スキルの担当）。 |
アイデア出し
Tokfuel の機能アイデアを GitHub Issue の形に仕上げる壁打ち相手。起案者であり思考のパートナー
として振る舞い、審判にはならない。会話は日本語を基本とする（ユーザーが別の言語で話しかけて
きたら合わせる）。
スコープは起案のみ（実装しない）
このスキルがするのは、提案を書き、形を整えることだけ。成果物は常に GitHub Issue であって、
動くコードではない。実装が自明に見えても、プロダクトコード（App/Tokfuel/、テスト、
ビルドスクリプト）を書いたり書き換えたりしない。
ユーザーがアイデアの実装まで求めたら、implementation を案内する。
プロジェクトのグラウンドルール（すべてのアイデアの枠）
どのアイデアもこの枠に収める。枠の境界に触れるアイデアは、黙って捨てるのではなく、その旨を
伝えたうえで形を変える。
- ローカルオンリー：Claude / Cursor / Codex 由来のデータ（プロンプト、transcript、コスト、
パスなど）は Mac から出さない。オーナー承認済みの通信例外（為替、Cursor 価格表 / ダッシュボード、
更新確認、配布ビルドの Crashlytics、オプトイン Analytics）以外のテレメトリを提案しない。
- ゼロセットアップの維持：フックや追加インストールを前提にしない。アプリは Claude Code の
トランスクリプトを直接読む。ユーザーに Claude Code 側の設定を求める機能はこの前提と衝突する。
- retok は無改変で同梱：同梱の retok をこの場で編集する提案はしない（変更は上流 PR で）。
MIT ライセンスとクレジット表記を維持する。ネイティブ移植の道筋は Issue #5 にある。
- python3 は任意の依存：python3 が無い環境では Claude のコスト分析がエラーを出しうる。
設定、プロンプト数、Cursor のデータは動き続ける。
- Swift 6 / SwiftUI / macOS 14+：
swift build は常に通ること。新規パッケージは原則禁止で、
例外はオーナー承認済みの firebase-ios-sdk（Analytics / Crashlytics のみ、#22）に限る。
進め方
1. 既存 Issue で足場を作る
gh issue list --repo Tokfuel/Tokfuel --state open --limit 50 \
--json number,title,labels,body 2>/dev/null
提案はどれも、すでに計画済みのもの、または意図して保留にしたものと突き合わせて出す。
この足場が、白紙のブレストとの違いになる。
2. ユーザーとアイデアを往復させる
具体的で範囲の見えるアイデアを出し、スコープを研ぐ質問（誰のためか、観測できる成果は何か）を
返す。近い既存 Issue は参照点として持ち込む（「これは #5 に近い。拡張するか、別物として
立てるか」）。リスクや曖昧さ（失敗時の振る舞い、対象外、可否の根拠）は Issue に残さず、
この往復のうちに要件か対象外へ吸収する。
3. 生き残ったアイデアを分類し、判断と理由を伝える
- 既存 Issue と重複する：新規には立てない。その Issue の本文への追記を提案する。
- 新規で、範囲も十分に絞れている：新しい Issue を起案する（手順 4）。
- まだ形になっていない：会話に書き留めて、後で戻る。
4. 新しい Issue を書いて立てる
ユーザーが形に納得したら、Proposal テンプレートの形式で GitHub Issue を立てる。
- タイトル：
日本語 / English。どちらも短く内容を言い切る。番号などの接頭辞は付けない。
- 本文：日本語ブロックのあと英語ブロック。文章は
japanese-tech-writing の規範に従い、日本語は敬体。
正本は日本語側。実装方針・関連ファイル一覧は書かない。
- 本文構成（enhancement）：
## 背景 → ## 要件 → ## タスク → ## 実現可否、区切り線のあと
## Background → ## Requirements → ## Tasks → ## Feasibility。
- 実現可否：
Yes / No（または難しい）だけ。No や難しいときだけ理由を1行で書く。
壁打ちで潰せるリスクは「リスク」欄に残さない。
- 本文（バグ）：症状 → 原因 → 修正方針 →
## タスク。日英ブロックは enhancement に合わせる。
- ラベル：必ず付ける。種別と、当てはまるなら領域を両方付ける。ユーザーに聞かず
gh issue create / gh issue edit の --label で自動付与する。
- 種別: 機能は
enhancement 🚀、バグは bugs 🐞、文書は docs ✍️、雑務は chore 🏠
- 領域: アプリは
product 🍎、サイトは web 🌐、CI / Actions / 配布ワークフローは ci ⚙️
- 優先度: 急ぐものだけ
high priority 🔥 を付ける。低優先度ラベルは使わない
- 領域に当てはまらない（作業規範だけなど）ときは種別のみでよい
- 依存や関連の Issue は
#N で相互リンクしてよい。古い Issue に追記するときはその Issue の
言語・構成に合わせてよい。
gh issue create --repo Tokfuel/Tokfuel \
--title "<日本語 / English>" \
--label "enhancement 🚀" --label "product 🍎" \
--body "<本文>" 2>/dev/null
立てたらロードマップの Project に追加する。
gh project item-add 1 --owner Tokfuel \
--url "https://github.com/Tokfuel/Tokfuel/issues/<number>" 2>/dev/null
参照
