---
title: "Automated Prompt Builds"
id: "589"
type: "page"
slug: "prompt-builds"
published_at: "2026-06-03T14:29:23+00:00"
modified_at: "2026-06-11T14:02:26+00:00"
url: "https://xedant.com/code/docs/validation/prompt-builds"
markdown_url: "https://xedant.com/code/docs/validation/prompt-builds.md"
excerpt: "Prompt-based builds are the most advanced validation mechanism in Xedant Code. Unlike command-based builds that…"
---

# Automated Prompt Builds

[https://xedant.com/code/docs/validation/prompt-builds.md](https://xedant.com/code/docs/validation/prompt-builds.md)

Prompt-based builds are the most advanced validation mechanism in Xedant Code. Unlike [command-based builds](/code/docs/validation/automated-build)
 that run fixed shell commands, prompt builds create a separate AI agent to validate your codebase. The agent’s reasoning happens in an isolated sub-chat, keeping the main conversation clean. The sub-agent’s output is then parsed for errors and warnings using the same parser infrastructure — and those errors can feed into [AutoFix](/code/docs/autofix)
 just like any other build.

![Auto-validation of project file updates](https://xedant.com/wp-content/uploads/2026/06/automated-build-validation.png)## How Prompt Builds Work

A prompt build uses the `prompt` field instead of `command` in `build.yml`. When triggered, it creates a new chat session, sends the prompt as the first message, and monitors the AI’s response:

```
build:
  ai-review:
    watch: chat                                    # Trigger when user chat completes
    prompt: "/verify Review the recent code changes. Read the chat transcript at {chat} and report any problems."
    chatTitle: "Code Review"
    delay: 5
    timeout: 120
    display: always
    autofix: always
```

The `watch: chat` trigger fires when the user’s chat session completes, user message queue is empty and AutoFix queue is done with no errors or warnings. Even if prompt build uses autofix, it would be executed only after command builds are auto-fixed, to ensure clean state for AI review. The `{chat}` placeholder resolves to the transcript path of the triggering user chat, giving the sub-agent access to the full conversation context. The `{buildName}` placeholder is also available in the `chatTitle` field for dynamic titles.

## Sub-Chat Architecture

Prompt builds create a separate chat instance with its own context window:

- **Isolated context** — The sub-agent’s reasoning and tool calls happen in their own chat session. They don’t consume tokens from or pollute the context of the main conversation
- **Parent chat tracking** — Each sub-chat records a `ParentChatId` linking it to the originating user chat. This creates a traceable chain visible in the [analytics dashboard](/code/docs/validation/analytics-observability)
- **Title generation** — The `chatTitle` field sets the sub-chat’s title. If omitted, it defaults to the build name. The `{buildName}` placeholder resolves to the actual build configuration key
- **Output extraction** — When the sub-agent finishes processing, the system extracts the last assistant message as the build output. If an `outputFile` is configured, the system reads from that file instead — you could instruct your agent to write its final results into a file to make it more robust and debuggable

The sub-agent runs within the configured `timeout` (in seconds). If it exceeds the timeout, the build is cancelled. The processing state is monitored via the Claude Code instance manager — when `isProcessing` becomes false for the build chat, the output is extracted and parsed.

## Output Parsing and AutoFix Integration

The sub-agent’s output is parsed using the same `.xedant/build.parser` infrastructure as command builds. This means any patterns defined for your build tools also work for prompt-based validation. If the sub-agent’s response contains text matching `[ERROR]` or `[WARNING]` patterns, it’s extracted as structured errors.

Prompt builds participate in [AutoFix](/code/docs/autofix)
 just like command builds:

- Set `autofix: always` to have AutoFix feed the sub-agent’s errors back to the main chat for fixing
- Set `autofix: errors` to only trigger AutoFix when the sub-agent reports errors (not warnings)
- Set `autofix: never` if the prompt build is informational only — you want to see the sub-agent’s analysis in the build panel but don’t want it to trigger fixes

Build output is stored in `.xedant/build/` using the same three-file format: `{build-name}.output.txt`, `{build-name}.errors.txt`, and `{build-name}.warnings.txt`.

## Configuring Prompt Builds

Prompt builds support the same configuration fields as command builds, with `prompt` replacing `command`:

```
build:
  security-audit:
    watch: chat
    prompt: "/verify Run a security audit on the codebase. Check for hardcoded secrets, SQL injection vulnerabilities, and insecure dependencies. Read the transcript at {chat} for context about recent changes."
    chatTitle: "Security Audit"
    delay: 10
    timeout: 300
    display: errors
    autofix: errors

  test-generation:
    watch: chat
    prompt: "/verify Write tests for the code changes described in the chat transcript at {chat}. Run the tests and report any failures."
    chatTitle: "Test Generation"
    delay: 5
    timeout: 180
    display: always
    autofix: always
```

### Writing Effective Validation Prompts

- **Load a skill** — Prefix the prompt with `start with loading skill-name skill` (more effective than `/skill-name` syntax) to load project-specific context into the sub-agent. A code review skill loads coding standards that the sub-agent can validate against
- **Reference the transcript** — Use `{chat}` to give the sub-agent access to the full conversation. Without it, the sub-agent only knows what you explicitly describe in the prompt
- **Be specific about what to check** — “Review for problems” is vague. “Check for null reference exceptions, missing error handling, and incorrect async patterns” gives the sub-agent concrete criteria
- **Specify the output format** — If you want the output to be parseable, instruct the sub-agent to format errors in a way that matches your build parser patterns. The best place to explain that is the skill, as it makes your subagent versionable and reusable

### Trigger Combinations

Like command builds, each prompt build watches exactly one type of event — file wildcards, parent build names, or `chat`. The `chat` trigger is available for all build types, not just prompt builds. If you need a single prompt build to activate on multiple events, use the parent-child scheme described in the [Automated Build Validation](/code/docs/validation/automated-build)
 guide — create multiple lightweight parent builds that each watch one event type, then have the prompt build watch all of them. Set `display: never` on the parent builds to keep them hidden from the build panel.

## Effective Validation Patterns

- **Code review after every session** — A prompt build with `watch: chat` automatically reviews the AI’s work after each conversation. The sub-agent catches issues that compilers and linters miss — architectural problems, logic errors, and violations of project conventions
- **Security auditing** — A dedicated security prompt build checks for secrets in code, SQL injection patterns, insecure dependencies, and other vulnerabilities that automated tools may not catch
- **Test generation and validation** — A prompt build that writes and runs tests provides a validation signal that no static analysis tool can match. If the sub-agent generates tests and they fail, AutoFix feeds the failures back to fix the code
- **Chain with command builds** — A prompt build watching a command build creates a two-stage pipeline: the command build catches static errors, and the prompt build catches semantic errors. Configure the command build first in the dependency order
- **Keep sub-agent context focused** — Load only the relevant skill and reference the transcript. Don’t load skills that add unrelated context — it dilutes the sub-agent’s attention and produces less useful validation output
- **Manual prompt builds** — Remove the `watch` trigger and set `autofix: never` to disable automatic triggering and AutoFix integration. The build stays visible in the build panel where you can trigger it manually as a one-click validator — ideal for truly heavy tasks like project-scale security audits that you run on-demand after large-scale project updates instead of on every chat completion

For the complete build system reference, see [Build & Deploy](/code/docs/build-deploy)
. For automated error feedback, see [AutoFix](/code/docs/autofix)
. For managing sub-agent context, see [Analytics & Observability](/code/docs/validation/analytics-observability)
.

**[← Automated Build Validation](/code/docs/validation/automated-build)**

**[Sound Feedback Validation →](/code/docs/validation/sound-feedback)**