mcpField
S
specsfy-07-implement

specsfy-07-implement

github.com/promovaweb開発87443 回インストール1 週間前に更新
リポジトリ

specsfy-07-implement について

specsfy-07-implementは、Specsfyの仕様ワークフローを使う開発者向けの実装スキルです。依存順にタスクを進め、ゲート検証、データベース安全確認、ビジュアルレビュー、証跡記録、スキル間の自動引き継ぎを扱います。

主な機能

  1. 01依存順でのタスク実行
  2. 02仕様とゲートの検証
  3. 03テスト前のDB安全確認
  4. 04必須のビジュアルレビュー
  5. 05証跡とチェック項目の追跡
  6. 06スキル間の自動引き継ぎ

活用シーン

  1. 01Specsfy計画のタスク実装
  2. 02安全でないDBへのテスト防止
  3. 03検証結果と納品証跡の記録

インストール

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

$npx skills add https://github.com/promovaweb/specsfy --skill specsfy-07-implement

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
completion-gates.md
specialists.md
scripts/
next_task.mjs
render_delivery.mjs
verify_evidence.mjs

詳細

タスクを実装してコードを作成する

必須の準備

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

対話モード

対話モード:perguntas。 質問を作成する前に、.specsfy/Spec.md の Contrato de perguntas numeradas を読み、適用してください。

spec.md の 14. Tarefas セクションを依存関係の順に実行し、単一の情報源、テスト、コード、証拠、チェックボックスの整合性を保ってください。

Laravel の場合、依存関係を追加または置き換える前に、.specsfy/PACKAGES.md、docs/packages/README.md、既存のパッケージ情報を確認してください。タスクに GitHub の URL が含まれる場合、または Composer を変更する場合は、$specsfy-specialist-laravel-package-manager を読み込み、要件を満たすインストール済みのパッケージを再利用してください。

必須のデータベース保護

テスト、スイート、回帰テスト、マイグレーションを実行する前に、必ず次を実行してください。

node .agents/skills/specsfy-setup/scripts/check_database_safety.mjs \
  --project <raiz> --command "<comando-pretendido>"

Laravel の場合は、.env.testing、APP_ENV=testing、および .env で定義された開発用データベースとは明確に異なるデータベースを必須としてください。状態が PENDING の間は、テストを一切実行しないでください。環境を修正して確認を再実行し、SAFE になってから続行してください。

IGNORED に分類されたコマンドはすべて無視してください。migrate:fresh、migrate:refresh、migrate:reset、migrate:rollback、db:wipe、schema:drop、prisma migrate reset、DROP DATABASE、DROP SCHEMA、DROP TABLE、TRUNCATE または同等のコマンドは、実行せず、タスクに変換せず、実行許可を求めないでください。同じ拒否は、間接的なスクリプトや RefreshDatabase または DatabaseMigrations を使うテストにも適用されます。データベースを消去せず、トランザクションによる分離と最小限のフィクスチャを使用してください。

必須のビジュアルレビュー

すべての開発タスクで、依頼がなくてもビジュアルレビューを実施してください。VISUAL 項目は VERIFY の後に置き、EVIDENCE の前に完了させてください。

インターフェースに変更を加える場合は、DESIGNSYSTEM.MD、INTERFACE.md、影響を受けるコンポーネントを確認してください。関連するビューポートと状態で、レンダリングまたは DOM を検査してください。システムの境界線、間隔、マージン、パディング、タイポグラフィに加え、配置、幅、オーバーフロー、フォーカス、ズーム、テキストの折り返しを確認してください。使用した方法、ビューポート、状態、調整内容、結果をタスクに記録してください。

タスクでインターフェースを変更しない場合は、具体的な理由とともに VISUAL を Não aplicável として完了してください。依頼されていないことを理由に、この項目を省略してはいけません。

会話のオーケストレーション

