AI Flow

AI Flow is a dynamic skill

A dynamic skill is a small Rust binary that holds the AI's hand through a long job. It says which step comes next, hands over ready-made code for the routine parts, checks the AI's work with deterministic linters, and answers every command with hints. AI Flow and every adom-aiflow-<stage> app (ordering, probing, video, ...) are dynamic skills, and they all follow the same rules:

• The AI does about 97 % of the work. The binary is about 3 %. The binary is the guide and the checker. The thinking, the design decisions and the actual work belong to the AI.
• A guide, never a gate. No step is a hard gate. A dynamic skill suggests what to do next; it does not decide whether the AI may continue.
• Linters give feedback, gently. A check reports what it found and suggests a next action. It is a suggestion, not a verdict: the AI and the human decide what to do with it.
• It never tries to do the AI's job. AI keeps getting better. A binary that does the AI's thinking for it, or walls it in with rules, is out of date the day a better model ships. Ideas and feedback stay useful; hard rules do not.
• The only error is "I could not run" (a missing file, a tool that is not installed), and even that answer says what to try next.

If you build or change a flow app, hold it to this. A new requirement, a mandatory field or a step that refuses is a sign the binary has started doing the AI's work.

Open source under the MIT License. The complete AI Flow source is available in this wiki repository: Rust workspace, CLI source, and package metadata. Third-party dependencies and assets retain their own licenses and notices.

adom-wiki repo clone adom/adom-aiflow --dir adom-aiflow
cd adom-aiflow
cargo build --release

Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board. The AI thinks its way from parts placement through routing, copper pours, current and thermal analysis to a delivered video. The binary does the fast, deterministic parts of every step, hands back hints written for an AI, and keeps a ledger of every turn, every return to an earlier step, and the AI's time from your prompt to "done" (sessions, one per prompt, the idle cut out; docs/time.md). One flow, one clock, one file, so Claude, Codex and any other engine are compared on the same thing.

adom-wiki pkg install adom/adom-aiflow
adom-aiflow --version

Screenshots and video clips on this page marked after the first run are placeholders until the first measured run under Fable 5.1 lands. The comparison numbers are examples of what the ledger produces, not results.

Boards in Autodesk Fusion too

The same flow runs a board that lives in Autodesk Fusion: the binary plans, routes and gates offline, and every placement, trace, pour and refinement lands live in Fusion through the Fusion bridge, read back from Fusion's own export each time. See the Fusion lane.

Silkscreen that helps at the bench

Available in v0.1.26 on the insiders channel. Install with adom-wiki pkg install adom/adom-aiflow. The KiCad workflow is demonstrated below; Fusion and Altium adapters still require validation.

AI Flow now includes a two-sided silkscreen step: grouped references and smaller values, test-point and connector functions, machine-contact frames and curved pointers, prominent board-specific interfaces, and useful board documentation. The optional dashboard shows placements and their font sizes; a fixed full-board replay lets you watch labels appear on each face before verifying the result in native KiCad 3D.

Read the silkscreen flow and watch the 58-second ESC demonstration. The guide covers the geometry inputs, ordered AI review passes, recording, native validation and remaining adapter limits. This is an AI-assisted workflow with deterministic layout/preflight helpers, not a guarantee that an arbitrary board is production-ready. KiCad was exercised on the ESC; Fusion/Altium adapters remain future work.

The final video

The evidence of a run is its video, two minutes at most: only the moments something moved, every step in order, the AI's own current density and temperature rise drawings fullscreen, the run and step clocks in the corner, the words cut to the picture. Every run's page carries its own; the pair is the piece people share.

Fable vs Astra on the ESC G431

Claude Fable 5.1 versus Codex (Astra) on the ESC G431: same board, same spec, same prompt, same flow, measured the same way. The comparison page links both runs in full.

Fable delivered in 53 min of AI time with 2 returns to earlier steps; Astra in 78 min with 14. The runs: Fable, Astra.

The comparison: what two runs look like side by side

Everything below comes from the two runs' ledgers and nothing else. These are example numbers; the first measured runs replace them.

The number: prompt to "done, here is your video"

Commercial users on API plans pay the API figure; a 20x subscription plan pays a twentieth. Both lines, always.

Per step: the AI's thinking versus the binary's time (minutes)

Thinking is the gap before each command, charged to the step the AI declared. Tool is the binary's own seconds. The sum over steps is the whole run.

The rework map: where each engine went back, and why

The board that came out

Both must reach 0 / 0 or the run is not a result. The rest is where the engineering judgement shows: copper kept for ablation, tab temperatures, how many refusals it took.

What it cost

