realign-spec について
realign-specは、機能ごとの要件・設計・タスクをコードやテストの実態に合わせるスキルです。要件の履歴を保ち、監査結果と検証の証拠に基づいて編集や状態変更を行います。
主な機能
- 01要件とタスク、設計を照合
- 02未対応要件をカバーするタスクを追加
- 03孤立した要件参照を指摘
- 04証拠がある場合のみ状態を変更
- 05監査結果の変更前後を報告
活用シーン
- 01コード変更後の機能仕様の同期
- 02タスク未設定の要件の特定
- 03検証証拠に基づく仕様状態の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/realign-specを入力して読み込まれたか確認します。
同梱ファイルeval.jsonTESTS.md
詳細
仕様を同期する
1 つの機能の仕様トライアド（docs/specs/<date>-<feature>/{requirements,design,tasks}.md）を、コード、テスト、タスクの実際の状態に合わせて修正します。変更後に再同期されていない仕様はフィクションになり、フィクションは仕様がないよりも悪いものです。
一度に 1 つの機能を扱います。まず仕様ディレクトリを特定します（ユーザー、現在のブランチ、または docs/specs/INDEX.md から）。
厳守事項
- 要件 ID の番号を振り直してはいけません。 ID は承認後に変更できません。以降のすべての項目がその ID を参照します。
- 要件を削除してはいけません。 次の形式で廃止します：
~~**CODE-N.M**~~ <reason>— 取り消し線の付いた ID は定義済みとして数えられなくなりますが、履歴は判読できる状態に保たれます。 - 新しい要件には、そのストーリー内で次に使える番号を付けます。新しいタスクは既存のタスク形式に厳密に合わせます。
Status: Shippedと記載してはいけません。 そのステータスへの移行は、リリース対象機能群に対するリリース手順cut-releaseのステップ i です。このスキルで同期するのは 1 つのトライアドであり、リリースのステータスを付与するものではありません。Status: In-progressと記載してはいけません。 そのステータスへの移行はexecute-commonのセッション事前確認で行います。
手順
a. ベースライン。 監査トレースのチェックを実行し（必須サブスキル：audit-trace を使用）、検出結果を記録します。これが「変更前」の状態です。
b. 要件 ↔ タスク。 requirements.md と tasks.md を比較します。
- 有効な要件を参照するタスクがない場合は、ファイル内のほかのタスクと同じ形式で該当タスクを追記し、末尾を
_Requirements: CODE-N.M_フッターにします。 - 実装済みで、証明の主張を裏付ける証拠も存在するなど、完了が確認できる作業のタスクボックスにチェックが付いていない場合は、チェックを付けます。
c. 要件 ↔ 設計。 要件 ID と design.md の Satisfies: 行を比較します。Satisfies: 行に一度も登場しない有効な要件は、ユーザーに提示します。設計にセクションが必要なのか（拡張する）、それとも要件が将来の構想なのか（廃止を検討する）を確認します。設計内容を黙って作り出してはいけません。
d. 孤立項目。 取り消し線の付いた ID、または存在しない ID を参照しているタスクフッターをすべて列挙します。項目ごとに対応案を添えてユーザーに提示します（有効な ID に付け替える、タスクの参照を廃止する、要件を復活させる）。孤立項目への対応は判断が必要なものであり、単なる整理ではありません。アプリケーションテスト内のレガシー ID 文字列は、この手順の対象外です（ドキュメントのみの仕様トレース）。
e. ステータスの移行 — 証拠がある場合のみ。
| 移行 | 必要な証拠 |
|---|---|
| Draft → Approved | ユーザーが仕様を明示的に承認していること — 推測してはいけません |
| Approved / In-progress → Implemented | すべてのタスクボックスにチェックが付いていること、ドキュメントのみの監査トレースにエラーがないこと、prove-claim の検証コマンドがすべて成功すること |
| Implemented → Shipped | ここでは適用しません — cut-release のステップ i でリリース対象機能群の Shipped を設定します |
必要な証拠がそろっている場合は、Draft → Approved または Approved / In-progress → Implemented を適用します。requirements.md の Status: 行と、docs/specs/INDEX.md の該当機能の行を更新します。証拠が一部しかない場合は、ステータスを移行せず、不足しているものを正確に伝えます。リリース作業中に「リリース済みの機能を Shipped にする」よう求められた場合、それはこのスキルではなく cut-release のステップ i です。ステータスの付与は拒否し、ずれがあれば 1 機能のトライアド修正を提案します。
f. 変更後の状態。 監査トレースのチェックを再実行し、変更前と変更後の検出結果を並べて表示します。解消されたエラーと警告、残っている項目、そしてその状態に至るために行った変更を示します。docs/specs/INDEX.md が各仕様の現在の Status: 行を反映していることを確認し、同じコミットにステージングします。
完了条件： 変更後のレポートでエラーが変更前より悪化しておらず、指摘されたすべての項目が編集済み、またはユーザーの判断待ちとして明示されており、INDEX.md の内容が各仕様の Status: 行と一致していること。