mcpField
B
build-now-adapt-later

build-now-adapt-later

github.com/rheinmir開発10247 回インストール2 週間前に更新
リポジトリ

build-now-adapt-later について

build-now-adapt-laterは、一部が未確定でも大半の作業を進められる場合に使う開発スキルです。仮定を単一のアダプター境界に隔離し、安定した契約に基づいてコアを構築・テストできます。

主な機能

  1. 01未確定事項と情報源の洗い出し
  2. 02安定したドメイン契約の定義
  3. 03仮定を設定とアダプターに隔離
  4. 04契約に基づくコアの構築とテスト
  5. 05適合性テストと適応チェックリストの準備
  6. 06境界外への仮定の漏出防止

活用シーン

  1. 01仕様が不明なハードウェアプロトコルの開発
  2. 02外部 API にアクセスできない段階での構築
  3. 03本番環境依存の値とコアロジックの分離

インストール

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

$npx skills add https://github.com/rheinmir/setup --skill build-now-adapt-later

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

詳細

スキル:build-now-adapt-later

確実な部分を今すぐ出荷し、不確実な部分を切り分けて、後で仕上げる際に変更するファイルを1つにします。

内容

目的とコンテキスト
  • 目的: 不足している情報や未検証の情報によってタスクがブロックされている場合、未知の要素に依存しないものをすべて今すぐ構築し、未知の要素を1つのアダプター境界の背後に隔離します。これにより、後で適応する際の変更は1ファイルで済みます。
  • 使用するタイミング: タスクに、まだ特定できない事実がいくつか含まれている場合(文書化されていないバイト配置、未確認のポートやエンディアン、まだ呼び出せない外部 API、実際のハードウェアや本番環境でしか判明しない値など)。ただし、作業の大部分はそれらの事実に本質的に依存していません。不確実な情報を待ってプロジェクト全体を止めたり、推測した値をコードベース全体に散在させたりしないでください。境界を1つ設けます。
  • 対象外: 未知の要素がタスク全体に及ぶ場合(例:「何を作るべきかわからない」)、または今すぐ低コストで解決できる場合は使用しないでください(その場合は解決してください)。また、推測を検証済みであるかのように示さないでください。確定しているものを「念のため」に抽象化しないでください(過剰なエンジニアリングです)。
メンタルモデル

安定した ドメイン契約 に依存するものはすべて、今構築してテストします。 未知の要素 に依存するものはすべて、1つのアダプターの背後に置き、文書化された最善の推測をデフォルトとし、 verified:false と明示します。変更は1か所で済むようにします。

unknowns (⚠️ + source-of-truth) → 安定した契約(⚠️なし) → 隔離(設定1つ + アダプター1つ、verified:false) → 契約に基づいてコアを構築 → 同じ契約でモックを作成 → 適応キット(チェックリスト + 適合性テスト) → 境界を保護

入出力契約
項目必須?意味
入力タスク + ⚠️「要検証」項目を含む仕様はい作業の大部分は未知の要素に依存しません
入力各未知要素に関する最善の推測を記したドキュメントいいえ不足している場合でも、デフォルト値には出典を記載し、安全側に倒す必要があります
出力契約(ドメイン型/インターフェース)はい⚠️の値を含みません
出力設定 + 隔離されたアダプターはいすべての未知要素を含み、verified: false とし、各 ASSUMPTION に出典を記載します
出力今日 E2E で実行できるコア + モックはい契約に基づいてビルドおよびテストします
出力ADAPT-CHECKLIST + 適合性テスト/ベクトルはいverified:true に切り替える前のゲートです
出力引き継ぎはい構築・検証済みのもの、推測にとどまるもの、各 ⚠️ を確定するための1ファイルでの手順
ルールと機能
  • RULE-01(必須):アダプターとその設定だけが、未知の要素を置く唯一の場所です。同じ推測が2つのファイルにある場合、漏洩です。
  • RULE-02(必須):すべての推測に明示的なフラグと出典を付けます。コードでも文章でも、推測を検証済みとして示してはいけません。
  • RULE-03(必須):verified:false の間のデフォルト動作は、楽観的ではなく 安全側 にしてください。適合性によって証明されるまで、推測が誤っているものとして扱います(特に物理的、金銭的、または破壊的なものについて)。
  • RULE-04(必須):真に未知のものだけを隔離します。確定しているものを「念のため」に抽象化しないでください。これは分離ではなく、過剰なエンジニアリングです。
  • RULE-05(必須):下流の作業が依存する成果物は契約です。契約を安定させ、推測ごとにではなく、意図的に拡張します。
  • RULE-06(必須):引き継ぎでは、構築・検証済みのもの、推測にとどまり保留中のもの、各 ⚠️ を確定するための1ファイルでの手順を明確に記載します。
  • 機能:既存の仕様/ドキュメントを読むこと、プロジェクトコード(契約、コア、アダプター、モック、テスト)を書くこと。実際のハードウェア/本番環境へのアクセスは不要です。
