pythia-spec

仕様を確定する

開始時に宣言：「pythia-spec を使用します。この依頼には、私ではなくあなたが決めるべき未決事項があります。」

**フェーズ：**学ぶ → 尋ねる — 適切な質問をするのに十分な知識を得て、仕様が確定するまで質問し、その後で初めて構築します

ほかのスキルは構築の連鎖を担い、仕様が確定してから始まります。このスキルが担うのはその前の段階です。エージェントが仕様をひそかに自分で確定してしまうと、流暢に間違ったものを構築してしまい、開発者が初めて異議を唱えられるのはコードができた後になります。その時点では、どの選択を変えるにも書き直しが必要です。

鉄の掟

SPEC DECISIONS BELONG TO THE DEVELOPER. YOU PROPOSE; THEY CHOOSE.

仕様か技術か？決定者を分ける線

仕様 — まず尋ねる	技術 — 自分で決め、根拠を示す
保存するもの：新しいテーブルか新しい列か、何を残して何を削除するか	名前と形式 — 既存の規約で決まります
ビジネス上の動作：有効期限、再試行回数、ロックアウト回数、許可されるユーザー	質問に答える辞書ビューまたはクエリ
セキュリティと監査のトレードオフ：トークンを削除するか、履歴を残すか	similar で見つけた既存パターンに従うこと
チャネルと範囲：メールか SMS か、どのテナントか、どの呼び出し元か	その種類の値について、プロジェクトのルールで指定されるデータ型
必須の規約から逸脱すること	pythia conventions またはコードベースで答えが得られるもの

経験則：**2 人のシニア開発者が、どちらも妥当な異なる動作を実装できるなら、それは仕様です。**コードベースまたは規約ですでに答えが得られるなら、それは技術上の判断です。自分で決め、根拠を示します。

ワークフロー

1. **適切な質問をするのに十分な知識を得ます。構築を始められるほどには学びません。**対象テーブルの cols と src、conventions、このプロジェクトでの解決方法を調べる similar を確認します。この手順の成果はコードではなく、より良い質問です。
2. **ひそかに決めてしまいそうな判断をすべて洗い出します。**テストとして、想定した実装をたどり、開発者が明示していない動作を選んだ箇所を記録します。
3. トレードオフと推奨案を添え、選択肢を一つずつ尋ねます。「どうしたいですか？」のような自由回答式の質問はしません。各選択肢で、何が必要になるかを説明します。 「SMS で OTP を送る場合、6 桁では推測されやすいため、試行回数カウンターとロックアウト用の列が必要になり、ドラフトとは異なるテーブルになります。」
4. **確定した仕様を数行で書き戻し、了承を得ます。**この段落がスコープになります。これは pythia-write における「開発者の文」です。この要約は省略できません。合意した内容そのものだからです。
5. 文書成果物を提示し、選択は開発者に委ねます。「仕様が確定しました。まず仕様ファイルと手順ごとの計画を作成しますか。それとも、すぐに構築しますか？」省略するという回答も有効です。その場合は一行で記録して先に進みます。必須なのは質問であり、文書ではありません。
6. **引き継ぎます。**いつもどおり、impact → write → apply の順です。

構築中に判断していることに気づいたら？

その箇所で止めます。コーディング中に新しい未決事項が見つかったら、それは新たな質問です。後から尋ねるのは容易ですが、最終報告で「これも決めておきました」と既成事実として提示するのは、このスキルが防ごうとしている失敗そのものです。

危険信号 — 次のように考えたら作業を止めてください

考え	実際のところ
「簡単なタスクだから、質問すると作業が滞る」	簡単な依頼ほど、仕様の見落としが多くなります。パスワードを忘れた場合のフローには、7つの仕様が含まれています。質問に3つ答えるのにかかるのは1分ですが、作り直しには午後いっぱいかかります。
「手抜きモードでは、質問で作業を止めないようにと言っている」	手抜きモードで短くするのは解決策であって、理解ではありません。仕様を確定することは、理解することです。
「選んだ内容は最終レポートで伝えよう」	その頃には、開発者にできるのは同意するか、やり直しを求めるかだけです。それは選択ではなく、請求書です。
「別のパックのブレインストーミングスキルで対応できる」	そのスキルが起動したなら、それに従ってください。何も起動していないなら、これが最低限の手順です。このキットは、ほかに何もインストールされていないことを前提としています。
「開発者が『とにかくやって』と言った」	それは開発者が認識していた判断事項に限られます。新たに見つかった判断事項も、引き続き開発者が決めることです。
「仕様ファイルが省略されているから、質問も省略してよい」	逆です。質問は必須で、文書だけが任意です。

このスキルを使わない場合

• 依頼内容が完全に明確な場合、または擁護可能な正しい振る舞いが1つに定まるバグの場合 — すぐに pythia-impact に進んでください。
• 開発者がすでに回答している場合 — 決着した内容は聞き直さず、変更された内容だけを再確認してください。
• 振る舞いをまったく変えないリファクタリングの場合。