electrobun-milady

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Electrobun × Milady Integration

Electrobun × Milady 集成

This skill covers how the electrobun-dev plugin and SDLC pipeline integrate with the milady-ai/milady project's agent review system, trust scoring, and CI/CD workflows.

本 skill 介绍 electrobun-dev 插件和 SDLC 流水线如何与 milady-ai/milady 项目的 Agent 评审系统、信任评分及 CI/CD 工作流集成。

The milady Project Context

milady 项目背景

milady-ai/milady

is an elizaOS-based AI assistant desktop app built with Electrobun. It uses an agents-only contribution model:

All code PRs come from AI agents
Humans serve as QA testers (bug reports, not code)
An automated Claude Code reviewer is the sole code reviewer
Verdicts are machine-parsed and trigger auto-merge or close

When our electrobun-dev SDLC pipeline submits PRs to milady-ai/milady (Electrobun desktop app code, plugin files, or skills), they go through this system.

milady-ai/milady

是一个基于 elizaOS、使用 Electrobun 构建的 AI 助手桌面应用。它采用 仅限 Agent（agents-only） 的贡献模式：

所有代码 PR 均来自 AI Agent
人类仅担任 QA 测试人员（提交 Bug 报告，不贡献代码）
自动化的 Claude Code 评审器是唯一的代码评审者
评审结论会被机器解析，并触发自动合并或关闭

当我们的 electrobun-dev SDLC 流水线向 milady-ai/milady 提交 PR（Electrobun 桌面应用代码、插件文件或 skills）时，PR 会经过此系统。

Agent Review System

Agent 评审系统

Pipeline

流水线

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)

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)

Review Protocol — What the Reviewer Checks

评审协议——评审器检查的内容

1. Scope Check

Category	Treatment
Bug fixes, security, performance, test coverage	IN SCOPE — welcome
New features, new plugins, architectural changes	REQUIRES DEEP REVIEW
Aesthetic/UI redesigns, theme changes	OUT OF SCOPE — close
Changes without tests for testable code	OUT OF SCOPE

Plugin contributions and Electrobun-related changes fall under "REQUIRES DEEP REVIEW". The reviewer verifies they align with project mission.

2. Code Quality Requirements

TypeScript strict mode compliance
No
any
types unless absolutely necessary (must explain in code comment)
Biome lint/format compliance (milady uses Biome, not ESLint)
Files under ~500 LOC — larger files get flagged
Meaningful variable names, brief comments on non-obvious logic
No committed secrets, real credentials, or live config values
Dependencies: only add if
```
src/
```
code directly imports them

3. Security Review

The reviewer specifically checks for:

Prompt injection vectors
Credential exposure
Supply chain risks (new dependencies,
```
postinstall
```
scripts)
Data exfiltration patterns
Changes to auth, permissions, or secret handling

4. Test Requirements

Change Type	Test Requirement
Bug fix	MUST include regression test
New feature	MUST include unit tests
Lines/functions/statements coverage	≥25% threshold (vitest.config.ts enforced)
Branches coverage	≥15% threshold
DB route/adapter/query changes	`bun run db:check` must pass

5. Dark Forest Awareness

The reviewer assumes adversarial intent until proven otherwise:

Why would an agent submit this change?
What does it break that isn't obvious?
Does it introduce subtle behavior changes?
Are there hidden side effects in innocent-looking changes?

Implication for our code: Every PR must be obviously correct. Unusual patterns must have inline comments explaining why.

1. 范围检查

类别	处理方式
Bug 修复、安全性、性能、测试覆盖率	IN SCOPE——欢迎
新功能、新插件、架构变更	REQUIRES DEEP REVIEW
外观/UI 重设计、主题变更	OUT OF SCOPE——关闭
可测试代码的变更未附带测试	OUT OF SCOPE

插件贡献和 Electrobun 相关变更均归入「REQUIRES DEEP REVIEW」。评审器会核实它们是否符合项目使命。

2. 代码质量要求

符合 TypeScript strict mode 要求
除非绝对必要，否则不得使用
```
any
```
类型（必须在代码注释中说明原因）
符合 Biome lint/format 要求（milady 使用 Biome，而非 ESLint）
文件保持在约 500 LOC 以下——更大的文件会被标记
使用有意义的变量名，并对不易理解的逻辑添加简短注释
不得提交 secret、真实凭据或线上配置值
仅当
```
src/
```
代码直接导入时才能添加依赖

