Espalier Engineering

An espalier trains a fruit tree to grow flat along a wall — pruned, wired, productive, and impossible to mistake for a wild one. Espalier does the same thing for your AI coding agents: it discovers the patterns already in your codebase, then encodes them as constraints so generated code grows along your conventions on the first try, not the fifth.

/plugin marketplace add Junhanliu-dev/espalier-engineering
/plugin install espalier-engineering@espalier-engineering
/espalier-init

v0.18.0 — the map lane: planning above one session, and a road into greenfield. Espalier gains a third altitude. /espalier <feature> plans one session's work; /espalier-map <idea> now plans the work above that — an epic, a product on a boilerplate, a greenfield build — as a decision map under espalier/maps/: a named destination, decision tickets (grilling / research / prototype / task), a fog-of-war section for what can't be phrased yet, and a frontier you work one ticket per session. Adapted from Matt Pocock's wayfinder (MIT) with Espalier-grade enforcement bolted on: a map-guard hook machine-blocks writes outside the map while a session is active (the "agent started building mid-plan" failure structurally removed), a max-open-tickets cap stops waterfall over-charting, and every decision runs the grill's rules/wiki cross-check before it locks. A cleared map hands back FILED change skeletons the normal pipeline adopts one at a time — decision → ticket → change → commit stays one audit chain. And /espalier-init learns greenfield: a near-empty repo takes the two-pass Decide, Then Bind path (skeleton install → chart the conventions as decisions → init binds them as rules citing decided_in: tickets); boilerplate repos run init first, then map the product against the discovered conventions. Lane quality is measured, not asserted: a shipped read-only stats hook (bash espalier/hooks/espalier-stats.sh) reports review-round/rollback distributions, the grill-verdict mix, per-map ticket/fog state, and the charted-vs-uncharted cohort comparison (including the fix echo via caused_by links), while a new eval/map/ harness (grill-harness pattern: planted decisions, simulated users, LLM judge, 0.80 catch-rate gate) validates the lane itself before release. Validation grows to 50/55/60; migration #25. Suites: bootstrap 197/197, hooks 146/146. Design: docs/map-lane-plan.md; migration: docs/migrating-v0.17-to-v0.18.md.

