Communityコーディング&開発github.com

DLMクローズリリース7 ポータブル

安全なDLMクロージ、オプションのリリース検証、およびオプションのGitコミットを、任意のリポジトリに対して連携実行するスキルです。ユーザーがタスクのクローズや決算、リリースの準備や検証、バージョン更新、スコープ完了のコミットを依頼した際に使用します。コミット、プッシュ、タグ、デプロイ、成果物コピーは別々の明示的権限とします。

DLMクローズリリース7 ポータブル とは?

このスキルは、タスク完了、知識沈殿、リリース制作、バージョニング、Gitコミット、デプロイメントを混同せずに、1つの検証済みエンジニアリングスコープをクローズするためのポータブルな個人スキルです。`close-only`(クローズのみ)、`release-verify`(リリース検証)、`release-commit`(リリース+コミット)の3つのモードを提供し、最小権限の原則で動作します。対応プラットフォームはGitベースの任意のリポジトリで、PowerShellコマンド、`dlm-load`、`dlm-reflect`、`dlm-sediment`、`dlm-version-master`などのツールと連携します。リポジトリ固有のリリースプロファイル(none/dotnet/custom)に従い、凍結された承認基準に基づいてクロージャレビュー、沈殿、ビルド検証、ステージング、コミットを段階的に実行します。変更の所有権を明確にし、許可されていない変更を決してステージングしない安全設計が特徴です。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/atlasray66-collab/agent-dlm-skills/tree/main/skills/dlm-close-release

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

DLM クローズリリース 7 ポータブル

目的

タスク完了、知識沈殿、リリース制作、バージョニング、Gitコミット、またはデプロイメントを混同せずに、1つの検証済みエンジニアリングスコープをクローズします。この個人スキルがライフサイクルを指揮します。リポジトリ契約と子スキルはそれぞれの技術的ルールを保持します。

成果ガバナンスゲート

すべてのクロージャ書き込み、リリース/バージョン変更、正式監査、ステージング、またはコミットの前に、共有のDLM成果ガバナンスを読み、適用します。

  • エンジニアリングターゲット状態、証拠状態、DLM調整状態、リリース状態、Git状態、デプロイメント状態、フィールド受入状態を分離します。一方を進めても他方を意味しません。
  • 承認されたモードに対して1つの受入ベースラインを解決します。クロージャ書き込みまたはリリース/Git変更の前に、ベースライン所有者がターゲット、非目標、承認スコープ、必要な証拠、基準、停止ラインを1回凍結します。ハッシュ、BOM/EOL、チェックアウト表現、受領書はそれを凍結または無効にしません。
  • クロージャ/沈殿/リリースレコードは、該当する契約/決定によって要求または消費された場合にのみターゲット作業となります。純粋な管理変更は、無関係なビルド/テスト/監査を再開しません。
  • 安定したターゲット状態に対しては、最大1回の正式な完全監査を使用し、ユーザー、承認された契約、または重大なリスクがそれを正当化する場合のみとします。修復後は、失敗した条件と直接の回帰のみを再検証します。

最も狭い権限モードを選択

モード許可されるアクション典型的な意図
close-onlyクロージャレビュー、沈殿、DLM検証「タスクを閉じる」「完了を沈殿する」
release-verifyclose-only + リポジトリのリリース/バージョンビルドと成果物メタデータ検証「リリースを準備」「リリースバージョンを検証」
release-commitrelease-verify + 正確なパスでのステージングとコミット「バージョンを更新しGitにコミット」

デフォルトは close-only とします。コミット要求はプッシュ、タグ、デプロイ、公開、または成果物コピーを許可しません。それぞれ別途承認されます。文言がGit/バージョン変更を区別するのに不十分な場合は、停止して質問します。

リポジトリと契約のロック

  1. 1つのGitルートを解決し、その AGENTS.md とDLM契約を読みます。
  2. タスクとリリースプロファイルに必要な最小限の dlm-load を実行します。
  3. この個人スキルをリポジトリにコピーしたり、コンテキストマニフェストに追加したりしないでください。
  4. リポジトリで宣言されたリリースプロファイルを使用します:
    • none:ユーザーが手順を提供しない限り、クローズのみ。
    • dotnet:コンポジションモードで dlm-version-master を使用。
    • custom:リポジトリ所有のバージョン/ビルド/検証契約を使用。
  5. マルチリポジトリまたはサブモジュール作業では、Gitルートごとに個別の許可リスト、検証結果、コミットを使用します。クロスリポジトリの原子性を主張しないでください。

フェーズ0 — スコープスナップショット

書き込みの前に、この結合されたライター/スコープ安全スナップショットを1回実行します:

git status --short
git diff --name-status
git diff --cached --name-status
git ls-files --others --exclude-standard

タスク所有の候補、既存の無関係な変更、事前ステージングされたファイルの正確なセットを構築します。ユーザーの意図、凍結承認スコープ、タスク文書、diffから所有権を確立できない場合は、変更前に停止します。単に承認証拠を製造するためにスナップショットを繰り返さないでください。決して git add . または git add -A を使用しないでください。

フェーズ1 — クロージャレビュー

凍結された基準と主張に一致する証拠に対して、対象を絞ったクロージャレビューを実行します。dlm-reflect を使用します。正式な独立レビューは、ユーザーが要求する場合、承認された契約が要求する場合、または重大なリスクがそれを正当化する場合を除き、オプションです。宣言された完了レベルが証明されたら続行し、または重大な未解決ギャップを現在のスコープ作業/ブロックとしてルーティングします。ビルド成功だけでは動作、UI、ハードウェア、移行、安全性、またはフィールドの証拠ではありません。同様に、古い管理インデックスだけでは証明された動作を否定しません。

