mcpField
I
implement-work

implement-work

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

implement-work について

implement-work は、承認済みのエンジニアリング作業を定められた範囲で進めるワークフロースキルです。根拠に基づく検証と、完了前の独立レビューを重視します。

主な機能

  1. 01範囲と受け入れ根拠の特定
  2. 02範囲を限定した作業の実行
  3. 03対象を絞ったチェックによる検証
  4. 04正規ドキュメントの更新
  5. 05完了前の独立レビュー

活用シーン

  1. 01選択した Plan フェーズの実施
  2. 02範囲を限定した修正やリファクタリング
  3. 03引き継ぎやブリーフからの作業継続

インストール

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

$npx skills add https://github.com/klausborges/workflow-skills --skill implement-work

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

同梱ファイル

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

skill.toml
agents/
openai.yaml
references/
document-conventions.md
engineering-discipline.md
phase-review-template.md
workflow-language.md

詳細

作業の実装

Plan 形式のプロセスを他の入力に押し付けず、承認された成果を実現します。

engineering-discipline.md を使用します。Plan に基づく作業では、workflow-language.md、document-conventions.md、phase-review-template.md も使用します。

作業範囲を確定する

  1. リポジトリの指示、作業を規定する入力、関連する現行ドキュメント、ソース、テスト、参照されている成果物を確認します。
  2. 承認された成果、境界、受け入れを示す証拠、ドキュメントへの影響、未解決の判断事項を特定します。実装を大きく左右し得る不足情報についてのみ調査します。
  3. Plan が作業を規定している場合は、指定された Phase、または続行するよう求められた場合は次の未完了の Phase を選び、レビューのチェックポイントと Doc Delta を確認します。
  4. 実際の曖昧さ、認証情報、プロダクト上の判断、リスクの高い権限、明示的な人間の確認が必要な場合に限り質問します。それ以外は作業を進めます。

入力または承認されたワークフローで求められない限り、Plan、インタビューループ、引き継ぎ、worktree、コミット、PR を作成しないでください。

実装と検証

  • 隣接するクリーンアップを取り込まず、定められた範囲内で作業します。
  • 迅速で有意義なフィードバックループを使用します。低コストの動作には対象を絞った red/green チェック、セットアップに手間のかかる動作には同じ範囲のチェック、時間のかかるエンドツーエンド、全スイート、またはビジュアル動作には受け入れゲートを適用します。自動化が現実的でない場合に限り手動の証拠を使用し、残るリスクを記録します。
  • 実用上可能な場合は、公開されているインターフェース、または意図的に安定させたインターフェースを通じて検証します。成功を主張する前に、最新のコマンド結果や観察結果を確認します。
  • 動作の実装に合わせて、正規のドキュメントを最新の状態に保ちます。無関係な未コミットの作業や既存のドラフト、プロトタイプはそのまま保持します。
  • Plan で定められた影響の大きいレビューのチェックポイントに従います。影響の小さい Task は、Phase 末のレビューまで保留できます。
  • Plan に基づく作業では、証拠によって裏付けられた場合に限り Task と受け入れ基準を確認します。選択した Phase の Doc Delta のみを適用し、必須ではない作業は Discovered Follow-ups に回します。
  • Plan がない場合は、Plan の進捗管理を独自に持ち込まないでください。承認された作業をひとつのレビュー範囲として扱い、別の作業者やレビュー担当者に必要な状態だけを保持します。

範囲を完了する

  1. 承認された範囲全体について、入力、ドキュメント、テスト、実際の差分、永続成果物の境界に照らしてセルフチェックします。
  2. 関連する検証を実行し、その出力を確認します。
  3. 最新のパッチだけでなく範囲全体を、review-work を通じて独立した新しいコンテキストのレビュー担当者に渡します。承認された主張は一次証拠で検証し、承認範囲内のブロッキング指摘を修正して、影響を受けるチェックを再実行します。
  4. 変更された範囲または残るリスクによって正当化される範囲に限り、レビューを繰り返します。
  5. 作業を規定する成果物を更新します。Plan に基づく作業では、phase-review-template.md を使用し、選択した Phase の Plan とドキュメントの更新を完了してから、その Phase を完了済みにします。

レビューを再帰的にレビューしないでください。Phase をまたぐ受け入れやリスクによって必要とされる場合に限り、Milestone レベルの統合レビューを追加します。Plan または Roadmap のクリーンアップは最終レビューまで保留します。

コメント