mcpField
U
ub-workflow

ub-workflow

github.com/robert-hoffmannその他1940 回インストール21 週間前に更新
リポジトリ

ub-workflow について

ub-workflowは、チャット履歴だけでは状態を保ちにくい大規模・高リスク・横断的な作業向けの、持ち運び可能な計画・実行プロセスです。発見、選択肢、ロードマップ、スプリントの成果物を構成し、検証や再開を支援します。

主な機能

  1. 01ビジョンからスプリントまでの計画モデル
  2. 02発見とデリバリーの二軌道プロセス
  3. 03レビュー後に開始する進行モード
  4. 04状態・証拠・判断の記録
  5. 05段階的作業を再開する成果物

活用シーン

  1. 01複数セッションにまたがる製品開発の計画
  2. 02実行前の選択肢とリスクの検証
  3. 03スプリントごとの成果と証拠の追跡
  4. 04判断の文脈を保った作業経路の変更

インストール

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

$npx skills add https://github.com/robert-hoffmann/uncle-bob --skill ub-workflow

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

同梱ファイル

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

assets/
.gitkeep
assets/initiative-template/
index.md
initiative.md
options.md
retained-note.md
roadmap.md
assets/initiative-template/sprint-template/
closeout.md
decision-log.md
sprint.md
assets/initiative-template/sprint-template/evidence/
index.md
assets/operations-root/
AGENTS.md
operation-guide.md
references/
artifact-contracts.md
context-management.md
governance-bridge.md
placeholder-contract.md
scaffold-helper.md
trace-tokens.md
validation-and-completion.md
workflow-contract.md
scripts/
check_scaffold_placeholders.py
check_workflow_options.py
scaffold_workflow.py

詳細

UB ワークフロー

概要

チャット履歴だけでは処理しきれない規模、リスク、範囲の広さ、または状態を伴う作業には、このスキルをポータブルなワークフローレイヤーとして使用します。

デフォルトの操作ルートは ./.ub-workflows/ です。ただし、ホストが意図的に別のルートを選択する場合を除きます。

正規化されたモデルは、プロダクトアジャイルのハイブリッドです。

Product Vision -> Product Options -> Outcome Waves -> Initiatives -> Discoveries -> Sprints

このモデルは、次の要素を組み合わせています。

  1. デュアルトラックアジャイル:デリバリーで作業に着手する前に、ディスカバリーで選択肢を検証します。
  2. 目標指向のロードマップ作成:プロダクトビジョンは広く保ちつつ、現在の成果はウェーブとイニシアチブで扱います。
  3. スクラムに似たスプリント実行:スプリントゴールを1つ設定し、検査と適応を行います。レビュー済みモードが有効な場合は、明示的な開始承認を必須とします。
  4. カンバン形式のフロー制御:明示的なポリシー、WIP 制限、コミット前の選択肢、フィードバックループ、古くなった候補の再検証を含みます。
  5. Shape Up の影響:軽量なベットの枠組み、アペタイト、サーキットブレーカーを取り入れ、バックログの滞留を防ぎます。
  6. アペタイト枠付きの予測調整:候補数は予測であり、対象範囲を絞った選択肢とトレードオフを確認した後、拡張するかどうかはオペレーターが選択します。

標準レイアウト

PROJECT_ROOT/
  AGENTS.md
  SOURCE_ATLAS.md
  .ub-workflows/
    AGENTS.md
    vision.md
    options.md
    status.md
    WORKFLOW_ATLAS.md
    SOURCE_PACK_ATLAS.md
    source-packs/
      .gitkeep
      YYYY-MM-DD-slug/
    waves/
      .gitkeep
      wNN-wave-slug/
        wave.md
        discoveries/
          .gitkeep
          wNN-dNN-slug.md
        source-packs/
          .gitkeep
          YYYY-MM-DD-slug/
        initiatives/
          .gitkeep
          iNN-initiative-slug/
            initiative.md
            options.md
            roadmap.md
            index.md
            discoveries/
              .gitkeep
              wNN-iNN-dNN-slug.md
            sprints/
              .gitkeep
              wNN-iNN-sNN-sprint-slug/
                sprint.md
                decision-log.md
                closeout.md
                evidence/
                  .gitignore
                  index.md

