specsfy-02-backlog

バックログを洗練し、掘り下げる

必須の準備

このスキルを実行する前に、プロジェクトのルートで必ず $specsfy-setup を読み込んでください。自動ハンドオフの場合は、このステップの前に再度読み込んでください。会話内で確認済みのルートを再利用し、セットアップで未解決事項が示された場合は先に進まないでください。

対話モード

対話モード：perguntas。 質問を作成する前に、.specsfy/Spec.md の Contrato de perguntas numeradas を必ず読み、適用してください。

曖昧な入力を理解しやすいバックログ項目に変換し、意図に仕様化が必要な場合は、テスト可能なブリーフを作成するまで判断を深めます。これはフレームワークの連続する第2段階です。バックログを規範的な情報源に変えることなく、記録、洗練、発見をまとめて行います。

会話をオーケストレーションする

この段階を完了したとき、または別の段階の作業を検出したときは、Pendência detectada: <descrição> — ação: resolvendo nesta etapa と通知し、その作業がこの段階の範囲内であれば解決してください。担当の切り替えが必要な場合は、Transição automática: $specsfy-02-backlog → $<destino> — motivo: <motivo> — resultado esperado: <resultado> と通知し、確認を求めたりコマンドを繰り返したりせず、直ちに移行先のスキルを読み込んでください。同じ会話の中で続行します。

この段階に必要な修正を行った後は、Retomada automática: $<destino> → $specsfy-02-backlog — pendência resolvida: <resultado> と通知し、直ちにこの段階に戻ってください。循環を避けるため、ハンドオフのたびに状態を再評価します。ハンドオフに確認は不要ですが、機微な操作には引き続き個別の許可が必要です。

重複と関連情報を検索する

1. ユーザーの依頼から派生する用語を抽出します。ドメイン名と、会話内ですでに使われている明らかな同義語も含めてください。
2. 項目を作成または更新する前に、次の場所でこれらの用語を検索します。
   • specs/inbox/*.md；
   • specs/backlog/*.md；
   • specs/<estado>/*/spec.md；
   • docs/**/*.md。
3. 妥当そうな検索結果のみを読み、各関連性を分類します。
   • 重複の可能性：問題、対象者、結果、コンテキストが実質的に同じ。
   • 関連バックログ：補完項目、依存関係、または先行項目。
   • 関連仕様：項目を制約する、定義済みまたは実装済みの動作。
   • 関連ドキュメント：プロジェクトの用語、規則、またはコンテキスト。
4. 重要な一致項目をパスとともに提示します。重複の可能性がある場合は、項目を更新するか、実質的な違いを記録するかをユーザーに確認してください。
5. 役立つ情報源を、相対パスと関連性の種類を添えて Referências relacionadas に記録します。見つかった判断を、ユーザーが述べた内容として扱わないでください。

回答によって用語、問題、対象者、結果、またはコンテキストが実質的に変わった場合は、検索をやり直してください。

MVP で確定した回答を再利用する

バックログの元が MVP.md から派生したマイルストーンである場合、質問を作成する前に次の作業を行います。

1. specs/milestones/M01.md と、バックログの Registros confirmados no MVP セクションを読みます。記録されたパスが利用可能な場合は、元の MVP.md も開きます。
2. 問題、対象者、成果、範囲、ユーザージャーニー、ルール、データ、連携、制限、受け入れ基準に答える記述をすべて抽出します。
3. その記述をバックログの該当フィールドに正規化した回答として反映し、出典として記述箇所とパスを保持します。
4. ファイルで質問と同じラベルが使われていなくても、回答が MVP に明記されていれば、その質問は回答済みとして扱います。
5. 実際の不足、重大な曖昧さ、または MVP、関連資料、現在の会話の間の矛盾についてのみ質問します。

MVP にすでに記載されている回答について、確認、選択、言い換えを求めないでください。再利用した内容を簡潔にまとめてもかまいませんが、新たな質問のラウンドには進みません。妥当な解釈が複数ある場合は、その曖昧さだけを提示し、該当する記述を引用してください。

インポート時に Default aplicado automaticamente が記録されている場合、示された根拠が明示的または明白であれば、確定したものとして扱います。質問に対して MVP と整合する選択肢が 1 つしかない場合は、その選択肢を適用して正規化を記録し、次の不足に進みます。実際の選択が必要な場合、複数の解釈が可能な場合、または情報源から確定できない提案の場合に限り、選択肢を提示します。ヒアリングでは、MVP から安全に回答または推測できなかったことだけを質問します。

最低限の情報を確実に収集する

1. 会話または specs/inbox/<data-hora>-<slug>.md で受け取った元の表現を保持します。宣言、推論、未解決事項を分けて記録します。
2. コンテキストから次の点が明らかになるか確認します。
   • 認識されている問題
   • 影響を受ける人、または恩恵を受ける人
   • 期待される成果または価値
   • 類似の依頼と区別するのに十分なコンテキスト