Token and dollar figures are self-reported by each engine into run.json; everything else is stamped by the binary.

The ESC G431, the first board

The proving run (the binary on a placement made earlier, not a measured run of the AI) ended with the ESC routed to 100 percent, 31 pours landed, both analyses passed:

What the binary is made of

One Rust binary, a crate per module: aiflow-board (the KiCad board model), aiflow-grid, aiflow-router (0.1 mm grid A*, escapes, plane stubs, per-net vias, rip-up, Kelvin taps), aiflow-copper (plans to copper, KiCad's DRC offline), aiflow-place (courtyards, packing, moves), aiflow-pours (zones, keepouts, thermal and stitching vias from the spec), aiflow-analyze (IPC-2221, tab copper, rise budgets), aiflow-run (the ledger and the manifest), aiflow-bridge (the live half through the Adom KiCad Bridge: landing, recording, measurement, validation), and adom-aiflow, the command.

KiCad Bridge today. Next backends: the Altium bridge, the Fusion bridge, then Adom's own web apps (adom-schematic, adom-2dboard, adom-3dboard). The board model and the bridge crate are the only ones that know KiCad; the flow, the spec, the ledger and the analyses do not change when the backend does.

Optional: try AI Flow: Routing beside the flow

adom/adom-aiflow-routing is a separate whole-board router to try next to this flow. It is not a step of AI Flow, nothing here depends on it, and route stays the flow's router. It is offered for comparison on real boards.

It is a dynamic skill by the same rules as this page: it suggests the next step, reports what it found with OK: and Hint: lines, and never blocks. It searches exact 0/45/90 degree paths instead of a grid, routes in the designer's order (pairs, data, power, the rest), and says why each connection it could not make failed.

adom-wiki pkg install adom/adom-aiflow-routing
adom-aiflow-routing route placed.kicad_pcb -o routed.kicad_pcb   # a new file; the input is never changed
adom-aiflow-routing check routed.kicad_pcb                      # then KiCad's DRC with zones refilled

What to know before trying it:

• Inside a measured run, wrap the command in adom-aiflow exec -- so its time is on the clock.
• It works on board files (a placed .kicad_pcb with its .kicad_pro), not through the KiCad Bridge.
• It does not write the plan JSON that gate --plan and land route --plan take, so its copper does not land through the flow yet. Route a copy of the placed board and put the result beside the flow's own.
• On 22 public wiki boards stripped and routed again, 19 come out clean in KiCad. It does not finish a two-layer power board with many small pours, and two dense boards keep 4 or 5 connections open. The pictures and data are on its page.

Findings from a trial are welcome as issues on that page.

Roadmap

Everything below is what John has asked for, in the order it is likely to land. 0.1 is what this page describes; nothing here is built until its version says so.

Steps in front of placement (the flow grows at the front)

• components: choose the parts from the requirements; a SPICE result or a thermal result can send the AI back here.
• libraries: build the symbols, footprints and 3D chips for every part (with adom-symbol, adom-footprint, chip-thumbnailer).
• schematic: draw it, and derive the spec from it, so the spec stops being hand-written.
• simulation: SPICE on the critical loops before the board exists (the KiCad Bridge's SPICE verbs, #89), with the loop back to components when a part choice is wrong.

Steps after the board (the flow grows at the back)

• moleculize: add the machine pins so the board can live in the probing workcell as a molecule.
• paste: solder paste jetting calculations and analysis.
• probe: work out how to probe the board when it comes off the 3rd party fab process.

Analyses (0.2)

• current 0.2: cross-sections through the filled copper instead of the narrowest-track heuristic; a current-density heat map per net.
• thermal 0.2: copper area weighted by distance from the tab, via conduction, the other layer's contribution; a heat map per hot part.
• impedance: controlled-impedance and return-path checks on the nets the spec marks.
• ablation: the copper-kept metric per layer as a mill-time estimate for the 3rd party fab process, so "least copper to ablate" is a number the AI can push.

The video (0.2)

• The step's own code frames the shot: zoom to fit before a landing, the part on screen when a move lands.
• Done in 0.1.14: compose cuts the final video from the motion of every step visit and the AI's drawings, two minutes at most, the picture leading and the adom-tts words cut to it. Left for 0.2: the AI writing its own words per segment, gang-takes for the charts.
• The split screen for two engines, and the grid for five (Fable, Astra, Antigravity, Grok, Kimi), cut from the same step tags.
• A clip for each step on this page, and the final video at the top of it.

Backends

• The Altium bridge and the Fusion bridge, behind the same commands.
• Adom's own web apps: adom-schematic, adom-2dboard, adom-3dboard, so users can stop relying on the legacy tools; the board model and the bridge crate are the only crates that change.

The binary and the bridge

• A batched landing verb in the KiCad Bridge (one DRC preflight for a whole plan) to bring a clean pass from 18 minutes to about 4.
• An ungated free-disk-space verb in ab (adom-bridge#196) so the recording budget can see the test box.
• Every step the AI replaces with its own better code comes back as a crate, filed on this page.

Measurement

• Token and dollar accounting written by the binary from the engine's own usage where an engine exposes it, instead of self-reported.
• The comparison page generated from the ledgers by the binary itself (adom-aiflow compare run1 run2 ...), so nobody assembles a chart by hand.

Skills in this package

• adom-aiflow: the flow, the commands, the spec, the honesty rules.
• aiflow-comparison-video: how to make the comparison video and page for two runs: pull the other run, compose --with and its narration script (the words lead, no dead air, who won each step, how the clock works), compare --push.
• aiflow-measurement: how a run is measured, in John's words: the clock from the prompt to "done, here is your video", the AI's thinking per step, the rework loops, the append-only run.jsonl, the cost both ways.

Honesty rules

• The clock starts at the prompt and stops at deliver. A late start takes --prompt-time.
• A stage the AI takes itself is stamped by the AI and named ai; the binary's are binary. Both go on the chart.
• A run without deliver is not a result, and its minutes are still counting.
• A run assembled from earlier work with a back-dated prompt is a proving run of the tool, not a measured run of the AI. Say so.
• 0.1's analyses are conservative heuristics (IPC-2221 for tracks; presence, connection style, area and vias for pours and tabs) and say so in their output. 0.2 computes cross-sections through the filled copper.

Trustworthy current and thermal screens

A pour's area or presence is not proof of current capacity or acceptable temperature. analyze current and analyze thermal now require both the heuristic checks and a matching Adom Fields solve. Run adom-fields analyze --board <current saved board> --spec <run spec> --out <run>/fields, then analyze current --fields <run>/fields/fields.json and analyze thermal --fields <run>/fields/fields.json. Fields records SHA-256 identities for the exact inputs. Changed boards or specs invalidate the result; unsolved loaded nets or hot parts are not a pass. finish rechecks the evidence. This is an engineering screen under the solver's documented assumptions, not junction-temperature certification.

Placement checks compare individual native DRC findings with the baseline, not just their counts. Conservative courtyard bounding boxes guide packing but do not override native courtyard checks. Project .kicad_pro and .kicad_dru constraints follow board snapshots. When present, they require a native kicad-cli (optionally set ADOM_AIFLOW_KICAD_CLI); the single-file headless service must not silently discard them. In a container without native KiCad, ADOM_AIFLOW_KICAD_CLI=adom-aiflow-kicad-cli-remote (installed with AI Flow) runs kicad-cli on a Windows or Linux desktop's KiCad through Adom Bridge (pcb drc, pcb export gerbers|drill|pos|step, sch export netlist, sch erc, version; KICAD_REMOTE_TARGET names the desktop, default this machine's own); a stock distro kicad-cli that lacks pcb drc --refill-zones is ignored. The gate refills zones natively when it has a native kicad-cli, so zone fills are KiCad's own, not the raster estimate, and the current and thermal analyses read the board's own copper when the routing plan leaves nets out (an adopted, already-routed board). Manufacturing-rule warnings, including hole spacing, remain blocking.

Latest maintenance: 0.1.28 lifecycle and native IPC readiness.

0.1.29: reliable component tours and explicit zone ownership.

Optional thermal assemblies and signal screening

Adom Fields 0.4.0 adds conducting heatsink blocks, copper thickness per layer and a Signals view for plane-overlap capacitance, differential-pair skew, reference coverage and microstrip estimates. AI Flow hints direct the AI to use explicit assembly and stackup data and keep unsupported cases visible. Fields inputs, sources, limits and fixture.

Native pour integration: owned-zone transactions and asynchronous refill/readback.

Browser access during sourcing

adom-aiflow browser-check --lane pup --input page-observation.json distinguishes access denial from missing or loading pages and recommends an owned native-browser session when appropriate. It checks saved page evidence and does not navigate or claim the product was verified. See the sourcing skill.

0.1.69: sourcing recovery, state-aware component assets and routing fidelity.

Automatic progress dashboard

AIFlow opens its Hydrogen timeline automatically when a run starts or resumes, for every AI engine. Existing tabs are reused; each project gets its own server identity. Closed tabs and stopped servers recover on the next command. UI failures are reported separately from design checks. Use timeline open to bring it forward explicitly, or AIFLOW_DASHBOARD=off for headless automation.