命名規則:

  1. ウェーブ ID はプロジェクト全体で連番にします:w01、w02 など。
  2. イニシアチブ ID はウェーブごとに i01、i02 などから付け直します。
  3. ウェーブレベルのディスカバリーには wNN-dNN-slug.md を使用し、番号はウェーブごとに付け直します。
  4. イニシアチブのディスカバリーには wNN-iNN-dNN-slug.md を使用し、番号はイニシアチブごとに付け直します。
  5. スプリントには wNN-iNN-sNN-sprint-slug/ を使用し、番号はイニシアチブごとに付け直します。
  6. ソースパックには YYYY-MM-DD-slug/ を使用し、日付には作成日、元の調査日、確認できる最古の日付、または移行日を指定して、その旨を記録します。

レーン

受け入れた目標を、無関係な範囲拡大を伴わずに完了、検証、復旧できるレーンを選択します。

  1. 範囲を限定した直接作業:永続的な計画用の領域を必要としない、小規模な単一セッションの変更です。
  2. ウェーブ/イニシアチブのワークフロー:選択肢ボード、ディスカバリー、ロードマップ、スプリント、完了処理、再開可能な証跡が必要な、複数セッションにわたる段階的な作業、リスクの高い作業、プロダクト形成に関わる作業、または複数領域にまたがる作業です。

現在のレーンでは、受け入れた目標を完了し、その達成を証明するための永続的な領域が不足する場合は、より上位のレーンへ移行します。 移行理由は、その作業を新たに管理する成果物に記録します。

