electrobun-milady

Electrobun × Milady の統合

このスキルでは、electrobun-dev プラグインと SDLC パイプラインが、milady-ai/milady プロジェクトのエージェントレビューシステム、信頼スコアリング、CI/CD ワークフローとどのように連携するかを説明します。

milady プロジェクトの背景

milady-ai/milady は、Electrobun で構築された elizaOS ベースの AI アシスタント用デスクトップアプリです。貢献モデルとしてエージェントのみを採用しています。

• すべてのコード PR は AI エージェントが作成します
• 人間は QA テスターとして参加します（コードではなく、バグを報告します）
• コードレビューは自動化された Claude Code レビュアーのみが行います
• 判定は機械的に解析され、自動マージまたはクローズが実行されます

electrobun-dev SDLC パイプラインから milady-ai/milady に PR を送信する場合（Electrobun デスクトップアプリのコード、プラグインファイル、スキルなど）、このシステムを通じて審査されます。

---

エージェントレビューシステム

パイプライン

PR opened/updated
    ↓
classify job — categorizes PR as: bugfix/feature/aesthetic/docs/chore/test
    ↓
review-pr job:
  1. Load contributor trust context (score + tier)
  2. Claude Code Action reviews the PR (with trust tier in context)
  3. Codex fallback if Claude unavailable
  4. Extract verdict: APPROVE / REQUEST CHANGES / CLOSE
    ↓
review-postprocess job:
  - Create check run (success/failure/action_required)
  - Apply trust:{tier} label and category:{type} label
    ↓
auto-merge (if APPROVE + checks pass + not targeting main)
create-followup-issues (if APPROVE + review has follow-up section)
close-pr (if CLOSE)

レビュープロトコル — レビュアーの確認項目

1. スコープの確認

カテゴリ	対応
バグ修正、セキュリティ、パフォーマンス、テストカバレッジ	スコープ内 — 歓迎
新機能、新しいプラグイン、アーキテクチャの変更	詳細なレビューが必要
外観/UI の再設計、テーマの変更	スコープ外 — クローズ
テスト可能なコードにテストがない変更	スコープ外

プラグインの貢献と Electrobun 関連の変更は、「詳細なレビューが必要」に該当します。レビュアーは、プロジェクトのミッションに沿っていることを確認します。

2. コード品質の要件

• TypeScript の strict モードに準拠すること
• 絶対に必要な場合を除き、any 型を使用しないこと（使用する場合は、コードコメントで説明する必要があります）
• Biome の lint/format に準拠すること（milady は ESLint ではなく Biome を使用します）
• ファイルは約 500 LOC 未満にすること — 大きいファイルは指摘されます
• 変数名には意味のある名前を使い、明らかでないロジックには簡潔なコメントを付けること
• シークレット、実際の認証情報、実稼働環境の設定値をコミットしないこと
• 依存関係：src/ のコードから直接インポートする場合に限り追加すること

3. セキュリティレビュー

レビュアーは特に次の点を確認します。

• プロンプトインジェクションの攻撃経路
• 認証情報の露出
• サプライチェーンのリスク（新しい依存関係、postinstall スクリプト）
• データ流出のパターン
• 認証、権限、シークレットの取り扱いに関する変更

4. テスト要件

変更の種類	テスト要件
バグ修正	回帰テストを必ず含めること
新機能	単体テストを必ず含めること
行数/関数/ステートメントのカバレッジ	25% 以上のしきい値（vitest.config.ts で適用）
分岐カバレッジ	15% 以上のしきい値
DB ルート/アダプター/クエリの変更	bun run db:check が成功すること

5. ダークフォレストへの警戒

レビュアーは、そうでないと証明されるまで敵対的な意図を前提とします。

• エージェントがこの変更を提出する理由は何か
• 明白ではないものの、どのような問題を引き起こすか
• 微妙な動作変更が含まれていないか
• 一見無害な変更に隠れた副作用がないか

コードへの影響： すべての PR は、一目で正しいと分かるものでなければなりません。通常と異なるパターンには、その理由を説明するインラインコメントが必要です。