この段階を完了したとき、または別の段階の作業を検出したときは、Pendência detectada: <descrição> — ação: resolvendo nesta etapa と告知し、自身のスコープに属する場合は解決してください。責任を切り替える場合は、Transição automática: $specsfy-07-implement → $<destino> — motivo: <motivo> — resultado esperado: <resultado> と告知し、確認を求めたりコマンドを繰り返したりせず、直ちに移行先のスキルを読み込んでください。同じ会話内で続行してください。この段階に必要な修正後は、Retomada automática: $<destino> → $specsfy-07-implement — pendência resolvida: <resultado> と告知し、直ちに作業を再開してください。ハンドオフのたびに状態を再評価し、循環を避けてください。ハンドオフの確認を求めないでください。機微な操作には引き続き個別の許可が必要です。

初期ゲート

  1. $specsfy-setup で確認したパスをルートとして解決します。ユーザーがサブディレクトリを指定した場合は、それをプロジェクトとして扱い、Git ルートに昇格させないでください。<ルート>/specs/planned/<NNNN>-<slug>/spec.md、research/ にインデックス化されたエビデンス、リポジトリの指示、および関連するコードを読みます。tasks.md、plan.md、research.md、data-model.md は探さないでください。
  2. Formato: Specsfy/2.0、Status: Planned または Implementing、Definition Gate: Passed、Plan Gate: Passed を必須とします。
  3. Interface para pessoas が Sim の場合、セクション 10 を読み、計画にローカルスタック、画面、メニューとメインナビゲーション、フォーム、アクション、React ブロック、shadcn/ui/ReUI コンポーネント、状態、操作テストのタスクが含まれていることを確認します。コードを変更する前に、現在のスタック、画面、フローをプロジェクトと照合します。記録された範囲外にある既存のコンポーネント、ルート、コンテンツ、権限、動作は維持します。いずれかが不足している場合、または提案された技術が確認なしに異なる場合は、自動的に $specsfy-05-tasks に戻します。API または永続化のみの CRUD は実装しないでください。 コーディングを始める前に、セクション 10 の表と INTERFACE.md で選択項目を確認します。コーディング後は、作成、変更、または再利用したすべてのブロックを INTERFACE.md に反映します。 React プロジェクトでは、JSX または TSX を書く前に $specsfy-specialist-react-ui-components を必ず読み込みます。 このスキルがインストールされていない場合は、検出されたスペシャリストをインストールするため $specsfy-setup に戻り、その準備が完了するまで画面を実装しないでください。 CRUD の場合は、すべての画面で再利用する単一の PageHeader、全幅の DataGrid、常に表示される ID 列、詳細への行リンク、行内に個別に配置された編集ボタンと削除ボタンも確認します。
  4. specs/<状態>/<NNNN>-<slug>/spec.md に対してバリデーターを実行します。以前承認された計画でタスク、TDD の先行タスク、または RED が欠けているためにゲートが失敗した場合は、未解決事項を伝え、自動的に $specsfy-05-tasks に戻します。本番環境は変更しないでください。このスキルは第 II 幕を再開して TDD/BDD を呼び出し、計画を再検証した後にこの実装を再開します。それ以外の失敗の場合は、ゲートを担当するスキルを自動的に読み込みます。
  5. check_database_safety.mjs で基本テストスイートのコマンドを確認します。SAFE の場合にのみ実行してください。分離されたテスト環境がない場合は、テストを一切実行しないでください。既存の失敗を記録し、新たな変更に起因するものとして扱わないでください。
  6. 本番環境を初めて変更する前に、Status: Implementing、Delivery Gate: In Progress を設定し、specsfy transition <id> in-progress を実行します。
  7. 次の方法で、着手可能な作業を選択します。
node .agents/skills/specsfy-07-implement/scripts/next_task.mjs \
  <raiz>/specs/<estado>/<NNNN>-<slug>/spec.md

着手可能なタスクがない場合は、「完了」と「依存関係によりブロック中」を区別します。