組み込み契約

  1. 再利用可能なワークフロールールは、リポジトリオーバーレイではなく、このスキルに保持します。
  2. リポジトリオーバーレイは薄く保ちます。プロジェクトの事実、現在のポインター、ローカルの検証コマンド、ドメインの境界、リポジトリ固有の制約に限定します。
  3. vision.md は、適応可能なプロダクトの北極星を管理します。
  4. ルートの options.md は、確定前の厳選されたプロダクトレベル、将来のウェーブ、担当者不明の選択肢を管理します。バックログ台帳、完了履歴、実行許可のための場所ではありません。
  5. status.md は、現在のプロダクトの状況、ウェーブの順序、アクティブなポインター、ブロッカー、WIP の状態、候補トラック、保持コンテキストへのルート、次に許可されるアクションを管理します。
  6. SOURCE_ATLAS.md は、プロジェクトルートのソースルーティングを管理します。ブートストラップ時に一度だけスキャンして初期データを作成し、その後の更新はソース境界が移動したときにイベントベースで行います。
  7. ルートの AGENTS.md は、ローカルのエージェントオーバーレイを管理します。ブートストラップで作成またはパッチするのは、小さな管理対象のワークフロールーティングセクションのみです。
  8. ワークフロールートガイド、プロダクトとライブ状態を分割した起動ファイル、ルートの仕様レーンは、標準的なワークフローの管理場所ではありません。
  9. 成果ウェーブは適応可能なプロダクトスライスであり、レビュー済みのディスカバリーを通じて分割、統合、拡大、縮小できます。
  10. イニシアチブは、ウェーブ内のテーマ別の賭けです。一時停止して再開できます。
  11. イニシアチブローカルの options.md は、そのイニシアチブが終了する前に挿入する可能性のある項目を管理します。プロダクトレベルまたは後続ウェーブの選択肢は、ルートの options.md に移します。
  12. ディスカバリーは、例外的な儀式ではなく、通常の上流の舵取り作業です。
  13. ディスカバリーとスプリントプレビューでは、ユーザーまたはオペレーターからのエビデンスの状態を used、not triggered、deferred のいずれかで記録し、技術作業においても、実際のユーザーやオペレーターからのフィードバックが判断に反映されたかどうかを明示します。
  14. スプリントは、受け入れ済みのディスカバリーまたはレビュー済みのスプリントプレビューから取り出すデリバリースライスです。
  15. デフォルトの WIP は、制約付きのデュアルトラックです。アクティブなイニシアチブごとに、アクティブなデリバリースプリントを 1 つ、アクティブなディスカバリーを 1 つとします。ウェーブのディスカバリーは、アクティベーション、移行、またはルート変更の場合にのみアクティブになります。
  16. 将来の作業は、確定前であればルートまたはイニシアチブローカルのオプションボードに置けます。オプションは期間レーン内でドキュメントの順序に従って並べますが、デリバリーの確約、ステータス台帳、実行キューではありません。
  17. オプションを昇格、却下、統合、または完了し、受け入れ先の成果物が永続的な記録を管理するようになったら、そのオプションを削除します。オプションボードに Done レーンを設けないでください。
  18. 新しいウェーブまたはイニシアチブをアクティブにする前に、ルートのオプションと、終了するイニシアチブの未解決のローカルオプションをレビューします。
  19. イニシアチブを終了する前に、すべてのローカルオプションを昇格、移動、却下、または削除します。完了したカードをオプションボード自体にアーカイブしないでください。
  20. ウェーブまたはイニシアチブの移行時、オプションの昇格時、イニシアチブのクローズアウト時、ターミナル監査時、オプションからスプリントプレビューを取り出す際に、オプションの検証を実行します。
  21. 成果物の所有権、ライフサイクルゲート、スキャフォールドの出力、移行ポリシー、復旧コンテキストに影響する再利用可能なワークフローシステムの変更には、簡潔なワークフロー改善ディスカバリー、または同等の受け入れ済み判断記録が必要です。
  22. 候補は触れる際に再検証します。最新のエビデンスに基づいて準備されていない候補は、実行前に新たなディスカバリーまたはプレビューを通過する必要があります。ルートを変える不確実性がある場合はディスカバリーを使用し、登録済みの候補を開始前に改めて検証する場合に限り、レビュー済みプレビューを使用します。
  23. Discovery Triage は、プレビューの付録ではなく、フェイルクローズの Routing Preflight です。レビュー済みプレビューを選ぶ前に、トリガーカテゴリーと次のいずれか 1 つの結果を記録します:preview_ok、discovery_required、operator_decision_needed、not_triggered。トリガーカテゴリーには、自律性、権限、ランタイム境界、ポリシー、エビデンス、相互運用性、エージェントの振る舞いの変更、エージェントループ、ハーネス、ループの継続、目標の判断、予算、チェックポイントが含まれます。トリガーされたエビデンスによってルート、契約、スコープ、検証、ランタイム境界、実装パスが変わる可能性がある場合は、discovery_required を記録します。preview_ok が有効なのは、ルートがすでに決定されており、トリガーのエビデンスによってそれらの判断が変わる可能性がない場合に限ります。not_triggered は、具体的な理由がある場合にのみ使用します。
  24. ディスカバリーに基づく順序変更は、受け入れ前に所有する roadmap.md に反映する必要があります。クローズアウトに基づく次のルートの変更は、スプリントのクローズアウト前に反映する必要があります。
  25. スプリントプレビューでは、トリガーされた場合にリポジトリが所有する運用サーフェスを特定します。所有者、ライフサイクル、可視性、安全性ポリシー、検証パス、インベントリ/トポロジー/レジストリ/ルートマップへの影響が含まれます。これらの事実に関する不確実性によってスコープ、アーキテクチャ、リスク、受け入れ基準が変わる可能性がある場合は、実行前にディスカバリーへ進めます。
  26. 各ウェーブとイニシアチブでは、プロダクトまたはユーザー価値、デリバリーフロー、品質または安定性、コンテキストまたはエビデンスのコストについて、定性的な成果シグナルを記録します。これはルーティング用のシグナルであり、メトリクス台帳ではありません。
  27. 各イニシアチブとスプリントでは、賭けの枠組みを簡潔に記録します。アペタイト、成功のエビデンス、サーキットブレーカー、非目標、延期の経路を含みます。
  28. ウェーブとイニシアチブでは、デフォルトでアペタイト枠内の予測を使用します。予測数は確約ではなく、順序の拡大は自動的な適応ではありません。作業を追加するには、エージェントが選択肢、トレードオフ、推奨経路を提示し、オペレーターの明示的な判断を仰ぐ必要があります。
  29. ウェーブとイニシアチブの憲章には Forecast And Appetite を記録し、ロードマップには Forecast Control を記録します。ディスカバリーとレビュー済みプレビューでは、順序を変更する場合に Forecast Impact を記録します。
  30. スプリントプレビューでは、プロダクトインクリメントへの貢献を direct、enabling、audit のいずれかで記録します。enabling スプリントでは、妨げている目に見えるインクリメントと、direct スライスが実行可能ではない理由を明記する必要があります。
  31. enabling または前提条件となるスプリントが 2 回連続した場合、ルートレビューを行います。垂直方向の実証版の出荷、スコープの削減/延期、ルート変更、または追加の enabling 作業の明示的な購入を提案します。
  32. 主要なケイパビリティ候補では、受け入れ前に前提条件となるリスクと、最初に利用可能なプロダクトインクリメントを細分化します。
  33. レビューモードでは、先に進むというリクエストによってプレビューのみを開始します。実行は、その後に明示的な承認を得てから開始します。
  34. 新しいスプリントパックには、decision-log.md、closeout.md、evidence/index.md を含めます。
  35. evidence/index.md は、T4 の主張から証明へのルーターです。検証済みの主張、エビデンスファイル、必須の客観的ゲート、任意または未トリガーのゲート、編集上の扱い、昇格先、読み取りポリシーを記録します。物語形式のクローズアウトにはしません。
  36. スプリントエビデンス配下の生成されたランタイム状態(プロジェクト固有のスクラッチディレクトリを含む)は、デフォルトではローカルのスクラッチです。レビュー済みでシークレットを含まないエビデンスファイル、または明示的に承認されたエクスポートのみをコミットします。
  37. スプリントのクローズアウトには、必須の成果と学びのレビューを含め、次の 4 つの問いに答えます。このスプリントで何を達成したか、プロジェクトをどのように改善したか、何をより良くできたか、そして得られた学びによって次のルートが変わるのか、ローカルにとどめるのか、ワークフローの改善が示唆されるのか。
  38. スプリントのクローズアウトでは Forecast Delta を記録します。計画と実績、判明した隠れた前提条件、残りの予測への影響、ロードマップ、インデックス、ステータスを更新したかどうかを含みます。
  39. 重要なクローズアウトの主張は、evidence/index.md で裏付ける必要があります。元の目標を合格としてクローズする一方で、必須の客観的証明を延期することはできません。必須の証明が不足しているか不合格の場合、オペレーターが明示的にスコープを変更するか、証明が合格するまで、スプリントはアクティブまたはブロック状態のままです。
  40. スプリントのクローズアウトには、プロセス上の摩擦、エビデンスのコスト、コンテキストのコスト、判断の遅延、必要に応じたワークフローの調整、目的シグナル、制御可能性、繰り返し発生する摩擦を確認するレトロのエビデンスチェックに焦点を当てたミニレトロを含めます。
  41. 繰り返し発生する、または構造的なワークフロー上の摩擦は、このスキルに昇格させます。一度限りのリポジトリ固有の摩擦はローカルにとどめます。
  42. プロジェクトの進化モードは、ホストがレビュー済みの互換性を維持する判断を記録しない限り、デフォルトで forward-only です。
  43. アクティブな進化モードで前方移行が必要な場合、大規模な境界変更には影響インベントリを含める必要があります。また、クローズアウト前に、影響を受ける所有対象のサーフェスをそれぞれ更新、削除、または明示的に延期する必要があります。
  44. ソースパックは保持コンテキストであり、実行許可、ライブ状態、バックログではありません。
  45. トレーストークンは所有者専用の検索アンカーです。広範なワークフロー検索の前に、トリガーされた T3 イニシアチブの index.md にあるトレースルートを使用します。ディスカバリー、スプリントパック、クローズアウト、判断ログ、エビデンスインデックスにトレーストークンを追加しないでください。