3. 安全审查

评审器会重点检查：

Prompt 注入攻击面
凭据泄露
供应链风险（新增依赖、
```
postinstall
```
脚本）
数据外泄模式
对身份验证、权限或密钥处理的更改

4. 测试要求

变更类型	测试要求
Bug 修复	MUST 包含回归测试
新功能	MUST 包含单元测试
行/函数/语句覆盖率	≥25% 阈值（由 `vitest.config.ts` 强制执行）
分支覆盖率	≥15% 阈值
DB route/adapter/query 变更	`bun run db:check` 必须通过

5. Dark Forest 意识

评审器默认变更存在对抗性意图，直到证明并非如此：

Agent 为什么要提交这项变更？
它会破坏哪些不明显的地方？
它是否引入了细微的行为变化？
看似无害的变更中是否藏有副作用？

**对我们代码的影响：**每个 PR 都必须显而易见地正确。非常规模式必须附有内联注释说明原因。

Trust Scoring System

信任评分系统

Score Range and Initial State

分数范围和初始状态

Range: 0–100
Initial score: 35 (trust is earned, not given)
Storage:
```
.github/contributor-trust.json
```
(updated every 6h by trust-dashboard cron — read-only in CI)

**范围：**0–100
**初始分数：**35（信任需要 earns，而不是直接获得）
存储位置：
```
.github/contributor-trust.json
```
（由 trust-dashboard cron 每 6 小时更新，在 CI 中只读）

Tier System

等级系统

Score	Tier	Review Treatment
90–100	legendary	Standard review, proven elite
75–89	trusted	Expedited review, check security
60–74	established	Normal review depth
45–59	contributing	Standard review
30–44	probationary	Careful review, verify claims, check edge cases
15–29	untested	Deep review, line-by-line, extra security
0–14	restricted	Maximum scrutiny, assume adversarial

New agents start at 35 — probationary tier. Every PR from our SDLC pipeline will receive "careful review, verify claims, check edge cases" scrutiny until trust is built.

分数	等级	评审方式
90–100	legendary	标准评审，已证明属于精英层级
75–89	trusted	快速评审，检查安全性
60–74	established	正常评审深度
45–59	contributing	标准评审
30–44	probationary	谨慎评审，核实各项声明，检查边缘情况
15–29	untested	深入评审，逐行审查，额外安全检查
0–14	restricted	最严格审查，假定存在对抗意图

**新 Agent 从 35 分开始——属于 probationary 等级。**在建立信任之前，我们 SDLC 流水线提交的每个 PR 都会接受“谨慎评审、核实各项声明、检查边缘情况”的严格审查。

PR Format Requirements

PR 格式要求

The agent-review system machine-parses the review verdict. Our PRs themselves must be structured so that when Claude reviews them, its response will be parseable.

agent-review 系统会以机器方式解析评审结论。因此，我们的 PR 本身也必须采用结构化格式，以确保 Claude 评审后生成的响应可以被解析。

