datasqrl/datasqrl-plugin/implement

Run the DataSQRL Code Agent in implementation mode (implement → compile → test → verify → refine) on the current project.

Working directory: run datasqrl-agent.sh in the project directory — the one containing the adr subfolder and the project implementation files. The command mounts the entire repository for the agent to read, and the invocation directory is the only one it writes to. adr/plan_*.md is discovered relative to that directory.

Step 1 — start the run

The launch command starts a detached container and returns in about two seconds, printing the run name. Launch once, in the foreground, with the default timeout. The container is owned by the Docker daemon and keeps running after this session is interrupted or closed.

CODEAGENT="${CLAUDE_PLUGIN_ROOT}/scripts/datasqrl-agent.sh"
[ -f "$CODEAGENT" ] || CODEAGENT=datasqrl-agent.sh   # fall back to PATH
 
bash "$CODEAGENT" "$ARGUMENTS" --mode implementation --detach [run choices]

• Run the first two lines exactly as written. They locate the launcher (datasqrl-agent.sh).
• Run choices: run with the choices settled during setup, as `agent-setup.md` describes. With none settled, add nothing: the run uses the defaults.
• With no argument the launcher auto-discovers the latest adr/plan_*.md. Pass a path to target a specific plan.
• The printed run name confirms the container started.
• A non-zero exit means the run never started — failed preflight (Docker down, image missing, no credential), or a run already in progress for this project. Report that message verbatim and end the turn.

Step 2 — start the background wait

Start this command in the background, with the longest timeout you can set:

bash "$CODEAGENT" --wait

It waits until the run ends and then prints one line with the result. Because it runs in the background, you get a notice when it ends, and the user does not have to ask you. If you cannot run a command in the background, skip this step; the user will ask you how the run went.

Step 3 — inform the user, then end your turn

Write this message after the background command has started, as the last message of the turn, so the user sees it in full (text written before a command call can be hidden by the user's interface). The message contains, in full:

• the run name the launch printed;
• the block of commands the launch printed under the run name, copied word for word — each line is an action the user can take from a terminal;
• that the user can ask you at any time how the run is going or what a progress line means (the `progress` skill answers that), and can ask you to stop the run;
• that the container keeps working while this session sits idle;
• that you will report when the run ends (only when the background wait is running).

Then end your turn.

Step 4 — when the background --wait stops because of the timeout

The run is still going. Start the same --wait command again in the background and end your turn.

Step 5 — when the run finishes

Do this when the background --wait ends with the line No run in progress. Last result: …, or when the user asks you how the run went (the `progress` skill tells you whether it has finished) and it shows that the run finished.

Read the newest run, the first entry of runs in .datasqrl_agent_results.json, and report success, mode, refinements, issue_score, code_check_status, llm_judge_status and the counts for each severity in issue_count. If the file is absent, say so. success means the final iteration passed its tests. The judges' issues, each one listed in issues, are review notes only. code_check_status says whether the code-based checks ran, and llm_judge_status says whether the LLM judges ran. The values are complete (none failed), partial (some failed), failed (all failed) and null (none ran). A check that finds issues has not failed. issue_score holds the score of the issues found, also when the LLM judges failed. Tell the user when either value is partial or failed. A run from an older image has neither field. That report is the complete deliverable, for every outcome. Stop after the report. The containerized agent has already run its own compile → test → judge → refine loop, so the result it returns is final and every change it made is already applied.