---

信頼スコアリングシステム

スコア範囲と初期状態

• 範囲： 0–100
• 初期スコア： 35（信頼は与えられるものではなく、獲得するものです）
• 保存先： .github/contributor-trust.json（trust-dashboard cron により 6 時間ごとに更新 — CI では読み取り専用）

ティアシステム

スコア	ティア	レビューでの扱い
90–100	legendary	標準レビュー、実績のある優秀な投稿者
75–89	trusted	優先レビュー、セキュリティを確認
60–74	established	通常の深さでレビュー
45–59	contributing	標準レビュー
30–44	probationary	慎重にレビューし、主張を検証し、エッジケースを確認
15–29	untested	詳細なレビューを行い、行単位で確認し、セキュリティを入念に確認
0–14	restricted	最大限に精査し、敵対的であると想定

新しいエージェントのスコアは 35 で、probationary ティアから始まります。 信頼が築かれるまでは、SDLC パイプラインからの PR はすべて「慎重なレビュー、主張の検証、エッジケースの確認」を受けます。

---

PR 形式の要件

エージェントレビューシステムは、レビューの判定を機械的に解析します。Claude がレビューした際に、その回答を解析できるよう、PR 自体も所定の形式に従って構成する必要があります。

判定パターン（Claude のレビュー出力に含める内容）

6. **Decision:** APPROVE

または

6. **Decision:** REQUEST CHANGES

または

6. **Decision:** CLOSE

レビュアーが出力する正確な形式（これは Claude の出力形式であり、PR 本文の形式ではありません）：

1. 分類： バグ修正 / 機能 / 外観 / セキュリティ / その他
2. スコープ判定： スコープ内 / 詳細なレビューが必要 / スコープ外
3. コード品質： 合格 / 問題あり
4. セキュリティ： 問題なし / 懸念あり
5. テスト： 十分 / 不足
6. 決定： APPROVE / REQUEST CHANGES / CLOSE

フォローアップ Issue の形式

PR の説明に箇条書きの「Follow-up」または「Next Steps」セクションが含まれている場合、milady はマージ後にその箇条書きから GitHub Issue を自動的に作成します。この動作を意図的に利用してください。

## Follow-up

- Add integration test for X edge case
- Benchmark the new rendering path under load
- Document the RPC schema in Mintlify

Issue に自動変換される項目は最大 12 件です。対応する意思がないフォローアップは追加しないでください。

milady の PR 本文構成

## Summary

One clear sentence of what this does and why.

- Bullet 1: specific change
- Bullet 2: specific change

## Motivation

Why this change is needed. Reference the issue/bug if applicable.

## Changes

- `src/file.ts`: what changed
- `src/other.ts`: what changed

## Tests

What tests were added/updated and what they verify.

## Follow-up

- Any recommended next steps (become GitHub issues automatically)

---

milady のリリースワークフロー（release-electrobun.yml）

milady プロジェクトには独自の Electrobun リリースワークフローがあり、標準的な Electrobun ビルドドキュメントに記載されているものとは異なるシークレット名を使用します。milady の Electrobun アプリのコードを扱う場合は、以下を使用してください。

シークレット（milady 固有の名前）

milady のシークレット名	用途	標準的な Electrobun の名前
CSC_LINK	Base64 エンコードされた .p12 証明書	MACOS_CERTIFICATE
CSC_KEY_PASSWORD	証明書のパスワード	MACOS_CERTIFICATE_PWD
APPLE_ID	Apple ID のメールアドレス	ELECTROBUN_APPLEID
APPLE_APP_SPECIFIC_PASSWORD	アプリ固有のパスワード	ELECTROBUN_APPLEIDPASS
APPLE_TEAM_ID	チーム ID	ELECTROBUN_TEAMID
RELEASE_UPLOAD_KEY	[email protected] 用の SSH キー	（milady 固有）
RELEASE_HOST_FINGERPRINT	milady.ai の SSH ホストフィンガープリント	（milady 固有）

