specsfy-update-spec

既存の仕様を更新する

必須の準備

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

対話モード

対話モード：perguntas。 質問を作成する前に、.specsfy/Spec.md の 番号付き質問の契約 を読み、適用してください。

初期定義の後に生じた依頼を取り込み、変更を隠したり、規範となる情報源を重複させたり、行為やゲートについて利用者に把握を求めたりしないでください。

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

このステップを完了したとき、または別のステップの作業を検出したときは、 Pendência detectada: <descrição> — ação: resolvendo nesta etapa と通知し、その作業がこのスキルの範囲内であれば解決してください。担当範囲を引き継ぐ場合は、 Transição automática: $specsfy-update-spec → $<destino> — motivo: <motivo> — resultado esperado: <resultado> と通知し、確認を求めたりコマンドを繰り返したりせず、ただちに移行先のスキルを読み込んでください。同じ会話の中で続行してください。このステップで必要な修正を行った後は、 Retomada automática: $<destino> → $specsfy-update-spec — pendência resolvida: <resultado> と通知し、ただちにこのスキルに戻ってください。ハンドオフのたびに状態を再評価し、循環を避けてください。ハンドオフの確認を求めないでください。機微な操作には、引き続き個別の許可が必要です。

入力を確認する

1. 新しい依頼を解釈する前に、文字どおりの形で保持してください。
2. 正規の仕様を specs/<estado>/<NNNN>-<slug>/spec.md で特定し、そのメタデータ、要件、シナリオ、計画、タスク、ゲート、証拠を読み込んでください。
3. プロジェクトの指示、PROJECT.md、.specsfy/STACK.md、.specsfy/RULES.md、.specsfy/DATABASE.md、および該当するインデックス済みリサーチを読み込んでください。
4. 仕様に対する既存の Git 変更を調査し、今回の依頼によるものとして扱わないでください。
5. 仕様が存在しない場合は、未解決事項を通知し、概要レベルのアイデアであれば $specsfy-02-backlog を、スライスの作成意図がすでに明示されている場合は $specsfy-03-specify を読み込んでください。
6. 仕様がまだ Draft で、これまで一度も Definition Gate: Passed になっていない場合は、$specsfy-03-specify を読み込んでください。このスキルの対象は、すでに定義が進んでいる仕様の改訂のみです。

作成前に分類する

依頼によって動作、計画、または仕様間の境界が変わる可能性がある場合は、分類マトリクス を読んでください。

• 観測可能な影響を伴わない、取り消し可能な内部修正の場合、仕様は変更しないでください。タスクの証拠に評価を記録し、$specsfy-07-implement に戻ってください。
• 意味を変えない編集上の明確化の場合、ゲートを維持し、必要な文言のみを変更してください。
• 動作、受け入れ条件、スコープ、データ、セキュリティ、またはインターフェースの変更の場合は、アクト I から再開してください。
• ソリューション、タスク、またはテスト戦略のみの変更の場合は、アクト II から再開してください。
• 現在のスライスの目的やアクターから独立した機能は、黙って追加しないでください。依頼の成熟度に応じて $specsfy-02-backlog または $specsfy-03-specify を読み込んでください。
• 妥当な選択肢によって結果が実質的に変わる場合は、$specsfy-02-backlog にハンドオフし、適応サイクルを実行してから、このスキルに戻ってください。利用者が avançar を選択した場合は、中央契約に定められた確認と記録を適用し、該当する論点が残っていればアクト I を再開してください。定義を承認済みとして引き継がず、この再開時に同じサイクルを繰り返さないでください。

このスキルは新しい仕様を作成せず、重要な要件を利用者に代わって決定せず、本番コードを変更せず、依頼を実装しません。

変更を反映する

1. 依頼者が現在の spec への依頼の反映を許可したことを確認します。変更、追加、削除、修正を明示的に求めている場合は、すでに許可されています。確認を繰り返さないでください。
2. spec.md と、必要なインデックス済みのリサーチのみを編集します。 change-request.md、plan.md、tasks.md、research.md や、その他の並行する情報源は作成しないでください。
3. 影響を受けるすべての規範的なセクションを更新し、有効な ID と決定を保持し、既存の ID の番号を振り直さないでください。動作の変更については、第 17 節に理由、決定、影響を受ける ID を記録します。計画のみの変更については、人為的にプロダクトの決定を作り出さず、影響を受ける計画またはリスクのセクションに理由を記録します。
4. 過去の証拠を、新しい入力のために作成されたかのように書き換えないでください。無効になったバージョンに依存する、その後の証明はすべて保留としてマークします。
5. 影響範囲の投影を実行します。

node .agents/skills/specsfy-update-spec/scripts/analyze_change.mjs \
  specs/<estado>/<NNNN>-<slug>/spec.md --base HEAD --mode impact

--mode changelog を使用して、追加、削除、変更された ID を一覧表示します。分類にはセクション番号ではなく正規タイトルを使用します。安全のため、unknown の場合は第 I 幕からやり直します。このスクリプトは読み取り専用であり、依頼との意味的な比較に代わるものではありません。

必要なものだけを無効化する

• 第 I 幕の変更の場合は、Status: Draft、 Definition Gate: Pending、Plan Gate: Pending、および Delivery Gate: Pending に設定します。
• 第 II 幕のみの変更の場合は、Status: Defined に設定し、 Definition Gate: Passed を維持して、Plan Gate と Delivery Gate を Pending に戻します。
• 意味上の変更がないことが確認された編集上の明確化の場合は、ステータスとゲートを維持します。
• 無効になった入力に対して、後続のゲートを承認済みのままにしないでください。
• 有効なタスクと証拠は保持します。$specsfy-05-tasks が、新たな RED を行う前に、影響を受ける項目とその依存関係を調整します。

中間構造を検証します。

node .agents/skills/specsfy-04-validate/scripts/validate_spec.mjs \
  specs/<estado>/<NNNN>-<slug>/spec.md --allow-draft

フローを再開する

• 第 I 幕以降に変更があった場合は、$specsfy-04-validate を読み込みます。その後、タスク、TDD/BDD、および変更の起点となった段階を順に進めます。バックログの詳細化が avançar で終了した場合は、同じ再開中にこの引き継ぎを行わないでください。不足事項を報告し、ゲートを保留のまま終了します。
• 第 II 幕のみの変更の場合は、計画を調整し、$specsfy-06-tdd-bdd を呼び出して、変更の起点に戻る $specsfy-05-tasks を読み込みます。
• 実装中に変更が検出された場合は、Definition と Plan Gate が Passed に戻り、新規または変更された動作に対して有効な RED が存在するまで、$specsfy-07-implement を再開しないでください。
• Complete 後に変更が検出された場合は、無効になった幕を再度進め、Delivery Gate と DoD が実証された場合にのみ Complete に戻します。

報告する

維持された依頼、変更された spec、分類、影響を受ける ID とセクション、無効になったゲート、維持または保留となった証拠、次に読み込まれたスキルを報告します。結果を伝える前にフレームワークの複雑さを説明しないでください。まず、依頼が反映されたことと、必要なフローが自動的に再開されることを伝えます。