インタラクションモード

  1. reviewed がデフォルトです。実行前にプレビューし、明示的な承認を得てから開始し、実行後にレポートを提示して、クローズアウト後に一時停止します。
  2. flow:実行前に簡潔なメモを提示し、実行後にレポートを提示して、手動で次に進みます。
  3. auto:実行前の分析は内部で行い、ブロッカー、競合、またはパスを左右する判断で中断が必要な場合を除いて、自動的に次へ進みます。
  4. continuous / yolo:通常は一時停止しませんが、すべてのゲート、成果物、中断ルールは引き続き適用されます。

モードによって変わるのは、可視性と一時停止の動作です。準備状況、エビデンス、書き戻しの要件が緩和されることはありません。

目標完了ルール

目標を完了できるアクションを選択してください。受け入れ済みのスプリント目標と終了基準に必要なすべての作業を実装し、検証します。無関係な範囲の拡大は避けますが、スコープや予算を維持するためだけに、必要な証明を削除、先送り、分割してはいけません。

スプリント、プレビュー、クローズアウトで smallest、narrow、only as needed などの表現が使われている場合、最初の対象テストに合格するだけの最小パッチではなく、目標を完了できる最小の垂直スライスと解釈してください。スプリントのスコープで指定された、影響を受けるリポジトリ管理下のすべての領域、必須のエビデンスゲート、すべての終了基準は、オペレーターが明示的に目標を変更しない限り、引き続きスコープに含まれます。

