mcpField
O
optflow

optflow

github.com/majiayu000開発28848 回インストール1 日前に更新
リポジトリ

optflow について

optflowは、リポジトリの最適化候補を見つけて実装するスキルです。調査から検証、コミットまで進めたい開発者向けに、影響度・工数・リスクに基づいて作業を段階化します。

主な機能

  1. 01最適化候補の調査と分類
  2. 02影響度、工数、リスクによる優先順位付け
  3. 03実装計画の作成
  4. 04段階的な実装とチェック
  5. 05BDDシナリオとコミット方針への対応

活用シーン

  1. 01リポジトリ最適化のロードマップ作成
  2. 02性能や信頼性の改善
  3. 03曖昧な要件へのBDDシナリオ追加
  4. 04最適化変更の段階的なテストとコミット

インストール

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

$npx skills add https://github.com/majiayu000/spellbook --skill optflow

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

同梱ファイルreferences/bdd-guide.mdreferences/delivery-base.md

詳細

Optflow

概要

このスキルを使用して、リポジトリの最適化の機会を見つけ、選択した最適化を最初から最後まで実行します。

  • 最初に最適化ポイント(パフォーマンス、信頼性、保守性、セキュリティ、コスト、開発者体験)を見つけます。
  • 影響度/工数/リスクに基づいて優先順位を付けます。
  • 検証と明示的なコミットポリシーに従い、厳密な順序で実行します。
  • 要求された場合、または要件が曖昧な場合は、BDD の振る舞い仕様を追加します。

トリガーとなる依頼

次のいずれかをユーザーが求めた場合、このスキルを使用します。

  • リポジトリ/ライブラリの最適化の機会を見つける。
  • 最適化ロードマップと実装を求める。
  • テストファーストで最適化を実施し、コミットする(最後にまとめて、またはステップごとに)。
  • 振る舞い駆動型の実施(BDD)または受け入れシナリオを求める。

ワークフロー

0. 最適化バックログを見つける
  • 変更を計画する前に、リポジトリをスキャンします。
  • 見つかった項目を次のカテゴリに分類します。パフォーマンス、信頼性、保守性、セキュリティ、開発者体験、コスト。
  • 各項目について、次の内容を記録します。
    • 症状と根拠(ファイル/パス/メトリクス)
    • 期待される影響
    • 工数の見積もり
    • リスクレベル
  • 影響度/工数/リスクに基づき、優先順位を付けたバックログを作成します。
  • 確信度の低い項目には、仮説であることを明示します。
1. Ready Criteria(DoR)を定義する

共通のデリバリーベースを参照してください:references/delivery-base.md

optflow に関する追加事項:

  • 実装が求められており、コミット方式が明示されていない場合は、per_step(デフォルト)を使用します。
  • ユーザーが「ステップごとに最適化してテストし、その後コミット」と指定した場合は、per_step を使用します。
2. 編集前に完全な計画を作成する

共通のデリバリーベースを参照してください:references/delivery-base.md

3. 必要に応じて BDD レイヤーを追加する

ユーザーが要求した場合、または要件が明確でない場合は BDD を使用します。

BDD Lite、シナリオ品質チェックリスト、シナリオアウトライン、テストレイヤーのマッピングについては、共通リファレンスを参照してください。

references/bdd-guide.md

4. ステップごとに実行する

共通のデリバリーベースを参照してください:references/delivery-base.md

  • 可能な限り、計画上の 1 ステップを 1 つの機能境界として扱います。
  • commit_policy = per_step(実装時のデフォルト)の場合:
    • 現在のステップ/機能に関するファイルのみをステージします。
    • まずステップレベルのチェックを実行します。
    • ステップのチェックに合格したら、直ちにコミットします。
    • ステップとコミットハッシュの対応関係を記録します。
5. 後方互換性なしモードを適用する(要求された場合)

共通のデリバリーベースを参照してください:references/delivery-base.md

6. テストマトリクスで検証する

共通のデリバリーベースを参照してください:references/delivery-base.md

ステップごとに必ず行うループ(commit_policy = per_step の場合):

  1. 現在の機能ステップを実装します。
  2. 対応するステップのチェックを実行します(少なくとも 1 つの自動化コマンド)。
  3. チェックに合格したら、このステップを直ちにコミットします。
  4. 次の機能ステップに進みます。
7. コミットして引き継ぐ

共通のデリバリーベースを参照してください:references/delivery-base.md

  • per_step:次のステップを開始する前に、各ステップを必ずコミットしておきます。

出力テンプレート

最適化バックログのテンプレート
Finding:
Category: <performance|reliability|maintainability|security|dx|cost>
Evidence: <file/metric/log>
Impact: <high|medium|low>
Effort: <high|medium|low>
Risk: <high|medium|low>
Priority score: <...>
Decision: <implement now|defer>
最適化計画のテンプレート
Selected Findings:
1. <finding>
2. <finding>

Execution Steps:
1. <step> (done condition: <...>)
2. <step> (done condition: <...>)

Expected Gains:
- <metric or qualitative gain>

ガードレール

  • 実装が求められている場合、計画だけで終わらせないでください。
  • 計画のステップを未完了のまま残さないでください。
  • 今すぐ実行できる必須のテストを先送りしないでください。
  • commit_policy = per_step の場合、コミットする前に次の計画ステップへ進まないでください。
  • commit_policy = per_step の場合、完了した複数の機能ステップを 1 つのコミットにまとめないでください。
  • ユーザーが互換性に関する作業を明示的に求めていない場合、互換性を保証しないでください。
  • 既存の無関係な未コミットファイルをコミットに含めないでください。
  • 具体的な検証結果を示さずに引き継がないでください。

コメント