フェーズ2 — 沈殿

ユーザーが沈殿を要求した場合、承認されたリポジトリ/タスク契約がそれを要求する場合、または実際のローディング/リリース/決定コンシューマーが同期を必要とする場合、dlm-sediment をコンポジションモードで1回実行します。確認されたタスク/ドメイン知識とステータスのみを書き込みます。BRIEF/L0承認ゲートは引き続きアクティブです。子スキルは正確な変更パスを返す必要があり、ステージングやコミットを行ってはなりません。そのようなトリガーが存在しない場合は、sediment: not required を記録し、検証済みのエンジニアリング結論を保持します。

実際のタスク/知識コンシューマーのために1回同期し、既存の証拠を再利用します。調整レコードのみが変更されたために、同義の受領書を作成したり、無関係なエンジニアリング検証を再実行したりしないでください。

close-only の場合、承認されたクロージャにDLM状態が含まれるか、現在の契約/コンシューマーの主張がそれに依存する場合にのみDLMヘルスチェックを実行し、その後クロージャレポートで停止します。該当しないチェックをスキップしても失敗ではありません。

フェーズ3 — リリース検証

リリースモードの場合のみ:

  1. リポジトリのリリースプロファイルと正確な出力スコープを解決します。
  2. バージョン意図を決定します。Major/minor には明示的な意図が必要です。Patch/auto は、リリース意図が存在し、リポジトリ契約がそのデフォルトを宣言している場合のみ許可されます。
  3. リポジトリのバージョン/ビルドプロセスを、その契約が別途指定しない限り、直列に実行します。
  4. テストを実行し、凍結されたリリース基準/プロファイルによって要求される公開バイナリ/パッケージメタデータとハッシュを検証します。レビューアの好みによるチェックを新しいリリース条件として追加しないでください。
  5. 意図的なバージョン状態、チェンジログ、リリースインフラストラクチャ、タスク所有のソースファイルのみを候補許可リストに追加します。

ビルド、テスト、ハッシュ、またはメタデータの失敗は、凍結リリースベースライン、リポジトリプロファイル、または実証された重要な出力リスクによってそのチェックが必要とされる場合、コミット/リリースの主張をブロックします。無関係な既存または管理上の失敗は個別に報告され、リリース基準を黙って拡大することはありません。

フェーズ4 — 正確なステージングセットゲート

release-commit の場合のみ:

  • 許可リストをリポジトリ相対の正確なパスに正規化します。
  • 現在のステージング済みファイルを事前ステージングスナップショットと比較します。
  • ユーザーの作業をアンステージしないでください。事前ステージングされたファイルが許可リストの範囲外にある場合は、停止して報告します。
  • 許可リストに含まれるファイルに安全に分割できない無関係な既存の変更が混在している場合は、停止して質問します。
  • シークレット、マシンローカル設定、bin/、obj/、out/、ログ、キャプチャ、公開/ステージング出力、一時的な成果物を、明示的に要求され適切でない限り除外します。
  • リポジトリによって要求される空白/エンコーディングチェックを実行します。

フェーズ5 — ステージングとコミット

git add -- <exact-paths>
git diff --cached --name-status
git diff --cached --stat
git diff --cached --check
git status --short

ステージングされたパスと承認された許可リストの完全一致を要求します。コミットの前に、グローバルな AGENTS.md によって要求されるプレコミットレビュー(ponytail-review ゲートとそのガードマーカー)およびリポジトリによって要求されるレビューを、この正確なステージング差分に対して実行します。各所見をそれらのルールの要求に従って解決するか、明示的に保持します。必要なレビュースキルまたはフックが利用できない場合は、コミットする前に停止し、バイパスせずにそのギャップを報告します。Gitルートごとにリポジトリの慣習を使用して1回コミットします。要求がない限り修正(amend)しないでください。コミット後、git show --stat --oneline HEAD と残りのワークツリーを検査します。

障害ルール

  • 子コマンドの非ゼロ終了コードは、現在の凍結基準、該当契約、影響を受ける成果物の整合性チェック、または重要な安全性/リリース境界に失敗した場合のみ、後のフェーズをブロックします。無関係な既存および管理上の失敗は、新しいゲートになることなく報告されます。
  • ブロックされたタスクはクローズされません。その理由、所有者、試行回数、リリース条件を保持します。
  • キャンセルされた作業は、成功したリリースを装うことなく、キャンセル状態を保持しても構いません。
  • 出力ロックは報告され、強制削除されません。
  • 無関係な作業はそのまま残ります。
  • ベースラインの無効化は、新しいSSOTの競合、誤った前提、安全性、またはデータ損失のリスクのために予約されています。EOL/BOM、clean/smudge、タイムスタンプ、表示順序、または受領書のみの変更は、完全な検証を無効にしたり再開したりしません。

最終レポート

モード、リポジトリ/プロジェクト識別情報、受入ベースラインの状態/所有者/停止ライン、クロージャレビューの種類/評決、沈殿コンシューマー/パス、DLMチェック、リリースプロファイルとバージョン変更、主張に一致する検証済み成果物、ステージング許可リスト、コミットハッシュ(ある場合)、ブロッキングギャップとアドバイザリーギャップ、および意図的に触れていない無関係なファイルを報告します。コミット/プッシュ/タグ/デプロイ/成果物コピーのうち、どれが実行されなかったかを明示的に述べます。承認されたモードの境界で停止します。次のサブタスク、作業項目、保留中の所見、プッシュ、タグ、またはデプロイメントを自動的に起動しないでください。

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

関連スキル