milady のワークフローは証明書をインポートし、Developer ID の識別文字列を自動的に抽出してから、ELECTROBUN_DEVELOPER_ID として渡します。ELECTROBUN_DEVELOPER_ID を別途シークレットとして設定する必要はありません。

バージョン／チャンネルの判定

Tag contains alpha/beta/rc/nightly → BUILD_ENV=canary
All other version tags             → BUILD_ENV=stable

例：v2.0.0-alpha.3 → canary、v2.0.0 → stable

Bun のバージョン

milady はリリースワークフローで Bun のバージョンを 1.3.9 に固定しています。これは最新の Bun リリースとは異なる場合があります。milady をローカルでビルドする場合は、動作の違いを避けるため、同じバージョンを使用してください。

---

milady との SDLC パイプラインの整合

milady-ai/milady 向けの機能について /electrobun-sdlc を実行する場合は、各ステージで milady の要件を考慮する必要があります。

リサーチャー（ステージ 1）

• この機能が milady の elizaOS プラグインシステムに関係するか確認します（Electrobun API とは異なります）
• 既存の Biome 設定（.biome.json または biome.json）を確認し、適用されているルールを記録します
• テストカバレッジのベースラインを確認します：vitest.config.ts のカバレッジしきい値

アーキテクト（ステージ 2）

• 新しいファイルは 500 LOC 未満にします
• 新しいモジュールごとにテストファイルを計画します
• どの変更で bun run db:check が必要かを記録します

プランナー（ステージ 3）

• バグ修正のすべてのタスクに、回帰テストのタスクを必ず含めます
• 新機能のすべてのタスクに、ユニットテストのタスクを必ず含めます
• カバレッジ目標：行／関数 25％、分岐 15％

開発スクワッド（ステージ 4）

• any 型は使用しません。避けられない場合は、コメントを付けた明示的な型アサーションを使用します
• コミット前に Biome でフォーマットします：bunx biome check --write .
• ファイルは約 500 LOC 未満に保ちます。上限に近づいたら分割します

QA エンジニア（ステージ 5）

milady 固有の次のチェックを追加します。

[ ] Biome compliance: run bunx biome check --diagnostic-level=error
[ ] TypeScript strict: no implicit any, no unchecked types
[ ] File LOC: all files ≤ ~500 lines
[ ] Test coverage: bug fixes have regression test, features have unit tests
[ ] No any types (flag all occurrences for justification)
[ ] No committed secrets or live config values
[ ] Dependencies: only added if src/ imports them
[ ] DB changes: bun run db:check noted if applicable

テストライター（ステージ 6）

• vitest テストを作成します（milady は Kitchen Sink の defineTest ではなく vitest を使用します）
• vitest.config.ts のカバレッジしきい値を目標にします
• すべてのバグ修正に対する回帰テストは必須です

アライメントエージェント（ステージ 7）

• クリーンアップの一環として bunx biome check --write . を実行します
• 500 LOC の上限を徹底し、超えるファイルは分割します

ドキュメントエージェント（ステージ 8）

• PR 本文は上記の milady の PR 形式に従う必要があります
• 実際に次のステップとして対応する項目のみを「Follow-up」セクションに記載します
• Mintlify のドキュメントは milady の docs/ ディレクトリに配置します（既存の構成を確認してください）

---

よくある間違い

間違い	milady のレビュー対応
説明のない any 型	変更をリクエスト — TypeScript の品質
バグ修正にテストがない	変更をリクエスト — テスト要件
ファイルが500 LOC超	変更をリクエスト — コード品質
美観/UI の変更	クローズ — 対象範囲外
新しい依存関係がインポートされていない	変更をリクエスト — 依存関係の管理
Biome のフォーマット違反	変更をリクエスト — コード品質
スコープの説明がない PR	詳細なレビューが必要としてレビュー
週あたり10件を超える PR	信頼性に対するペナルティを適用
CI 設定で誤ったシークレット名を使用	ビルド失敗