levelup-publish

levelup-publish

このスキルの機能

承認済みCDRをteam-ai-directivesチームAIディレクティブ内の実際の成果物に変換し、ドラフトPRを作成します。

CDRライフサイクルにおける実装フェーズです。

• 承認済みCDRをシグナルゲートに照らして検証する
• 公開前にCDR間の競合を検出する
• コンテキストモジュールファイル（ルール、ペルソナ、例、憲章）を生成する
• 評価タイプのCDR向けに評価用ゴールデンセットファイル（goldset.md + goldset.json）を生成する
• スキル成果物（SKILL.md + .skills-entry.json）を生成する
• .skills.jsonマニフェストを更新する
• team-ai-directives内のCDR.mdインデックスを更新する
• ブランチを作成し、コミットして、ドラフトPRを作成する

CDRが/levelup-clarifyを通じて承認されるまで、このスキルは実行されません。

使用するタイミング

• /levelup-clarifyの後：承認済みCDRを公開する必要がある場合
• 単一スキルのビルド：--skill <name|CDR-id>を使って1つのスキルをビルドする場合
• コンテキストモジュールのみ：--context-onlyを使ってスキルの生成をスキップする場合

使用しないタイミング

• 承認済みCDRがない場合：最初に/levelup-clarifyを実行してください
• team-ai-directivesに未コミットの変更がある場合：最初に作業ツリーをクリーンにしてください
• パターンを見つける場合：/levelup-initまたは/levelup-specifyを使ってください
• CDRをレビューする場合：/levelup-clarifyを使ってください

プロセス

ユーザー入力

$ARGUMENTS

入力が空でない場合は、必ず続行前にユーザー入力を考慮してください。

ユーザー入力の例：

• "--ready" — ドラフトではなく、レビュー可能なPRを作成する
• "--skip-skills" — スキルのCDRを含めない
• "--context-only" — コンテキストモジュールのみをビルドする
• "--skill CDR-005" — CDR-005のスキルのみをビルドする
• "CDR-001 CDR-003" — 特定のCDRのみを実装する
• 空の入力：すべての承認済みCDRをドラフトPRとして実装する

フラグ

• --ready：ドラフトではなく、レビュー可能なPRを作成する
• --skip-skills：スキルタイプのCDRをスキップする
• --context-only：コンテキストモジュールのみをビルドする（すべてのスキルをスキップ）
• --skill <name|CDR-id>：特定の承認済みスキルCDRから1つのスキルのみをビルドする

役割とコンテキスト

あなたはコンテキストパブリッシャーとして、承認済みCDRをローカルのドラフトからteam-ai-directivesへ移行します。

役割には次の作業が含まれます。

• CDRが承認済みで、準備が整っていることを検証する
• CDRの内容からコンテキストモジュールファイルを作成する
• スキルタイプのCDRからスキル成果物を作成する
• Git操作（ブランチ、コミット、プッシュ、PR）を管理する

概要

1. 環境のセットアップ（フェーズ0）：パスを解決し、承認済みCDRを一覧表示する
2. 前提条件の確認（フェーズ1）：team-ai-directivesが設定済みで、クリーンであることを確認する
3. シグナルゲートの検証（フェーズ2）：具体的な証拠がないCDRを除外する
4. CDR間の競合チェック（フェーズ3）：重複する対象とルールの競合を検出する
5. ブランチの準備（フェーズ4）：team-ai-directivesにブランチを作成する
6. コンテキストモジュールの生成（フェーズ5）：ルール／ペルソナ／例／憲章をビルドする
7. 評価用ゴールデンセットの生成（フェーズ6）：評価CDR向けにgoldset.md + goldset.jsonをビルドする
8. スキルの生成（フェーズ7）：SKILL.md + .skills-entry.jsonをビルドする
9. log.mdの更新（フェーズ8）：ディレクトリごとのlog.mdにOKF §9の項目を追記する
10. AGENTS.mdの確認（フェーズ9）：存在しない場合は作成する
11. コミットとPR（フェーズ10）：変更を公開する
12. 概要（フェーズ11）：結果を報告する

実行手順

フェーズ 0：環境設定

実行します：

scripts/bash/setup-levelup-publish.sh

REPO_ROOT、TEAM_AI_DIRECTIVES、CDR_DRAFTS_DIR、ACCEPTED_CDRS、TD_CONFIGURED、TD_IS_GIT、TD_CLEAN の JSON を解析します。

