Lanqiao-Luca/ai-java-workflow

What this project is

ai-java-workflow organizes AI-assisted Java/Spring Boot development into a layered method: standards and tools feed skills, which agents use inside workflows, loops and graphs. The entry point is Brain, which routes a task to a graph, loop, workflow or individual agent depending on scope and dependency structure. The repository provides 20 role definitions with inputs, outputs and verification expectations, plus fictional runnable cases that demonstrate the full chain from requirements to delivery. It is meant for developers who want a repeatable division of labor around AI coding assistants, not for teams looking for a Spring AI framework implementation.

Getting started

The prerequisite is Git and Python 3.9+. Clone the repository and run the offline repository checks:

git clone https://github.com/Lanqiao-Luca/ai-java-workflow.git
cd ai-java-workflow
python3 -B scripts/check_all.py

This runs eight offline checks over the public file manifest, document references and case records, plus loop-control tests. It does not call a model or build a Java project. Then open the repository in a programming assistant that can read local files and ask it to review the bookmark-tag example as a single closed loop. For your own task, start from the Brain routing document and let it select the appropriate workflow or agent. A CLI entry point also provides doctor, choose, run, status and resume commands for the five whitelisted cases; run directories stay outside the repository.

Constraints and boundaries

Brain is currently a documented routing layer consumed by the assistant or user, not an automatic scheduler: the existing CLI does not read its routing or authenticate callers. Native agent orchestration has been validated on macOS with Codex CLI and Maven, and requires model login and network access. The strict foreground macOS sandbox is experimental, rejects fork and cannot run Maven or Gradle; the trusted-build sandbox allows child build processes and a wider loopback boundary, so it is limited to trusted projects. Docker sandbox support is verified only on the listed macOS and Linux VM controller setups. Examples use fictional data and do not connect to company services or production databases. Production deployment, real authentication, load behavior and arbitrary project compatibility need separate validation. The rewritten documentation, scripts and fictional examples are MIT-licensed; the license does not extend to users' company code or third-party materials.

HotRepo's take

The repository appeared in HotRepo's new-project Python list on 2026-11-05, with 22 stars added over roughly 11 hours and 6 forks. That is a small, early sample rather than evidence of sustained traction. The project's own documentation is unusually explicit about what has and has not been verified: it distinguishes actually executed Spring/MockMvc cases from NOT_RUN plans, and its 8-task structural benchmark compares 8 correct checks under the full contract with 3 correct under a simplified field baseline. Those numbers describe structural checks only, not real model quality or engineering gain. Readers should treat this as a method-and-case repository in an early stage, with automation still limited to specific validated backends.

Project source and documentation