Verdict Pattern (what Claude's review output must contain)

结论模式（Claude 评审输出必须包含的内容）

6. **Decision:** APPROVE

6. **Decision:** REQUEST CHANGES

6. **Decision:** CLOSE

The exact format the reviewer produces (this is Claude's output format, not our PR body format):

Classification: bug fix / feature / aesthetic / security / other
Scope verdict: in scope / needs deep review / out of scope
Code quality: pass / issues found
Security: clear / concerns
Tests: adequate / missing
Decision: APPROVE / REQUEST CHANGES / CLOSE

6. **Decision:** APPROVE

或

6. **Decision:** REQUEST CHANGES

或

6. **Decision:** CLOSE

评审器输出的确切格式如下（这是 Claude 的输出格式，而不是我们的 PR 正文格式）：

Classification: bug fix / feature / aesthetic / security / other
Scope verdict: in scope / needs deep review / out of scope
Code quality: pass / issues found
Security: clear / concerns
Tests: adequate / missing
Decision: APPROVE / REQUEST CHANGES / CLOSE

Follow-up Issues Format

Follow-up Issue 格式

If our PR description includes a "Follow-up" or "Next Steps" section with bullet points, milady automatically creates GitHub issues from those bullets after merge. Use this intentionally:

markdown

undefined

如果我们的 PR 描述中包含带项目符号列表的

Follow-up

或

Next Steps

章节，milady 会在合并后自动根据这些项目符号创建 GitHub issues。请有意识地使用此功能：

markdown

undefined

Follow-up

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


Max 12 items auto-converted to issues. Don't add follow-ups unless you mean them.

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


最多可以将 12 个项目自动转换为 issues。除非确实需要，否则不要添加 follow-ups。

PR Body Structure for Milady

milady 的 PR 正文结构

markdown

undefined

markdown

undefined

Summary

One clear sentence of what this does and why.

Bullet 1: specific change
Bullet 2: specific change

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

```
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)

---

Any recommended next steps (become GitHub issues automatically)

---

milady Release Workflow (release-electrobun.yml)

milady 发布工作流（release-electrobun.yml）

The milady project has its own Electrobun release workflow with different secret names from what the standard Electrobun build documentation describes. When working on milady's Electrobun app code, use these:

milaby 项目拥有自己的 Electrobun 发布工作流，其 secret 名称 与标准 Electrobun 构建文档所述不同。处理 milady 的 Electrobun 应用代码时，请使用以下配置：

Secrets (milady-specific names)

Secrets（milady 专用名称）

milady Secret Name	Purpose	Standard Electrobun Name
`CSC_LINK`	Base64-encoded .p12 certificate	`MACOS_CERTIFICATE`
`CSC_KEY_PASSWORD`	Certificate password	`MACOS_CERTIFICATE_PWD`
`APPLE_ID`	Apple ID email	`ELECTROBUN_APPLEID`
`APPLE_APP_SPECIFIC_PASSWORD`	App-specific password	`ELECTROBUN_APPLEIDPASS`
`APPLE_TEAM_ID`	Team ID	`ELECTROBUN_TEAMID`
`RELEASE_UPLOAD_KEY`	SSH key for releases@milady.ai	(milady-specific)
`RELEASE_HOST_FINGERPRINT`	SSH host fingerprint for milady.ai	(milady-specific)

The milady workflow imports the certificate and automatically extracts the Developer ID identity string, then passes it as
ELECTROBUN_DEVELOPER_ID
. You do not need to set
ELECTROBUN_DEVELOPER_ID
as a secret separately.

milady Secret 名称	用途	标准 Electrobun 名称
`CSC_LINK`	Base64 编码的 .p12 证书	`MACOS_CERTIFICATE`
`CSC_KEY_PASSWORD`	证书密码	`MACOS_CERTIFICATE_PWD`
`APPLE_ID`	Apple ID 邮箱	`ELECTROBUN_APPLEID`
`APPLE_APP_SPECIFIC_PASSWORD`	App 专用密码	`ELECTROBUN_APPLEIDPASS`
`APPLE_TEAM_ID`	团队 ID	`ELECTROBUN_TEAMID`
`RELEASE_UPLOAD_KEY`	用于 releases@milady.ai 的 SSH 密钥	（milady 专用）
`RELEASE_HOST_FINGERPRINT`	milady.ai 的 SSH 主机指纹	（milady 专用）

milady 工作流会导入证书并自动提取 Developer ID 身份字符串，然后将其作为
ELECTROBUN_DEVELOPER_ID
传递。你无需单独将
ELECTROBUN_DEVELOPER_ID
设置为 secret。

Version/Channel Determination

版本/渠道判定

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

Example:

v2.0.0-alpha.3

→ canary,

v2.0.0

→ stable

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 Version

Bun 版本

milady pins Bun to

1.3.9

in its release workflow. This may differ from the latest Bun release. When building milady locally, use the same version to avoid behavior differences.

milady 在其发布工作流中将 Bun 固定为

1.3.9

，这可能与最新的 Bun 版本不同。在本地构建 milady 时，请使用相同版本，以避免行为差异。

SDLC Pipeline Alignment with milady

SDLC 流水线与 milady 的对齐

When running

/electrobun-sdlc

for a feature destined for milady-ai/milady, each stage must account for milady's requirements:

针对 milady-ai/milady 运行

/electrobun-sdlc

开发功能时，每个阶段都必须考虑 milady 的要求：

Researcher (Stage 1)

Researcher（第 1 阶段）

Check whether the feature touches milady's elizaOS plugin system (different from Electrobun APIs)
Check for existing Biome config (
```
.biome.json
```
or
```
biome.json
```
) — note rules in force
Check test coverage baseline:
```
vitest.config.ts
```
coverage thresholds

检查该功能是否涉及 milady 的 elizaOS 插件系统（与 Electrobun API 不同）
检查现有 Biome 配置（
```
.biome.json
```
或
```
biome.json
```
），并记录当前生效的规则
检查测试覆盖率基线：
```
vitest.config.ts
```
中的覆盖率阈值

Architect (Stage 2)

Architect（第 2 阶段）

Keep new files under 500 LOC
Plan test files for every new module
Note which changes need
```
bun run db:check
```

将新文件控制在 500 LOC 以下
为每个新模块规划测试文件
记录哪些更改需要执行
```
bun run db:check
```

Planner (Stage 3)

Planner（第 3 阶段）

Every task for a bug fix MUST include a regression test task
Every task for a new feature MUST include a unit test task
Coverage target: 25% lines/functions, 15% branches

Bug 修复的每项任务都 MUST 包含回归测试任务
新功能的每项任务都 MUST 包含单元测试任务
覆盖率目标：行/函数覆盖率 25%，分支覆盖率 15%

Dev Squad (Stage 4)

Dev Squad（第 4 阶段）

No
```
any
```
types — use explicit type assertions with comments if unavoidable
Format with Biome before committing:
```
bunx biome check --write .
```
Files must stay under ~500 LOC — split if approaching

不使用
```
any
```
类型；如果不可避免，请使用明确的类型断言并添加注释
提交前使用 Biome 格式化：
```
bunx biome check --write .
```
文件必须保持在约 500 LOC 以下——接近上限时应拆分

QA Engineer (Stage 5)

QA Engineer（第 5 阶段）

Add these milady-specific checks:

[ ] 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

添加以下 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

Test Writer (Stage 6)

Test Writer（第 6 阶段）

Write vitest tests (milady uses vitest, not Kitchen Sink defineTest)
Target coverage thresholds from vitest.config.ts
Regression tests for every bug fix are non-negotiable

编写 vitest 测试（milady 使用 vitest，而非 Kitchen Sink defineTest）
以
```
vitest.config.ts
```
中的覆盖率为目标
每个 Bug 修复都必须包含回归测试，这是不可妥协的要求

Alignment Agent (Stage 7)

Alignment Agent（第 7 阶段）

Run
```
bunx biome check --write .
```
as part of cleanup pass
Enforce 500 LOC limit — split files that exceed it

在清理阶段运行
```
bunx biome check --write .
```
强制执行 500 LOC 上限——拆分超出上限的文件

Docs Agent (Stage 8)

Docs Agent（第 8 阶段）

PR body must follow the milady PR format above
Include "Follow-up" section with genuine next-step items only
Mintlify docs go in milady's
```
docs/
```
directory (check existing structure)

PR 正文必须遵循上述 milady PR 格式
仅在确有后续事项时添加
```
Follow-up
```
章节
Mintlify 文档应放在 milady 的
```
docs/
```
目录中（检查现有结构）

Common Mistakes

常见错误

Mistake	milady Review Response
`any` types without explanation	REQUEST CHANGES — TypeScript quality
No tests for a bug fix	REQUEST CHANGES — test requirements
File >500 LOC	REQUEST CHANGES — code quality
Aesthetic/UI change	CLOSE — out of scope
New dependency not imported	REQUEST CHANGES — dependency hygiene
Biome format violations	REQUEST CHANGES — code quality
PR without scope context	Reviewed as REQUIRES DEEP REVIEW
>10 PRs/week	Trust velocity penalty applied
Using wrong secret names in CI config	Build failure

错误	milady 评审响应
使用 `any` 类型但未作说明	REQUEST CHANGES——TypeScript 质量
Bug 修复未附测试	REQUEST CHANGES——测试要求
文件超过 500 LOC	REQUEST CHANGES——代码质量
外观/UI 变更	CLOSE——超出范围
添加未被导入的依赖	REQUEST CHANGES——依赖治理
违反 Biome 格式要求	REQUEST CHANGES——代码质量
PR 未提供范围上下文	按 REQUIRES DEEP REVIEW 评审
每周提交超过 10 个 PR	应用信任速度惩罚
CI 配置中使用错误的 secret 名称	构建失败