Compile for coding agents: A-ISL (experimental)

A developer released A-ISL, an experimental open-source workflow that has a coding agent author a reviewable Spec in the classic ISL format (.isl.md) from a natural-language product description, which a human must accept before a separate skill compiles it into a target stack such as React, Blazor, WinForms or a C# library. The Spec never auto-chains into build output, preserving a human gate, and the same Spec can compile to multiple stacks without rewriting intent. In an internal closed-rules benchmark (tariffe-v2, N=5), Spec-to-compile matched a single prompt at 5/5 on React JS and 5/5 on C#, while an open DTO-style prompt dropped to 1/5 on first pass until a 'prefer records' rule was added; the developer frames this as a non-regression check, not a leaderboard, and says the expected payoff on large or multi-module projects is not yet demonstrated.

I got tired of two extremes: one-shot prompts that disappear into the chat, and hand-written specs nobody maintains. A-ISL is an experiment in the middle: you describe the product in natural language; a coding agent writes a reviewable Spec in classic ISL https://github.com/fra00/isl-specification .isl.md ; you accept it; then you explicitly ask another skill to compile that Spec into bin-<stack / React, Blazor, WinForms, C library, … . You do not hand-author ISL or the app. a-isl-spec-author .isl.md only a-isl-compile bin-<stack / via a small runtime builder → queue → packet → lock Spec never auto-chains into bin/ . That’s the whole point: human gate , not autopilot. Same Spec can compile to more than one stack without rewriting intent — see the sheet demo https://github.com/fra00/a-isl-agents/tree/main/examples/sheet-workspace React / Blazor / WinForms . A-ISL does not invent the product. You decide behavior and accept the Spec. Wrong Spec that compiles is still “faithful.” That boundary is intentional. Internal bench tariffe-v2 , closed Domain/Logic rules, N=5 : | Campaign | Stack | First full-pass | Final | |---|---|---|---| | A-ISL | react-js | 5/5 | 5/5 | | Single prompt | react-js | 5/5 | 5/5 | | A-ISL | csharp | 5/5 | 5/5 | | Prompt open DTO style | csharp | 1/5 | 5/5 | | Prompt + same “prefer records” rule | csharp | 5/5 | 5/5 | Regression check, not a leaderboard. On a small closed-rules task, Spec → Compile matches a single prompt 5/5 vs 5/5 on JS . On C , a prompt that left DTO style open dropped to 1/5 on first pass; adding the same “prefer records” rule closed the gap. The expected payoff is on large or multi-module projects and on change-via-Spec . This bench does not demonstrate that; it only supports non-regression on a small closed oracle. Full honesty: evaluation.md https://github.com/fra00/a-isl-agents/blob/main/docs/evaluation.md . Runtime is agent-agnostic. Skills ship for Cursor, Claude Code, and GitHub Copilot same text, synced . Day-to-day use and the bench were on Cursor ; other hosts are not separately tested yet. Modules, evolution via Spec, multi-stack. For a one-shot script, a normal prompt is enough — Spec→Compile costs more turns on purpose. Prerequisites: Node.js 18+; for Blazor / WinForms sheet demos, a .NET SDK WinForms needs Windows targeting . git clone https://github.com/fra00/a-isl-agents.git cd a-isl-agents && npm install && npm --prefix runtime/lint install open in your agent → /a-isl-spec-author → review → /a-isl-compile Tutorial: docs/tutorial-first-project.md https://github.com/fra00/a-isl-agents/blob/main/docs/tutorial-first-project.md