セットアップスクリプトが利用できない場合、または失敗した場合は、手動で解決します。

1. REPO_ROOT — cwd から上位にたどって .adlc/ を探すか、git rev-parse --show-toplevel を実行するか、pwd を使用します。
2. TEAM_AI_DIRECTIVES — TEAM_AI_DIRECTIVES 環境変数、次に .adlc/init-options.json → team_ai_directives、次に REPO_ROOT/team-ai-directives。
3. CDR_DRAFTS_DIR — REPO_ROOT/.adlc/drafts/cdr
4. ACCEPTED_CDRS — grep -l '^### Status: \*\*Accepted\*\*' CDR_DRAFTS_DIR/CDR-*.md を実行し、ID を抽出します。
5. TD_IS_GIT — git -C "$TEAM_AI_DIRECTIVES" rev-parse --is-inside-work-tree（終了コード 0 = true）。
6. TD_CLEAN — git -C "$TEAM_AI_DIRECTIVES" status --porcelain（空 = クリーン）。

TD_IS_GIT が false の場合、フェーズ 10（ブランチ／コミット／PR）は実行できません。team AI directives に対して git init を実行するか、git を使わずにファイルを直接書き込むかを提案します。

フェーズ 1：前提条件の確認

Team Directives が設定されていることを確認します：

Team AI directives repository not configured.
Run: team-setup
Or set: export TEAM_AI_DIRECTIVES=/path/to/team-ai-directives

作業ツリーを確認します：

TD_CLEAN が false の場合：

team-ai-directives has uncommitted changes.
Please commit or stash changes before running /levelup-publish.

承認済み CDR を確認します：

ACCEPTED_CDRS が空の場合：

No accepted CDRs found.
Run /levelup-clarify to accept CDRs first.

フェーズ 2：シグナルゲートの検証

承認済みの各 CDR について、以下の 4 つの基準に照らして評価します。

1. チーム全体への適用可能性：このパターンは複数のプロジェクト／チームに適用されますか。それとも 1 つのプロジェクトに固有ですか。CDR のコンテキストや根拠が、一般化できる教訓を含まず、単一プロジェクトの内部情報のみを参照している場合は → スキップします（理由：「プロジェクト固有」）。

2. 根拠の品質：CDR は具体的なファイルパス、コミット SHA、またはテストケースを参照していますか。根拠のセクションが空、または曖昧（「さまざまなファイル」、「一般的なプラクティス」）な場合は → スキップします（理由：「根拠なし」）。

3. 重複の有無：team-ai-directives 内の既存の指示と重複していませんか。重複する内容がないか、context_modules/rules/、context_modules/examples/、CDR.md を確認します。重複している場合は → スキップします（理由：「重複」）。

4. 価値の高さ：これは本当に役立つパターンですか。それとも、あれば便利な程度の小さな利便性ですか。CDR に「価値が低い」または「小さな利便性」と明記されている場合、あるいはパターンが些細なもの（例：「セミコロンを使う」）である場合は → スキップします（理由：「価値が低い」）。

いずれかの基準を満たさない CDR はスキップします。スキップした CDR はローカルの下書きに残します。

報告します：

## Signal Gate Validation

**Passing**: N | **Skipped**: M

### Skipped CDRs

| CDR | Reason |
|---|---|
| CDR-003 | No evidence |
| CDR-005 | Project-specific |

フェーズ 3：CDR 間の競合確認

以下を確認します。

1. ターゲットの重複：複数の CDR が同じモジュールパスを対象としている
2. ルールの競合：同じ懸念事項に対して、異なる実装がある
3. 未解決の不整合：タイプが「Inconsistency」の CDR が「Resolved」とマークされていない

競合が見つかった場合：

Cross-CDR conflicts detected. Resolve via /levelup-clarify before implementing.

フェーズ 4：ブランチの準備

team-ai-directives にブランチを作成します（TD_IS_GIT=false の場合はスキップします。git の操作はフェーズ 10 で処理します）。

cd "$TEAM_AI_DIRECTIVES"
git checkout -b "levelup/$(basename "$REPO_ROOT")" main 2>/dev/null || git checkout -b "levelup/$(basename "$REPO_ROOT")"

フェーズ 5：コンテキストモジュールの生成