トリガーに応じた参照資料の読み込み

  • [phase:lifecycle-detail] 詳細な運用ルール、WIP ポリシー、reviewed モードのプレビュー、復旧については、references/workflow-contract.md を読んでください。
  • [phase:artifact-create|artifact-validate] ワークフロー成果物を作成または検証する場合は、references/artifact-contracts.md を読んでください。
  • [edge:context-management|frontmatter|context-budget] context_tier、summary_budget_lines、フェーズごとの読み込み予算、アトラスルート、コンテキストレシート、保持されたコンテキストの読み込み、エビデンス/書き戻しレシートの形式を解釈する場合は、references/context-management.md を読んでください。
  • [edge:trace-token|trace-lookup|workflow-search] ワークフロー履歴を検索する場合、トレース ID またはタグを解釈する場合、トレースメタデータを追加する場合、またはトレースアンカーの配置先を判断する場合は、references/trace-tokens.md を読んでください。
  • [phase:gate-eval|closeout|readiness] 準備状況、クローズアウト、アーカイブ、完了を評価する場合は、references/validation-and-completion.md を読んでください。
  • [edge:helper-use] 決定論的ヘルパーを使用または説明する前に、references/scaffold-helper.md を読んでください。
  • [edge:strict-placeholder-validation|options-validation] 厳密なプレースホルダー検証が関係する場合は、references/placeholder-contract.md を読んでください。オプションボードの検証、遷移チェック、クローズアウトチェックが関係する場合は、references/validation-and-completion.md を読んでください。
  • [edge:governance-escalation] 明示的なガバナンスマッピングが有効な場合に限り、references/governance-bridge.md を読んでください。
  • [edge:authoring-conventions] 共有ルーティング、命名、選択式質問の作成規約を変更する場合は、../ub-authoring/references/authoring-conventions.md を読んでください。

同梱アセット

正規テンプレートとして assets/operations-root/ と assets/initiative-template/ を使用してください。ブートストラップ、ウェーブ、イニシアチブ、ディスカバリー、ソースパック、スプリント、アーカイブの各操作には、scripts/scaffold_workflow.py を使用してください。オプションボードの遷移、クローズアウト、ターミナル監査、古いカードの検証には、scripts/check_workflow_options.py を使用してください。

出力要件

重要度の高いワークフロー作業については、次の項目を報告してください。

  1. レーンとスケールの判断。
  2. アクティブな成果物のオーナー。
  3. WIP とゲートの状態。
  4. パスの選択が重要な場合は、選択したパスと却下した代替案。
  5. 検証とエビデンスの要件。
  6. 次に許可されるアクション。

コメント