feat: extract the generic "Automated AI Engineer" core into a dedicated plugin

[devantler]

🤖 Generated by the Daily AI Assistant

Maintainer prompt (2026-07-03): "Consider if parts of the constitution stored in AGENTS.md files in the monorepo and submodules should be made into a dedicated 'Automated AI Engineer' plugin." Assessment + proposed direction below.

Problem

The Daily AI Engineer's definition lives entirely in the monorepo (AGENTS.md contract + .claude/ agents/skills). A large part of it is genuinely generic — reusable by any org that wants an autonomous engineer over a portfolio — but it is not consumable outside the monorepo, and this repo's own roadmap (#38 T1 "realize not-skills-only", T2 catalogue coverage) wants exactly this kind of flagship agent+skills bundle.

What is generic (plugin material) vs deployment-specific (stays in AGENTS.md)

Generic — the role:

• The run loop: survey → select → act → report; operate-before-advance ladder
• Issue-driven engineering: capture-before-build, drain-oldest-actionable-first, decompose-and-start
• The draft-PR checkpoint model (autonomy up to promotion; promotion as the human gate)
• PR hygiene triad (CI + review threads and review-body findings + conflicts), bot-reviewer handling
• Untrusted-input discipline & trust-gate pattern (exact-login matching, external-PR static-review-only)
• Per-run worktree execution model + git safety
• Self-improvement procedure (evidence-from-own-runs, guard-railed, never weaken)
• Generic agent definitions: the engineer actor + a read-only portfolio surveyor

Deployment-specific — the configuration (NOT plugin material):

• The portfolio map, product cards, and each submodule's AGENTS.md ## Maintenance (validate commands, protected files, labels — repo-specific by definition)
• Concrete trust-gate logins, merge-queue/repo mechanics, prod access, memory location/schema, cadence numbers, maintainer channels

Proposal (incremental, ADR-first — mirror ADR-0001's precedent)

1. Child 1 — design ADR: define the plugin boundary (generic role vs deployment config), the parameterization contract (the consuming repo's AGENTS.md supplies portfolio map + trust gate + cadence; the plugin's skills reference those sections by convention), and the self-improvement loop implication: today the agent improves its constitution via same-repo draft PRs; with a plugin, generic-core improvements become agent-plugins PRs + a consumer version bump — acceptable (still devantler-tech-autonomous) but must be an explicit, documented trade.
2. Child 2 — extract: plugins/automated-ai-engineer/ bundling generalized portfolio-maintenance / product-engineering / self-improvement skills + the engineer/surveyor agent definitions (this realizes Roadmap: agent-plugins marketplace — reach & feature-completeness #38 T1 "agents+skills bundle" at real scale).
3. Child 3 — consume: the monorepo installs the plugin and its AGENTS.md shrinks to the deployment config + pointers; per-product cards stay local.

Trade-offs weighed

• ➕ Portability principle (industry-standard, tool-neutral; Copilot CLI reads the same plugin schema) and reuse beyond this org; flagship proof that plugins are feature-complete bundles ([[feedback_plugins_feature_complete]] direction).
• ➖ Iteration friction where change is hottest: the constitution changes weekly; a plugin boundary adds release+bump indirection. Mitigated by splitting on volatility — the role is slow-moving, the portfolio config (fast-moving) stays local.
• ➖ Risk: a bad split leaves half-generic text in both places that drifts. The ADR must name every section's home explicitly.

Size

L (epic) — ship as the 3 children above; child 1 is S and startable independently.

Relates: #38 (T1/T2), monorepo AGENTS.md Design principles (native-to-Claude, portable-by-default).