Electrobun Milady

Electrobun × Milady Integration

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.

The milady Project Context

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.

Agent Review System

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)

Review Protocol — What the Reviewer Checks

1. Scope Check

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

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.

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)

Tier System

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.

PR Format Requirements

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.

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

6. **Decision:** APPROVE

or

6. **Decision:** REQUEST CHANGES

or

6. **Decision:** CLOSE

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

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

Follow-up Issues Format

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:

## 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.

PR Body Structure for Eliza

## 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 Workflow (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:

Secrets (milady-specific names)

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.

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

Bun Version

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.

SDLC Pipeline Alignment with milady

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

Researcher (Stage 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

Architect (Stage 2)

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

Planner (Stage 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

Dev Squad (Stage 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

QA Engineer (Stage 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

Test Writer (Stage 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

Alignment Agent (Stage 7)

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

Docs Agent (Stage 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)

Common Mistakes