失敗時の境界
  • 主な未知要素がタスク全体に及ぶ(「何を作るべきかわからない」) → このスキルは 適用せず、ユーザーに確認します。
  • 未知の要素を低コストで解決できる → すぐに調べ、隔離しません。
  • 推測値が2か所に現れる → 分離が破られています → 修正されるまで ブロック(ステップ7)。
  • 適合性テストに合格していない → verified:false を維持し、デフォルト動作は安全側に倒します(部分的。引き継ぎで明記してください)。

手順

主なワークフロー
StepTypeInputsActionOutputs/exitFailure/next
W01判断仕様不明点を列挙し、⚠️ と情報源を付ける不明点の一覧簡単に調べられる → 不明点ではない
W02判断不明点安定した境界(コントラクト)を定義する⚠️ を含まないコントラクトコントラクトに ⚠️ が含まれる → やり直す
W03副作用不明点隔離する:設定ファイル 1 つ + アダプター 1 つ、最善の推測値 + verified: false設定ファイル + アダプター—
W04副作用コントラクト境界より上のすべてを完全に構築するテスト済みのコア隔離した値をインポート → 修正
W05副作用コントラクト + アダプター同じコントラクトを使用するモック/スタブオフライン E2E—
W06副作用アダプターAdapt-kit を提供する:ADAPT-CHECKLIST + 適合性検証キット—
W07決定的コードベース境界を保護する(lint/レビュー時の注意書き)漏れなし漏れ → 次に進む前に修正

各ステップの詳細(W01~W07 の信頼できる情報源):

  1. 不明点を列挙します。 把握していない、または検証できない事実をすべて列挙します。それぞれに ⚠️ を付け、信頼できる情報源(実機、実稼働データ、手元にないドキュメント、関係者の決定)を記録します。「事実」を今すぐ簡単に調べられるなら、調べてください。それは不明点ではありません。

  2. 安定した境界(コントラクト)を定義します。 それ以外のすべてが利用する、ドメインレベルのインターフェースを記述します。つまり、未知のエンコーディングではなく、意図を表す型/関数シグネチャ/メッセージスキーマです。ルール:コントラクトに ⚠️ の値を含めてはいけません。(例:バイトオフセットではなく SemanticCommand/Telemetry モデル、ゲートウェイのワイヤ形式ではなく PaymentRequest。)

  3. 不明点を隔離します。 不明点に依存する定数はすべて 1 つの設定ファイルに、ロジックはすべて 1 つのアダプターモジュールにまとめ、コントラクトの背後に配置します。手元にあるドキュメントをもとに最善の推測値を設定し、それぞれに // ASSUMPTION (source / not verified) と明記して、verified: false フラグを明示的に追加します。不明点を把握するのはアダプターだけです。

  4. 境界より上のすべてを完全に構築します。 UI、ビジネスロジック、トランスポート、安全性/エラー処理、検証を、すべてコントラクトに基づいて実装し、完成させてテストします。隔離された値をインポートすることはありません。

  5. 同じコントラクトを使用するモック/スタブを構築します。 実際の不明点がわからなくても、システム全体を今すぐエンドツーエンドで実行できます。モックは同じアダプター/設定を使用するようにし、後で適合性検証ハーネスとしても使えるようにします。

  6. Adapt-kit を提供します。 (a) 不明点が判明した後に確定するための正確な手順(設定を編集 → アダプターを編集 → 適合性検証を実行 → verified:true に変更)を記載した簡潔な ADAPT-CHECKLIST と、(b) 推測値を信頼して本番環境または実機で使用する前に合格しなければならない適合性テスト/ベクトルを用意します。

  7. 境界を保護します。 隔離された値がアダプターの外に漏れてはならないことを、lint ルールまたはレビュー時の注意書きとして追加します。推測した定数が 2 か所に現れたら、すでに分離が破綻しています。次に進む前に修正します。