受理された各スキル以外の CDR について、対象ファイルを作成または更新します。

CDR からのフィールドの抽出：CDR では1行形式のフィールド（### Field: value）を使用します。### プレフィックスの後の行を解析して値を抽出します。

• title — ## CDR-NNN: 見出しから
• description — ### Descriptor: 行から
• id — ## CDR-NNN 見出しから（例：CDR-001）
• cdr_ref — id と同じ
• domain — ### Domain: 行から（デフォルト：general）
• context-type — ### Context Type: 行から（小文字に変換。デフォルト：rule）
• created — ### Date: 行から（記載がない場合は今日の日付を使用）
• evidence — ### Feature Implementation Evidence または ### Evidence セクションの本文から
• {Content from CDR} — ### Context セクションの本文から
• OKF v0.2 のフィールドは次のように導出します。resource = コンテキストタイプ／ドメイン／ファイルからの相対パス、tags = コンテキストタイプ、generated.at = ISO 8601 形式の日時。evidence の項目がある場合は、それぞれを sources[] エントリーに割り当てます。空の場合は sources を省略します。

ルール（OKF v0.2 フロントマター）：

---
type: Rule
title: {title}
description: {description}
resource: ./context_modules/rules/{domain}/{file}.md
tags: [{context-type}]
generated: { by: agent:levelup-publish, at: {today}T00:00:00Z }
id: {id}
cdr_ref: {cdr_ref}
created: {created}
verified:
  - { by: agent:levelup-publish, at: {today}T00:00:00Z }
status: stable
stale_after: 180d
sources:
  - id: {evidence-id-or-derived}
    resource: {evidence-resource-or-path}
    title: {evidence-title}
---

# {Title}

{Content from CDR}

## Source

Contributed from: {project-name}
CDR: {cdr_ref}

モジュールファイルの書き込み後、context_modules/rules/index.md に1行を追加します（OKF §8 のリスト形式）。

* [{Title}](relative-path.md) - {description}

context_modules/rules/index.md が存在しない場合は、最初に # Rules 見出しを記載して作成します。

ペルソナと例にも、適切な type を指定して同様のテンプレートを使用します。

Constitution：

• Constitution Creation CDR の場合：context_modules/constitution.md を作成します
• Constitution Amendment CDR の場合：既存の constitution に追記します

フェーズ 6：評価用ゴールデンセットの生成

受理された各 eval タイプの CDR について、team-ai-directives/evals/ にゴールデンセットファイルを生成します。

eval CDR からのフィールドの抽出：CDR の1行形式のフィールドを解析します。

• directive_id — ### Paired Directive CDR: 行から（例：CDR-001）
• descriptor — ### Descriptor: 行から
• pass_cases — ### Pass Cases セクションの本文から
• fail_cases — ### Fail Cases セクションの本文から
• adversarial_cases — ### Adversarial Cases セクションの本文から

ステップ 1：eval ディレクトリを作成する

mkdir -p "$TEAM_AI_DIRECTIVES/evals/{directive_id}"

ステップ 2：goldset.md を書き込む

{TEAM_AI_DIRECTIVES}/evals/{directive_id}/goldset.md に書き込みます。

---
type: Eval
title: {title from CDR}
description: {descriptor from CDR}
resource: ./evals/{directive_id}/goldset.md
tags: [eval]
generated: { by: agent:levelup-publish, at: {today}T00:00:00Z }
id: {eval CDR id}
cdr_ref: {eval CDR id}
paired_directive: {directive_id}
created: {date from CDR}
verified:
  - { by: agent:levelup-publish, at: {today}T00:00:00Z }
status: stable
stale_after: 180d
---

# Goldset: {Title}

## Directive Under Test

- **CDR**: {directive_id}
- **Path**: {target module of paired directive CDR}

## Pass Cases

{pass cases from CDR — each with scenario, input, output, why-it-passes}

## Fail Cases

{fail cases from CDR — each with scenario, input, output, why-it-fails, correction}

## Adversarial Cases

{adversarial cases from CDR — each with scenario, expected}

ステップ 3：goldset.json を書き込む

採点時に使用する機械可読形式として、{TEAM_AI_DIRECTIVES}/evals/{directive_id}/goldset.json に書き込みます。