タスクを実行する

  1. ID、種別、参照先、依存関係、ファイル、検証可能な結果を確認し、その確認直後に PREP を付けます。
  2. [TEST] では、$specsfy-06-tdd-bdd に従います。spec の参照用 Gherkin を読み、それを使って TDD テストを設計します。マーカーを追加し、有効な RED を確認します。.feature を作成または実行してはいけません。PHP では Pest を使い、Node ではユーザーが確認したランナーのみを使います。
  3. [CODE] では、同じ ID を対象とし、セクション 11 に RED が記録された TDD の先行タスクが完了していることを確認します。完了していなければ停止し、本番コードを変更しません。未完了であることを伝え、自動的に $specsfy-05-tasks に戻ります。そこで計画を再開し、$specsfy-06-tdd-bdd を呼び出し、新しい Plan Gate: Passed の後にこのスキルへ戻ります。
  4. TDD テストを成功させるための、本番コードの変更を最小限に抑えます。UI タスクでは、spec で定義された画面、メニュー、フォーム、インタラクションを、記載された状態に従って実装します。合意済みの画面を、API ルート、空のコンポーネント、または画面を省略する近道に置き換えてはいけません。 React では、新しい構成を作成する前に $specsfy-specialist-react-ui-components に従い、コンポーネントを特定、再利用、調整し、記録します。 タスクで [MIGRATION] を使う場合は、計画されたパスにバージョン管理対象のファイルを最初に作成します。コマンドを check_database_safety.mjs に通し、テスト用データベースにマイグレーションを適用して、直後に状態を確認します。終了コードがゼロの両方のコマンドを、タスクの specsfy:evidence コメントに記録します。
  5. 本番コードを変更した後、EXECUTE を付ける前に、コンテキストを監視します。
node .agents/skills/specsfy-setup/scripts/monitor_context.mjs \
  --project <raiz> --check

保留中のスタック関連事項は $specsfy-aux-stack に、永続化関連事項は $specsfy-aux-database に、確認済みルールは $specsfy-aux-rules に引き継ぎます。アプリケーションを変更するたびに PROJECT.md を見直します。ストーリー、目的、機能、制限に実質的な影響がない場合は、その評価をタスクのエビデンスに記録し、--acknowledge-project-no-change を付けて再実行します。モニターが PENDING を返す間は、タスクにチェックを付けてはいけません。 6. [CODE] タスクごとに、次の内容を伝えてから $specsfy-documentator を読み込みます。 Transição automática: $specsfy-07-implement → $specsfy-documentator — motivo: implementação alterou o sistema — resultado esperado: docs/ reconstruído e atual 既存のすべてのコードからドキュメントを再構築し、--check を実行します。ドキュメントが最新になった場合にのみ、このスキルに戻ります。 7. [DOC] または [OPS] では、求められている固有のエビデンスを作成します。 8. 成果物と必要なドキュメントが、宣言されたパスに存在する場合にのみ EXECUTE を付けます。 9. check_database_safety.mjs を使って各テストコマンドを再確認します。TDD の焦点テスト、関連スイート、静的チェックは、SAFE の後にのみ実行します。期待された結果が得られた場合にのみ VERIFY を付けます。 10. すべてが成功している場合にのみ、リファクタリングします。 11. コマンド、結果、ID をセクション 11~13 に記録し、その後 EVIDENCE を付けます。Evidence Contract: 1 がある場合は、タスクのブロックに JSON 形式の specsfy:evidence コメントも記録し、次を実行します。

node .agents/skills/specsfy-07-implement/scripts/verify_evidence.mjs \
  specs/<estado>/<NNNN>-<slug>/spec.md . --task TNNN