v0.17.0 — the gardener takes over (multi-dev maintenance, Release B-team). Maintenance becomes a scheduled singleton: one rotating gardener runs doctor + prune once per interval in a single weekly maintenance PR, and everyone else's pre-flight defaults to "Proceed". Two small shared files carry the facts that matter through git: the tracked one-line espalier/.doctor-stamp (only a clean stamp satisfies the team; a dirty:N stamp satisfies just its writer; skewed stamps rejected; the doctor restamps clean when the session's prune cleared everything) and conventions file-per-key under espalier/conventions/ (the towncrier trick: different keys can't conflict at all; a same-key double decision surfaces as an ordinary 5-line git conflict — the conflict is the race detection; append collisions resolve by keeping both lines, deduped at read time). No event logs, no fold algorithms, no format markers. Migration #24 is pure-copy only. Suites: bootstrap 177/177, hooks 127/127 with two-clone git sims. Plain-language tour: docs/multi-dev-maintenance-how-it-works.md; migration: docs/migrating-v0.16-to-v0.17.md.

v0.16.0 — maintenance goes team-shaped (Release A: the compatibility floor). With several developers on one repo, the single-dev maintenance loop breaks four ways: every clone sees a different staleness picture, nobody owns the shared upkeep, the bookkeeping files merge with conflicts, and rule changes diverge silently across branches. v0.16.0 ships the floor that fixes the last two and prepares the first two: an executable conventions reader (conv_fold — folds the legacy .conventions.tsv and the upcoming per-key espalier/conventions/ files, width-tolerant, deduped, with clock-free status precedence), per-mechanism maintenance lanes (doctor and routine prunes ride one weekly maintenance PR; promotions ride the deciding feature branch as their own isolated commit behind a CODEOWNERS merge gate), a corrected promotion race guard, canonical-ref config keys, the one .gitattributes union entry (.ask-gaps.tsv), optional CODEOWNERS generation, worktree-correct hook install, an enforced migrate barrier, and conflict/slug-collision recipes. Validation grows to 48/53/58 checks (57-58). Suites: bootstrap 161/161, hooks 99/99. Design: docs/multi-dev-maintenance-implementation-plan.md; plain-language tour: docs/multi-dev-maintenance-how-it-works.md.

Existing users: run /espalier-migrate — the v0.16 step refreshes the pipeline files, appends the Maintenance Commits policy, and re-wires (optionally asking for CODEOWNERS handles). See docs/migrating-v0.15-to-v0.16.md.

v0.15.0 — Espalier learns Copilot; the wiring layer goes three-platform. /espalier-init now targets any subset of Claude Code, Codex, and GitHub Copilot. For Copilot the same espalier/ tree wires through Copilot-native surfaces: the 12 skills as Agent Skills in .github/skills/ (read by VS Code, Copilot CLI, and the cloud coding agent; invoked /espalier…), the always-loaded rules via a generated .github/copilot-instructions.md section, coder/reviewer/security separation as @harness-* custom agents (.github/agents/*.agent.md), and the two quality gates as Copilot hooks (.github/hooks/espalier-gates.json) — a small adapter translates Copilot's camelCase hook payload into the Claude/Codex shape, so the same two wrapper scripts now gate all three platforms (Copilot fails non-zero preToolUse exits closed, matching the exit-2 contract). Wiring stays additive (espalier/.platforms unions; nothing ever unwires) and claude-only output stays byte-stable. Suites: bootstrap 117/117, hooks 86/86; validation is 46/51/56 checks by platform set. Setup guide: docs/copilot-integration.md.

Existing users: run /espalier-migrate — the v0.15 step installs the one new adapter file and asks whether to wire Copilot. See docs/migrating-v0.14-to-v0.15.md.

v0.14.0 — Espalier learns Codex. The same discovered guardrails now wire into OpenAI Codex as first-class output: /espalier-init asks which platform(s) to target (Claude Code, Codex, or both) and, for Codex, wires the very same espalier/ content through Codex-native surfaces — the 12 skills as repo skills in .agents/skills/ (invoked $espalier, $espalier-fix, …), the always-loaded rules via a generated AGENTS.md section, the coder/reviewer/security separation as .codex/agents/harness-*.toml subagents, and the two quality gates as PreToolUse/PostToolUse hooks in .codex/config.toml (Codex shares Claude Code's hook JSON schema and exit-2-blocks contract, so the same wrapper scripts serve both — now hardened to parse apply_patch patch bodies and argv-array commands). You can even run $espalier-init from inside Codex itself: the skill carries a platform-fallback table (chat questions instead of AskUserQuestion, inline discovery instead of scout spawns). Wiring is additive and re-runnable — a claude-only install adds codex later with one --wire-only --platforms=codex run (or /espalier-migrate), never unwiring anything. Suites extended and green: bootstrap 97/97, hooks 73/73, validation grows to 51 checks on codex installs while claude-only output stays byte-stable at 46. Setup guide: docs/codex-integration.md.

Existing users: run /espalier-migrate. It applies the chain (… v0.12.0→v0.13.0→v0.13.1→v0.13.2→v0.14.0) in order; the v0.14 step refreshes the two hook wrappers (backups at <file>.pre-v0.14.bak) and asks whether to wire Codex — declining changes nothing else. See docs/migrating-v0.13-to-v0.14.md.

v0.13.0 — the coder gets a laziness ladder; the reviewer gets a minimalism lens. Espalier enforced fit — conventions, layers, production seeds — but had no notion of size: a convention-perfect 200-line date-picker component passed every gate while <input type="date"> was never considered. Now the coder climbs a Solution Selection Ladder before choosing a change's shape (reuse what the project has → the convention-named mechanism → stdlib/native/installed dep → the leanest compliant implementation; a NEW dependency needs a requirements.md line), and the reviewer runs an advisory Minimalism Review — delete:/stdlib:/native:/yagni: findings capped at P2/P3 so they can never re-open the Stage 4 fixpoint loop, with ONE objectively-checkable P1: a new dependency covering what stdlib or an installed dep already provides. The governing rule everywhere: conventions first, correctness within them, brevity only breaks ties — a construct your rules mandate is never "over-build", and "the convention itself is bloat" routes to the human promotion path, never a blocking finding. Idea adapted from ponytail (MIT), re-grounded convention-first. Gated on both eval suites (coder 4/4 incl. a new overbuild-trap fixture; review 8/8, catch-rate 1.00, FP 0 — incl. a planted new-dependency P1 and a severity-inflation guard) and quality-scored by independent agents on the darwin 8-dimension rubric: avg 82.3 → 85.9 after the scorer-finding fix round (reviewer 91.0, coder 88.6). Full report: docs/quality-report-v0.13.0.md.

Existing users: run /espalier-migrate. It auto-detects your install version and applies the needed migration chain (… v0.10.0→v0.11.0→v0.12.0→v0.13.0) in order. The v0.12→v0.13 step is surgical (anchored section inserts into the four per-project coder/reviewer files — never a template overwrite, backups at <file>.pre-v0.13.bak). See docs/migrating-v0.12-to-v0.13.md.

---

The Problem

AI coders write plausible-looking code that doesn't fit your codebase. They invent helpers when you already have one. They split files the team would keep together. They pick a logging library the project doesn't use. They handle errors with throw when your repo standardised on Result<T> three years ago.

It's not a model intelligence problem. It's an unwritten rules problem — patterns every experienced developer on the team knows but nobody documented. The model can't read your team's Slack history.

The Solution

Espalier reads your code, extracts those rules, and writes them down as machine-enforceable constraints. The next time the AI codes, it loads your project's rules automatically and follows them. Reviewer agent (different agent, different tool set) checks against the same rules before any commit lands.

Result: rework cycles drop from 3-5 rounds to typically 1.

What It Generates

After running /espalier-init on any repo, you get a per-project espalier/ directory wired into your agent platform(s) — Claude Code, Codex, or both:

espalier/
├── rules/                  # always-loaded: engineering structure, coding standards, dev process, security standards, production standards
├── skills/                 # phase-loaded: coding, revie