分岐
IDKindGuard動作Skip / failure再合流
B01復旧W07 で推測値が 2 か所にあることが判明アダプター/設定に移し、2 つ目を削除する—W07
B02条件付き必須プロジェクトに llmwiki/ があるドラフトレポートを作成する(「成果物」項目)llmwiki/ がない → スキップ終了
検証と停止条件

必須:コアテストとモック E2E がコントラクト上で成功すること。適合性テスト/ベクトルだけが verified:true に変更するためのゲートです。レビュー必須:コントラクトに ⚠️ が含まれないこと、境界から漏れがないこと(lint ルールまたはレビュー時の注意書き)。引き継ぎに、構築・検証済みの項目と、推測・保留中の項目がすべて記載された時点で停止します。

例
  • 適用例: lite3-controller-ui — MotionSDK プロトコル(コマンドコード、バイトオフセット、エンディアン、ポート)はハードウェアで未検証です → SemanticCommand/Telemetry のコントラクトを定義し、protocol.config + motionsdk-codec を隔離し、UI/WS/ブリッジ/安全機能をすべてビルドします。UDP モックホストでオフラインの E2E テストを実現し、Adapt-kit によってプロトコルの確定を 1 ファイルの編集で行えるようにします。
  • 境界/失敗例: ユーザーが「このアプリで何をするのか分からないけれど、とにかく先にビルドして」と言う → 不明点がタスク全体に及ぶ → スキルを適用せず、要件を確認します。決済ゲートウェイのワイヤーフォーマットが不明な場合、デフォルトの verified:false では実際の取引を拒否する必要があります(フェイルセーフ)。成功すると仮定してはいけません。
参考 — クイックテンプレート(スタックに合わせて調整)
contract/         # stable domain types — NO unknown values        (built now, tested now)
  └ model.*       #   intent-level: commands, telemetry, requests
core/             # UI / logic / transport / safety on the contract (built now, tested now)
adapter/
  ├ config.*      # ⚠️ ALL unknown constants + verified:false       (quarantine)
  └ codec.*       # ⚠️ encode/decode against the unknown            (quarantine, swap 1 file)
mock/             # speaks the same adapter → E2E offline + conformance harness
ADAPT-CHECKLIST.* # 5-step finalize procedure when the unknown is known
conformance.*     # vectors that gate verified:true
参考 — 作業例(この例から導き出されました)

lite3-controller-ui:MotionSDK プロトコル(コマンドコード、バイトオフセット、エンディアン、ポート)は、実際のハードウェアでは未検証でした。コントラクトは SemanticCommand/Telemetry、隔離対象は protocol.config + motionsdk-codec です。UI/WS/ブリッジ/安全機能はすべてコントラクトを基に構築し、UDP モックホストによってオフラインで完全な E2E テストを実現しました。Adapt-kit(チェックリスト + 適合性テストベクトル)により、プロトコルの最終確定を 1 ファイルの編集で行えるようにしました。llmwiki/wiki/draft/orca/150626-lite3-adapter-isolation.md を参照してください。

納品 — 出力レポート(プロジェクトに llmwiki/ がある場合のみ)

作業完了後、意思決定を追跡できるよう、ドラフトレポートを作成します。

1. ファイル名: llmwiki/wiki/draft/orca/DDMMYY-<ten>.md — DDMMYY = 今日の日付、<ten> = kebab-case の 2~4 語。

2. 記述内容:

---
type: draft
title: "DDMMYY-<ten>"
status: proposed
tags: [<skill-name>, output-report]
timestamp: YYYY-MM-DD
---

# DDMMYY-<ten>
**Type:** draft
**Status:** proposed
**Tags:** build-now-adapt-later, output-report
**Proposed:** YYYY-MM-DD

## What
<One sentence — what was built now vs what was quarantined>

## Boundary
- Contract: <the stable domain types/interface>
- Quarantine: <config + adapter files holding the ⚠️ unknowns>

## Unknowns (⚠️) pending verification
| Unknown | Best-guess source | Finalize by |
|---------|-------------------|-------------|

## Files
| File | Action |
|------|--------|

## Notes
- Invoked via: `/build-now-adapt-later` skill

## Origin
- **Draft:** `wiki/draft/orca/DDMMYY-<ten>.md`
- **Commit:** _(filled by verify-before-commit)_
- **Date promoted:** _(filled by verify-before-commit)_

3. llmwiki/wiki/index.md に行を追加し、llmwiki/wiki/log.md に行を追加します。

コメント