3. 不足、曖昧さ、矛盾がある場合は、影響が最も大きい実際の不足を 1 つ選び、各ラウンドで番号付きの質問を必ず 1 つだけ作成します。
4. 各回答の後に不足事項を再評価します。項目を固定の質問票にしたり、すでに提供された情報を繰り返し尋ねたりしないでください。
5. 必須項目に不足または曖昧さがある間は、ファイルを作成または更新しないでください。回答者が分からない場合は、内容を捏造せず、不足している点を説明します。

最低限の情報収集では、技術的な解決策、完全な受け入れ基準、優先度は必要ありません。これらの情報は、詳細化の過程で充実させることができます。

項目を作成または更新する

1. 記録せずに検討だけをしたい場合は、話し合いを行い、書き込む前に確認します。
2. 該当する項目が存在する場合は、ID を変更せずに更新し、以前の表現を保持します。
3. 出所が specs/inbox/ の場合は、そのパスを Referências relacionadas に記録します。キャプチャ内容は変更も削除もしないでください。
4. 新しい項目を作成するには、次を実行します。

node <diretório-da-skill>/scripts/iniciar_backlog.mjs \
  --title "<título curto>" \
  --idea "<formulação original>" \
  --problem "<problema percebido>" \
  --person "<pessoa afetada ou beneficiada>" \
  --result "<resultado ou valor esperado>" \
  --context "<contexto que distingue a ideia>" \
  [--slug <slug>] [--root <raiz>]

5. スクリプトが出力する絶対パスを使用します。.specsfy/templates/custom/Backlog.md が優先され、存在しない場合は .specsfy/templates/Backlog.md が使用されます。

整理と優先順位付け

構成、詳細化、優先順位付け、準備状況の評価を行う際は、references/backlog-quality.md を読みます。

• 判明している場合は、プロダクト → エピック → 機能 → 項目に分類します。
• タイプと優先度を混同せず、エピック、ストーリー、ルール、技術、改善などのタイプを使用します。
• 価値、リスク、依存関係、緊急性、工数、ブロッカーの解消、不確実性に基づいて順序を決めます。すべてを高優先度にしないでください。
• リスクと複雑さに応じてフィールドを詳細化します。認証、決済、権限、プライバシー、非同期処理では、特に慎重に扱います。
• インターフェースの解決策より、観察可能な振る舞いを優先します。
• 重要な品質属性は、測定可能なものにします。
• 曖昧さの軽減に役立つ場合は、リスト、フロー、シナリオ、マトリクスを使用します。

仕様を深掘りする

ユーザーから仕様の深掘り、昇格、作成を求められた場合：

1. specs/inbox/ の入力、specs/backlog/ の項目、または指定された仕様を読みます。候補が複数ある場合は、どれを深掘りするか尋ねます。
2. 問題、ユーザー、認識される成果を一文で要約します。
3. 決定済みの内容と、スコープ、体験、セキュリティ、データ、テスト、アーキテクチャを変える可能性がある内容を分けます。
4. references/discovery-map.md を読んで関連する質問を選びます。マップを機械的にすべて確認しないでください。
5. 成果物にユーザー向けインターフェースが含まれる場合は、.specsfy/Spec.md の インターフェース体験の契約 を読み、インターフェース を独立したディスカバリー領域として扱います。画面、情報の流れ、メニューと主要なナビゲーション、フォーム、サイドパネルやモーダルなどのアクションパターン、構成について尋ねます。実際に選択肢がある場合は、ユーザーに代わってパターンを選ばないでください。質問する前に、中央契約で指定されたスタックと既存画面を確認します。既存のシステムがある場合は、影響範囲を調べ、新しい成果物が維持または変更するナビゲーション、コンポーネント、コンテンツ、権限、状態を記録します。これを基に、既定で新しいライブラリを提案するのではなく、既存の構成に合った選択肢を提示します。「インターフェース」という言葉が使われていなくても、画面、ダッシュボード、一覧、フォーム、ビジュアルフロー、CRUD の作成または変更の依頼があれば、この領域を有効にします。この領域を確定する前に $specsfy-specialist-interface-experience を読み込みます。このスペシャリストが現行システムの分析と後続スペシャリストを調整します。ジャーニーを確定する前に $specsfy-specialist-ux-design を、構成を確定する前に $specsfy-specialist-ui-design を読み込みます。React と Tailwind のスタックで ReUI を使用している場合は、ディスカバリーで宣言されたすべての CRUD に Data Grid または List、Filters、Form、Dialog または Sheet、および該当する ReUI の状態を記録します。この領域を確定する前に $specsfy-specialist-reui を読み込みます。
6. ../specsfy-03-specify/references/mcr-10.md を読み、最初の質問をする前にカテゴリ分析を内部で行います。
7. 技術や専門分野に追加のコンテキストが必要な場合に限り、references/specialists.md を読みます。

