33 lines
1.4 KiB
Markdown
33 lines
1.4 KiB
Markdown
# よくある詰まりポイント
|
||
|
||
## AIの出力がぶれる
|
||
|
||
仕様（project-brief）の曖昧な部分を埋める。
|
||
特に「スコープ外」が定義されていないと、AIが勝手に機能を追加しやすい。
|
||
|
||
プロンプトの「変更してはいけない範囲」に明示的に書くと安定する。
|
||
|
||
## レビューAIごとに指摘が違う
|
||
|
||
`30_review.md` の構造化フォーマット（重大度・根拠・影響・修正案）を
|
||
必ず使うことで、AIによるブレが小さくなる。
|
||
|
||
仕様外の提案は「Nice to have」として分けてもらうと判断しやすい。
|
||
|
||
## どのタスクから始めればいいかわからない
|
||
|
||
依存関係がないタスク（「依存」列が `-` のもの）から始める。
|
||
迷ったらAIに「どれから始めるのが最も安全ですか」と聞いてよい。
|
||
|
||
## 途中でアイデアが変わった
|
||
|
||
`project-brief` を更新してから、影響するタスクを見直す。
|
||
すでに実装済みのタスクを壊す変更は、新しいタスクとして分けて追加する。
|
||
|
||
## APIキーをどこに書けばいいかわからない
|
||
|
||
`.env.example` を参考に `.env` ファイルを作って、そこに書く。
|
||
`.env` は `.gitignore` に含まれているので、GitHubに上げても漏れない。
|
||
|
||
コードの中には変数名だけ書く（例: `process.env.API_KEY`）。
|