mcpField
L
land

land

github.com/pwguler開発10848 回インストール3 週間前に更新
リポジトリ

land について

検証済みの変更を取り込むためのワークフロースキルです。開発者がローカルマージ、PR、ブランチ保持、破棄から選べるようにし、仕様、ワークツリー、ブランチの扱いを定められた手順で管理します。

主な機能

  1. 01取り込み前の検証を必須化
  2. 02完了した作業に四つの選択肢
  3. 03仕様の恒久的な決定事項を保存
  4. 04PRとマージの説明文を作成
  5. 05ブランチとワークツリーを安全に管理

活用シーン

  1. 01検証済みの機能ブランチをマージ
  2. 02完了した作業からPRを作成
  3. 03後の作業に備えてブランチを保持
  4. 04確認後にブランチを破棄

インストール

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

$npx skills add https://github.com/pwguler/skills --skill land

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

同梱ファイル

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

references/
architecture-format.md
decision-record.md
terms.md

詳細

検証されていない作業を取り込まないでください。

高速パス:差分が小さく、呼び出しですでにパス(マージ、PR、保持、破棄)が指定されています。この場合はオプションメニューを省略して進めてください。ただし、手順 4 でそのパスが除外される場合を除きます。仕様についての質問は高速パスには含まれません。仕様があり、呼び出しでその扱いが指定されていない場合は、ここで仕様についても尋ねてください。質問は一行で、既定値は保持としてください。

  1. 何かを実行する前に、以下の手順を項目とするタスクリストを作成してください。すでにタスクリストがある場合は、そこに手順を追加してください。各手順は 1 項目とします。選択したパスで手順を省略する場合は、完了としてマークし、項目のテキストに skip: <reason> を追加してください。
  2. verify スキルを読み、その手順に従ってください。ツリーのハッシュが変わっていない場合、既存の証拠記録を再利用します。宣言済みフェーズ内で作成された記録は、そのフェーズの範囲のみを対象とします。そのため、フェーズ内から取り込む場合は、まず完全なゲートを実行してください。次に rubric スキルを読み、その手順に従ってください。作業に docs/specs/<slug>.md の仕様がある場合、不具合チェックを実行します。差分で UI、パブリックインターフェース、名称、または文章が変更される場合は、品質チェックを実行します。仕様に振る舞いではなく品質を示す基準がある場合も、品質チェックを実行します。対応が必要な指摘は implement または debug に戻してください。修正後のツリーに対して、再度 verify に合格する必要があります。検証に失敗した作業は、オプションメニューに進めません。
  3. 環境を確認してください。通常のチェックアウト、名前付きブランチのワークツリー、または detached HEAD のいずれかです。detached HEAD は、外部の何かが管理するワークスペースです。
  4. 説明を添えず、選択肢を正確に 4 つ提示してください。選択肢は、ベースブランチにローカルでマージ、プッシュして PR を作成、ブランチを保持、破棄です。detached HEAD の場合、呼び出しで指定されている場合も含め、マージと破棄の選択肢を除外してください。そのワークスペースは管理元の所有物であることを伝え、残りの選択肢を提示してください。破棄するには、ユーザーが「discard」と入力する必要があります。
  5. マージまたは PR のパスでは、仕様を整理してください。まず、仕様に残すべき内容を移してください。残す価値のある決定は、decision-record.md の説明に従って ADR にします。確定した用語は、terms.md の説明に従って CONTEXT.md に記載します。システム構成の変更は、architecture-format.md の説明に従って ARCHITECTURE.md を更新します。ファイルが存在しない場合は作成してください。この移行は必須です。ユーザーが決めるのは仕様ファイルをどうするかだけです。一行で尋ね、既定値も同じ行に記載してください:ユーザーから別の指定がない限り保持。呼び出しで指定されたパスは、すでにその問いへの回答になっています。たとえば「land: merge, drop the spec」のような指定です。保持パスでは、仕様が引き続き作業の指針となるため、質問せずにそのまま残してください。
  6. 仕様をもとに PR の本文とマージコミットメッセージを作成してください。本文はデモから始めてください。デモには verify の証拠、つまり何を実行し、何が示されたかを記載します。または、変更を試す方法を説明します。次に目標を要約行として、受け入れ基準を変更一覧として、非目標をスコープに関する注記として記載してください。仕様ファイルを残すかどうかにかかわらず、理由は git blame で辿れる恒久的な記録に残してください。
  7. マージパスでは、次の順序で作業してください。メインのチェックアウトからブランチをマージします。マージ後の状態をテストします。一致する証拠記録があれば、それをテストとして認めます。その後、ワークツリーを削除します。最後にブランチを削除します。ワークツリーを削除する前にブランチを削除すると失敗します。ワークツリー内からワークツリーを削除しようとしても失敗します。
  8. PR パスと保持パスでは、ユーザーがさらに作業できるようワークツリーを残します。破棄パスでは、ユーザーが「discard」と入力するまで待ってください。名前付きブランチのワークツリーでは、メインのチェックアウトからワークツリーを削除します。ワークツリーに未コミットの作業がある場合は、git worktree remove --force を使用してください。通常のチェックアウトでは、git switch --discard-changes <base> でベースブランチに切り替えます。未追跡ファイルは残るため、ユーザーにそのファイル名を伝えてください。どちらの場合も、その後 git branch -D でブランチを削除します。リモートにあるブランチのコピーは、ユーザーから指示がない限り残します。

ルール:

  • 強制プッシュは行わず、公開済みのコミットを amend しないでください。ユーザーから明示的に依頼されない限り、--no-verify を使わず、ダーティツリーに対して reset --hard を実行しないでください。
  • ユーザーから削除を依頼されていない仕様書は削除しないでください。沈黙は同意ではありません。ユーザーから返答がない場合は、仕様書を残してください。
  • 削除するのは、取り込むブランチのワークツリーだけにしてください。サブエージェントの実行で作成されたものも含め、ほかのワークツリーには手を触れないでください。そのワークツリーを作成したツールが削除します。削除後に git worktree prune を実行してください。
  • テストなしでマージしないでください。マージ結果のテストを実行してください。ただし、ツリーハッシュがエビデンス記録と一致する場合は除きます。ファストフォワードの場合は記録と一致します。ブランチが分岐した後のマージは、一致しません。
  • マージコンフリクトは、意図を踏まえて、ハンクごとに解決してください。それぞれの側をその出典までたどってください。--abort は解決ではありません。

コメント