完全な実行によって schema 2 のアテステーションが生成された場合は、--attestation PATH でもう一度検証します。互換性のあるコミット、同じ spec/タスクのバインディング、同一の refs とコマンド、実際に成功したチェック、各ファイルの最新の SHA-256 を必須とします。--self-test のアテステーションは、成果物の証明にはなりません。 12. ミニふりかえりを行います。安全な改善が見つかった場合は適用し、見つからなかった場合は理由とともに「改善は不要」と記録します。その後 IMPROVE を付けます。 13. specs/<estado>/<NNNN>-<slug>/spec.md のセクション 14 では、VISUAL を含む6項目すべてが完了した場合にのみ、親項目を - [ ] から - [x] に変更します。 14. validate_tasks.mjs を実行し、次のタスクを再計算して、next_task.mjs が返す次の項目を確認します。 [MIGRATION] タスクは、model、query、またはテストが存在するだけでは完了になりません。verify_evidence.mjs は、migration ファイル、その適用に使ったコマンド、および状態を確認するクエリを要求します。いずれかが不足している場合は、EXECUTE、VERIFY、タスクを未完了のままにしてください。

作業の進行に合わせて項目を更新し、完了時にまとめてチェックを付けないでください。[P] タスクは、同じファイルや状態に触れない場合に限り、まとめて実行できます。実行中に隠れた依存関係が明らかになった場合は、セクション 14 に明記してください。

スコープ変更の管理

実装に記載のない動作が必要になる場合、AC と矛盾する場合、または公開インターフェース、データ、セキュリティ、スコープ外の領域が変更される場合は、作業を停止してください。保留事項を伝え、$specsfy-update-spec を自動的に読み込んでください。この skill は依頼内容を維持し、要件の詳細化が必要か判断し、規範となる情報源を更新し、影響を受けるゲートのみを再開して、検証、タスク、TDD/BDD を順に進めます。ゲートが再承認された場合に限り、この skill を再開してください。次の順序で更新します。

specs/<estado>/<NNNN>-<slug>/spec.md (seções 1–13) → tarefas (seção 14) → testes → código → evidências na mesma spec

元に戻せる内部的な修正はコード上で判断し、仕様を再開せずに報告へ記録できます。

完了ゲート

セクション 14 のすべてのタスクにチェックが付いたら、次を実行してください。

  1. 利用可能なテストスイート全体、lint、型チェック、ビルドを実行します。
  2. テストのトレーサビリティを実行します。
  3. 各 AC、FR、NFR、Definition of Done の項目を最新のエビデンスと照合します。
  4. 未完了のタスク、プレースホルダー、スキップされたテスト、既知の失敗を確認します。
  5. monitor_context.mjs --project <raiz> --check を再実行し、保留中のドキュメント作業をすべて解決します。
  6. $specsfy-documentator を読み込み、docs/ を再構築し、build_documentation.mjs --project <raiz> --check が成功することを必須とします。
  7. エビデンスが不足している場合は、完了を宣言しないでください。
  8. すべての [MIGRATION] タスクについて verify_evidence.mjs を実行し、ファイル、適用、状態確認クエリを検証します。
  9. トレーサビリティが完全な場合に限り、Delivery Gate を Passed に変更し、Status: Reviewing を設定して、specsfy transition <id> review を実行します。$specsfy-04-validate が受け入れを完了し、spec を completed に移します。

最終ゲートの後、ファイルを作成せずに納品概要を生成します。

node .agents/skills/specsfy-07-implement/scripts/render_delivery.mjs \
  specs/<estado>/<NNNN>-<slug>/spec.md --format markdown

納品が未完了の間は --preview を使用してください。PR、コミット、または外部ツールへのテキストの公開には明示的な依頼が必要です。このスクリプトは stdout にのみ書き込みます。

締めくくりについては references/completion-gates.md を読んでください。

報告

完了したタスク、変更したファイル、コマンドと結果、対象 ID、既存の失敗、次に実行可能なタスク、または最終ゲートを報告してください。最後に、情報源から派生した全体像を確認するため、$specsfy-progress を告知して自動的に読み込んでください。失敗した場合は保留事項を伝え、必要に応じて担当 skill を自動的に読み込み、修正して作業を再開するまでタスクを未完了のままにしてください。

必要に応じて専門家に相談

ローカルのコンテキストでカバーされていない技術やリスクを伴うタスクを実行する前に、references/specialists.md を読んでください。インストールは、利用するプロジェクトでの許可を得た場合に限ります。

コメント