mcpField
S
spec-finish

spec-finish

github.com/martinffxエージェントワークフロー4844 回インストール3 日前に更新
リポジトリ

spec-finish について

spec-finishは、仕様に基づく実装を終えた開発者向けの仕上げスキルです。範囲の整理、ドキュメント更新、検証、レビュー、コミット、PR準備を順に進めます。

主な機能

  1. 01完了前提条件の確認
  2. 02範囲比較と変更の簡素化
  3. 03READMEなど関連文書の同期
  4. 04テスト・型チェック・ビルド
  5. 05最終変更のレビュー
  6. 06コミットとPRの準備

活用シーン

  1. 01仕様に基づく計画の完了後の仕上げ
  2. 02要求範囲を超えた実装の削除
  3. 03コミット前のコード検証とレビュー
  4. 04レビュー済み変更からのPR準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/martinffx/atelier --skill spec-finish

インストール後、Claude Code で/spec-finishを入力して読み込まれたか確認します。

詳細

Spec Finish

実装後のワークフロー：簡素化 → ドキュメントの同期 → 検証 → レビュー → PR の準備。

前提条件

開始する前に、以下を確認してください。

  1. Spec に基づく Plan のタスクがすべて完了している
  2. 作業ディレクトリに未解決のステージ済み変更または未ステージ変更がない
  3. テストが成功する

完了していない場合は、spec-implement に戻ってください。

Step 1: スコープを比較して簡素化する

ドキュメント作成や検証の前に、実装を元の動作およびユーザーの目標と比較してください。要求されていないスコープ、重複する概念、利用者が1つしかいない抽象化、十分なプラットフォームの機能に置き換わる独自の仕組みを削除してください。

実装が不必要に大規模な設計に忠実に従っている場合は、作業を止めて spec-plan に戻ってください。続行する前に、より小規模なプランの承認を得てください。

完了した SDD を更新し、より小規模な成果を記述してください。規範となる設計とプランでは、却下したアーキテクチャを前例として残さず、置き換えてください。その経緯が有用な場合に限り、却下した代替案として言及してください。

Step 2: ドキュメントを更新する

README、API ドキュメント、変更履歴の更新が必要か確認してください。必要なドキュメント変更を行い、最終検証の前に code-commit を通じてコミットしてください。

Step 3: 検証する

検証チェックを実行してください。

テストスイート
npm test
# or
pytest
# or
cargo test
型チェック
npm run typecheck
# or
python -m mypy
# or
cargo check
リント
npm run lint
# or
ruff check .
# or
cargo clippy
ビルド
npm run build
# or
go build ./...

いずれかが失敗した場合： 修正するために spec-implement に戻ってください。

すべて成功した場合： 次に進んでください。

Step 4: レビューする

ハーネスのスキル機構を通じて、インストール済みの code-review スキルを呼び出し、最終変更を包括的にレビューしてください。

レビュー対象
  • 意図したベースブランチのマージベース以降に変更されたすべてのファイル
  • テストカバレッジ
  • ドキュメントの更新
  • デバッグコードが残っていないこと
code-review で問題が見つかった場合
  • 軽微な修正はここで行い、その後、再検証と再レビューを実施できます。
  • blocking: true または requires_user_approval の指摘、およびスコープを変更する修正は、spec-implement に戻ってください。ブロック対象ではない指摘やフォローアップは該当しません。

Step 5: コミットを準備する

git log --oneline で現在のコミットを確認してください。未コミットの作業には code-commit を使用してください。デフォルトでは履歴を書き換えないでください。未公開のコミットスタックをリベースすると大幅に改善する場合は、リベースの前に対象範囲を示し、個別に承認を求めてください。

Step 6: PR を準備する

次に進む前に、Step 1〜5（簡素化、ドキュメント、検証、レビュー、コミット）をすべて完了してください。code-review でブロック対象の指摘、またはユーザーの承認が必要な指摘が見つかった場合は、作業を止めて spec-implement に戻り、修正してください。Step 6b には進まないでください。

Step 6a: 完了サマリーを提示する

PR を作成する前に、人間にサマリーを提示してください。

## Completion Summary

**Feature:** [name]
**Tests:** [passed/failed]
**Type Check:** [passed/failed]
**Lint:** [passed/failed]
**Review:** [passed/issues found]
**Commits:** [N commits in stack]
**Ready for PR:** [yes/no]
Step 6b: code-pull-request を呼び出す

サマリーに Ready for PR: yes と表示されている場合に限り、 code-pull-request スキルを呼び出して PR を作成してください。このスキルは、プラットフォーム（GitHub/GitLab）を検出し、既存の PR を確認し、テンプレートを見つけ、コミットから本文を生成して、gh または glab を使って PR を作成します。

引き継ぎ

「実装が完了しました。［N］件のコミットを準備できました。PR パッケージの承認準備が整っています。」

Integration

このスキルは、他のスキルを統括します。

  • 品質チェックのために code-review を呼び出す
  • PR を作成する最終ステップとして code-pull-request を呼び出す

使用しない場合

  • 実装がまだ進行中の場合は、spec-implement を使用してください
  • テストが失敗している場合は、spec-implement に戻ってください
  • レビューでブロック対象の指摘、またはユーザーの承認が必要な指摘が見つかった場合は、spec-implement に戻ってください
  • 実装が不必要に大規模な設計に従っている場合は、spec-plan に戻ってください

コメント

Markdown 対応