{
  "id": "{eval CDR id}",
  "paired_directive": "{directive_id}",
  "title": "{title}",
  "description": "{descriptor}",
  "cases": [
    {
      "id": "PASS-001",
      "type": "pass",
      "scenario": "...",
      "input_context": "...",
      "expected_output": "...",
      "actual_output": "...",
      "reason": "..."
    },
    {
      "id": "FAIL-001",
      "type": "fail",
      "scenario": "...",
      "input_context": "...",
      "expected_output": "...",
      "actual_output": "...",
      "reason": "...",
      "correction": "..."
    }
  ]
}

ステップ 4：報告する

Eval goldenset published: evals/{directive_id}/goldset.md
Eval goldenset JSON: evals/{directive_id}/goldset.json

フェーズ 7：スキルの生成

--skip-skills が指定されている場合、またはすべてのスキル CDR が除外されている場合はスキップします。

スキルタイプの CDR がある場合（または --skill <name|CDR-id> が指定されている場合）：

1. skills/{name}/SKILL.md を生成します。

---
name: {name}
description: {description from CDR}
disable-model-invocation: true
---

# {name}

## What this skill does

{Summary}

## When to use

- {Trigger 1}
- {Trigger 2}

## Steps

1. {Step 1}
2. {Step 2}

## Example

{Minimal example}

## Verification

{How to verify}

## Related

- CDRs: {cdr_ref}

2. skills/{name}/.skills-entry.json を生成します。

{
  "name": "{name}",
  "description": "{description}",
  "version": "1.0.0",
  "cdr_ref": "{cdr_ref}"
}

3. .skills.json に登録します。

{
  "local:./skills/{name}": {
    "version": "1.0.0",
    "description": "{description}",
    "categories": ["..."]
  }
}

4. AGENTS.md の Skills セクションを新しいスキルで更新します。

フェーズ 8：log.md の更新（OKF §9）

フェーズ 5 でモジュールを書き込んだ、受理された各 CDR について、該当する context_modules/<type>/log.md ファイルにエントリーを追加します（OKF §9 の日付ごとの形式で、新しい順）。

## {today}
* **Creation**: Added [{Title}](relative-path.md) — {one-line description}. CDR: {cdr_ref}.

context_modules/<type>/log.md が存在しない場合は、最初に # {Type} Update Log 見出しを記載して作成します。

**publish では CDR.md を手動で更新しなくなりました。**これは派生成果物であり、/team-repair によって各ディレクトリの index.md ファイルから自動生成されます。PR をマージした後、/team-repair を実行して CDR.md を再生成してください。

フェーズ 9：AGENTS.md の確認

AGENTS.md が存在しない場合は、テンプレートから作成します。

フェーズ 10：コミットと PR

作成されたファイルを確認し、git の判断ツリーに従います。

ケース A：team-ai-directives が git リポジトリである（TD_IS_GIT=true）

1. ブランチを作成します（main が存在する場合は main を使用し、存在しない場合は HEAD を使用します）。

cd "$TEAM_AI_DIRECTIVES"
git checkout -b "levelup/$(basename "$REPO_ROOT")" main 2>/dev/null || git checkout -b "levelup/$(basename "$REPO_ROOT")"

2. コミットします。

git add -A
git commit -m "Add context modules from $(basename "$REPO_ROOT")

CDRs implemented:
- CDR-001: ...
- CDR-002: ...
"

3. リモートを確認します。

git remote get-url origin 2>/dev/null

4a. リモート「origin」が存在し、gh CLI が利用可能な場合 — プッシュしてドラフト PR を作成します。

git push -u origin "levelup/$(basename "$REPO_ROOT")"
gh pr create --draft --title "Add context modules from $(basename "$REPO_ROOT")" --body "..."

4b. リモート「origin」は存在するものの、gh が利用できない場合 — プッシュのみ行い、手動で PR を作成するようユーザーに伝えます。

git push -u origin "levelup/$(basename "$REPO_ROOT")"

次のように報告します：「origin/levelup/{project-name} にプッシュしました。ホスティング先の Git で手動で PR を作成してください。」

4c. リモートが存在しない場合 — ローカルでのみコミットします。次のように報告します：「ローカルブランチ levelup/{project-name} にコミットしました。準備ができたらリモート（git remote add origin <url>）を追加してプッシュしてください。」

ケース B：team-ai-directives が git リポジトリではない（TD_IS_GIT=false）

