open-spec-complete について
変更完了時に機能仕様を同期する、フレームワーク非依存のスキルです。変更名がなければ Git の差分から対象を推定し、関連仕様を更新して一時的なワークフロー成果物を削除します。
主な機能
- 01Git 差分から変更を推定
- 02関連する機能仕様の更新
- 03新機能の仕様作成
- 04一時的な変更成果物の削除
- 05変更・作成した仕様の報告
活用シーン
- 01実装後の動作を仕様に記録
- 02TDD 変更後の仕様同期
- 03構造化された変更ワークフローの完了
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ aircury/ ai-framework --skill open-spec-completeインストール後、Claude Code で/open-spec-completeを入力して読み込まれたか確認します。
詳細
変更を完了としてマークし、常に最新の仕様を同期します。
フレームワークに依存しません:一時的な変更アーティファクト、プランモード、TDD、直接実装のいずれを使用した場合でも機能します。
唯一の要件は、specs/features/ にシステムの現在の動作が反映されていることです。
入力:変更名(specs/changes/<name>/ を使用している場合)を任意で指定します。それ以外の場合は、Git から差分を自動的に推測します。
手順
-
変更内容を把握する
git diff HEAD --stat git status変更された主要なファイルを読み、追加、変更、削除された動作を把握します。
-
ワークフローのアーティファクトを確認する
specs/changes/<name>/が存在するか確認します。- 存在する(構造化ワークフロー):正規の仕様を更新する際の計画コンテキストとして、そこにある作業中のアーティファクトを使用します。
- 存在しない(プランモード/TDD/直接実装):変更されたコードを読み、差分の影響を受ける
specs/features/内の要件を特定します。
-
specs/features/ を更新する
影響を受ける機能ごとに、次の作業を行います。
specs/features/<capability>/spec.mdを読みます。- 実際の動作変更に基づいて、追加、変更、削除する内容を特定します。
- RFC 2119 + WHEN/THEN 形式で、必要最小限の更新を適用します。
- 動作が新しい機能に属する場合は、
specs/features/<new-capability>/spec.mdを作成します。
形式(AGENTS.md より):
### Requirement: <system behavior as a declarative statement> <One-sentence description using SHALL/MUST.> #### Scenario: <observable outcome> - **WHEN** <condition or trigger> - **THEN** <expected system response>仕様には動作を記述します。実装については記述しません。技術名やフレームワークへの言及も含めません。
-
一時的なアーティファクトをクリーンアップする
specs/changes/<name>/が存在する場合:rm -rf specs/changes/<name>ワークフローの足場はコミットしません。役目を終えています。
-
報告する
specs/features/で何を変更したかを示します。ユーザーは、コード変更と一緒にこれらをコミットしてください。
出力
## Specs Updated
### Modified
- specs/features/learning-content-admin/spec.md — Added scenario: [...]
- specs/features/detectives-scenario-admin/spec.md — Updated requirement: [...]
### Created
- specs/features/<new-capability>/spec.md — New capability
### Cleaned up
- specs/changes/<name>/ (ephemeral artifacts removed)
Commit specs/features/ with the rest of this change.
ガードレール
- 必ず
specs/features/を更新します。観察可能な動作が変わった場合、仕様も変更する必要があります。 - アーティファクトをアーカイブしないでください。削除します(Git で無視される一時ファイルです)。
- 仕様には動作のみを記述します。DB スキーマ、コンポーネント名、エンドポイントパスは含めません。
- 変更が観察可能な動作を伴わない内部リファクタリングのみの場合、スキップする前にユーザーに確認します。
- タスクや PR ごとではなく、機能ごとに
spec.mdを 1 つ作成します。 - 仕様の更新は再構築テストに合格する必要があります。つまり、開発者が仕様だけをもとにこの機能を再構築できる必要があります。
コメント
Markdown 対応