implement-specs

implement-specs

PRODUCT.md と TECH.md に記載された承認済みの機能を実装します。

概要

プロダクト仕様と技術仕様の承認後に、このスキルを使用します。目的は、作業の進行に合わせて、チェックイン済みの仕様と実装の整合性を保ちながら、仕様に記載された機能を構築することです。

承認済みの仕様は、チケット名のディレクトリ直下に配置してください。たとえば、specs/APP-1234/PRODUCT.md と specs/APP-1234/TECH.md のようにします。

多くの場合、実装はプロダクト仕様および技術仕様と同じ PR でプッシュしてください。エンジニアが作業を進める中で、PRODUCT.md、TECH.md、コードの変更をすべて同じ PR にプッシュすれば、実際にリリースされる機能を軸にレビューできます。

前提条件

このスキルを使用する前に、以下を確認してください。

• PRODUCT.md が存在すること
• この機能で必要とされている場合、TECH.md が存在すること
• 関連する仕様のレビューが完了し、実装を開始できる程度に承認されていること

ワークフロー

1. 承認済みの仕様を最初に読む

以下のように扱ってください。

• ユーザー向けの動作については、PRODUCT.md を信頼できる情報源とします
• アーキテクチャ、順序、実装の構成については、TECH.md を信頼できる情報源とします

コードを書く前に、期待される動作、制約、リスク、検証計画を理解してください。

2. 大規模な機能では、任意の実装補助資料を提案する

大規模な機能や長期にわたる機能では、実装開始前に、以下の補助資料のいずれかをユーザーに任意で提案してください。

• PROJECT_LOG.md：チェックポイント、調査した経路、途中までの調査結果、現在の実装状況を記録します
• DECISIONS.md：PRD および技術設計のプロセスで決定した、具体的なプロダクトおよび技術上の判断を記録します

これらの補助資料は任意であり、必須の成果物ではありません。同じ経路を再調査する手間を省き、混乱を減らせる場合に提案してください。

3. 仕様に沿って計画し、実装する

作業を具体的な実装手順に分け、承認済みの仕様に沿って機能を実装してください。

実装中は、以下を行ってください。

• PRODUCT.md に記載された動作との整合性を保つ
• TECH.md に記載されたアーキテクチャおよび順序との整合性を保つ
• 作業の進行に合わせて、テストと検証成果物を追加または更新する

可能であれば、仕様と実装に同じ PR を使用してください。機能の変遷全体を 1 か所でレビューできます。

4. 実装の進行に合わせて仕様を更新する

実装によって、意図した動作や設計を変更すべきだと判明した場合は、仕様を古いままにせず、チェックイン済みの仕様を更新してください。

特に、以下のように対応してください。

• ユーザー向けの動作、UX、エッジケース、成功基準が変わった場合は、PRODUCT.md を更新する
• アーキテクチャ、順序、モジュールの境界、検証戦略が変わった場合は、TECH.md を更新する
• 対応するコード変更と同じ PR で、これらの更新を行う

PR には、仕様の初稿ではなく、実際にリリースされる機能を記述してください。

5. 仕様に照らして検証する

作業を完了とする前に、コードが現在の仕様に適合していることを検証してください。

以下を優先してください。

• リポジトリ内のテスト規約に沿ったユニットテストと回帰テスト
• 重要なユーザーフローを対象とする統合テストまたはエンドツーエンドテスト

ベストプラクティス

• 実装中は、仕様とコードの同期を保ちます。
• 判断が変わった場合は、仕様の整理を最後にまとめて行うのではなく、すぐに仕様を更新します。
• 複雑な機能で実質的な価値がある場合にのみ、任意の追跡用ドキュメントを使用します。
• 同じ PR に含める内容に一貫性を持たせます。仕様の更新、コード変更、テスト、任意の追跡用ドキュメントは、すべて同じ機能の説明を裏付けるものにしてください。

関連スキル

• spec-driven-implementation
• write-product-spec
• write-tech-spec