適応型ディスカバリーを進める

領域ごとに最大 8 問までのサイクルを実行します。

1. 各ラウンドの前に、入力内容、確認済みの決定、蓄積されたコンテキスト、新しい回答を、MVP の記録とあわせて読み直します。
2. 未解決事項と依存関係を再分類します。該当する未解決事項があり、上限まで質問できる場合は続行し、それぞれが決定済み、該当なし、または根拠によって解決された時点で終了します。
3. impacto × incerteza が最も大きい実際の未解決事項を選び、中央の契約に従ってラウンドを提示します。
4. 各回答の原文、正規化した決定、その影響を記録します。最初の手順に戻り、固定の質問リストは再利用しません。

質問が 8 問に達したら、要約を提示し、未解決事項を記録して終了します。サイクルを再開するのは、本人が明示的に追加の質問を求め、回答したい質問数を伝えた場合に限ります。

最初のラウンドから各質問に Avançar を含めます。本人がこの選択肢を選んだ場合：

• 次のラウンドでは、その領域の質問を完全に終了するのか、後で回答するのか、今すぐ回答に戻るのかを確認します。
• 確認は、そのラウンドで番号付きの質問を 1 つだけ提示して行います。
• 終了する場合は Área encerrada pelo usuário: <área> と記録し、明示的に再開されない限り、再度質問しません。
• 延期する場合は Área adiada pelo usuário: <área> と記録し、未回答の項目を再開できるよう保持します。
• 推論によって回答を補いません。
• 該当する未解決事項が残る場合は、Status: Draft と Definition Gate: Pending を維持したまま、依頼されたハンドオフを可能にします。

会話中は、次のことを行います。

• 労力を減らせる場合は、少なくとも 3 つの番号付き選択肢を提示し、短い理由を添えて 1 つを推奨します。
• 自由形式の回答を受け付け、再分析に反映します。
• 元の用語を保持し、申告、推論、仮説、決定、矛盾、未解決を区別します。
• 要約によって運用上の意図を確認します。
• 10 個のカテゴリを列挙したり、各カテゴリをそのまま質問にしたりしません。

問題、関係者、成果、範囲、ユーザージャーニー、障害、制限、ルール、データ、セキュリティ、プライバシー、パフォーマンス、アクセシビリティ、既存の制約、客観的な受け入れ基準と成功の兆候を十分に網羅します。

人が使うインターフェースの場合は、画面、ナビゲーション、情報の流れ、メニューとメインナビゲーション、フォームのフィールドと検証、各アクションを開始する方法、要素の配置、状態、キーボード操作についても扱います。仕様によって CRUD がエンドポイントに矮小化されたり、プロジェクトで使われている技術が置き換えられたりしないよう、回答のテキストと確認された技術スタックをバックログに記録します。

ユーザージャーニーが、保存、参照、共有、削除される情報に依存する場合は、brief の完成を宣言する前に、$specsfy-data-discovery への自動移行を告知します。技術設計の会話に変えることなく、.specsfy/DATABASE.md に確認済みの記録をコンテキストとして引き継いでバックログに戻ります。

項目を維持する

specs/backlog/<NNNN>-<slug>.md をそのまま使用し、次の状態を維持します。

• 項目が記録されただけの間は Status: Captured。
• 詳細化またはディスカバリーの間は Status: Refining。
• brief が十分な状態になったら Status: Ready for specification。
• 派生した spec が存在するようになったら Status: Promoted。

タイトルの下にある表にメタ情報を記載します。優先度、期限、ステークホルダー、解決策、根拠を捏造しません。Pronto para desenvolvimento は診断としてのみ使用し、実装の許可としては使用しません。

完了

Brief pronto para especificarを提示します。次の内容を含めてください。

1. 課題と目標。
2. 関係者。
3. 対象範囲と対象外の範囲。
4. ジャーニーと主要なルール。
5. Given／When／Then 形式の受け入れ基準。
6. 技術上の制約と品質要件。
7. 前提。
8. 未決事項、または Nenhuma lacuna aplicável。
9. 曖昧な用語と確認済みの推論。

登録の許可を得たら、バックログ項目を更新します。briefが十分な内容になったとき、またはユーザーが avançar を選んだときは、そのステップが承認済みの仕様に対する後発の変更を理由に呼び出された場合、自動的に $specsfy-update-spec に戻ります。初期定義を作成または統合する場合は、$specsfy-03-specify を呼び出します。avançar の場合は、部分的なbriefを提示し、Definition Gateを通過できない原因となる不足事項を伝えます。

制限事項

• Inboxのエントリを変更または削除しないでください。
• spec.md、タスク、research、テスト、コードを作成しないでください。
• 関係者、インテグレーション、制約、決定事項を捏造しないでください。
• 技術上の仮説を要件に変えないでください。
• 確認なしに既存の項目を移動または削除しないでください。