ユーザーに次の 2 つの選択肢を提示します。

1. git init ＋コミット — git を初期化し、スキャフォールドを使って初回コミットを作成してから、新しいコンテキストモジュールをコミットします。

cd "$TEAM_AI_DIRECTIVES"
git init
git add -A
git commit -m "Initial team-ai-directives scaffold"
git checkout -b "levelup/$(basename "$REPO_ROOT")"
git add -A
git commit -m "Add context modules from $(basename "$REPO_ROOT")"

続けて、上記の手順 3～4（リモートの確認）に従います。

2. ファイルのみ書き込む — すべての git 操作を省略します。ファイルは作業ツリーに直接書き込まれます。次のように報告します：「ファイルを {TEAM_AI_DIRECTIVES} に書き込みました。準備ができたら git を初期化してコミットしてください。」

フェーズ 11：概要

## LevelUp Implement Summary

**Project**: {project-name}
**Branch**: levelup/{project-name}
**CDRs Implemented**: N
**CDRs Skipped (Signal Gate)**: M

### Artifacts Created

| Type | Count |
|---|---|
| Rules | N |
| Personas | N |
| Examples | N |
| Skills | N |
| Constitution Changes | N |
| Evals | N |

### PR Details

**URL**: {PR-URL}
**Status**: Draft

### Next Steps

1. Review PR
2. Merge when approved
3. Run `/team-repair` after merge to re-index and validate

主なルール

承認済みの CDR のみを実装する

• ステータスは Accepted である必要があります
• Discovered／Proposed／Rejected の CDR はスキップします

シグナルゲート

• 厳格モード：具体的な証拠のない CDR はスキップします
• スキップした CDR は、改善のためローカルのドラフトに残します

CDR 間の検証

• 未解決の競合がある場合は停止します
• 解決には /levelup-clarify が必要です

メモリーエンジニアリング

• 公開ファイルには、OKF v0.2 のファミリーを含む YAML フロントマターを記述します：generated、verified（リスト）、status、stale_after
• log.md ファイルには、ディレクトリごとの監査証跡を記録します（OKF §9）
• CDR.md は /team-repair が index.md ファイルから生成するものであり、手動では管理しません

log.md より先にコンテキストモジュールを作成する

• 重要：log.md に追記する前に、すべてのコンテキストモジュールとスキルのファイルを作成します
• log.md のエントリーを先に書き、実際のモジュールを作成しないままにしないでください

ワークフローのガイダンスと移行

/levelup-publish の後

team-ai-directives で PR がマージされた後、/team-repair を実行して次の処理を行います。

• 残っている v0.1 のフロントマターを v0.2 に移行します（常時実行）
• ディレクトリごとの index.md ファイルと log.md ファイルを再構築します
• index.md ファイルから CDR.md のフラットテーブルを再生成します
• 競合スキャンを実行します
• 検証のタイムスタンプを更新します

CDR のライフサイクル全体

/levelup-init or /levelup-specify
    ↓
/levelup-clarify
    ↓
/levelup-publish
    ↓
PR merged
    ↓
/team-repair --validate

次のステップ

実装後、レビューのため PR を確認してください。マージされたら、更新後のチーム AI 指令を検証するために /team-repair を実行します。

検証

• 承認済みのすべての CDR がシグナルゲートを通過したか、明示的にスキップされている
• OKF v0.2 のフロントマター（generated、verified リスト、status、stale_after）を含むコンテキストモジュールファイルが {TEAM_AI_DIRECTIVES}/context_modules/ に作成されている
• ディレクトリごとの index.md エントリーが追記されている（OKF §8 のリスト形式）
• ディレクトリごとの log.md エントリーが追記されている（OKF §9 の日付グループ形式）
• eval タイプの CDR の場合、eval ゴールデンセットファイルが {TEAM_AI_DIRECTIVES}/evals/ に作成されている
• スキルをスキップした場合を除き、スキルディレクトリが {TEAM_AI_DIRECTIVES}/skills/ に作成されている
• .skills.json が新しいスキルで更新されている
• 適切な説明を含むドラフト PR が作成されている
• コミット後、team-ai-directives の作業ツリーがクリーンである
• マージ後：index.md ファイルから派生する CDR.md を再生成するために /team-repair を実行する

コンテキスト

$ARGUMENTS