This Claude skill provides a self-contained build and test automation system for Microsoft Dynamics 365 Business Central (AL) development. It streamlines the development workflow by integrating compilation, app publishing, and test execution into a single command, serving as a critical quality gate to ensure code stability before repository commits.

When should I use al-build?

al-build is useful in the following scenarios: • Pre-commit Validation: Automatically run the full build gate after modifying AL code to verify that changes pass compilation and all existing tests. • Rapid Iterative Testing: Use specific parameters to run individual test codeunits, allowing developers to quickly validate specific business logic without executing the entire test suite. • Project Environment Provisioning: Simplify the initial setup of AL projects by automating configuration file generation and symbol downloading through standardized initialization commands. • Automated CI/CD Reporting: Execute builds within sub-agents to generate concise summaries of pass/fail counts and error traces, keeping the main development conversation focused on high-level tasks.

name	al-build
description	Build and test AL/Business Central projects. Use after modifying AL code or tests to verify the build gate passes. Runs compilation, publishing, and test execution in a single command. Required gate before committing AL changes.

AL Build

Self-contained build system for AL/Business Central development. No external task runners required.

Project Setup (First Time)

Required Steps:

Initialize config: Run /al-build:init to create al-build.json
Customize config (especially testAppName to match your test app)
Run provision (one-time): Run /al-build:provision

Config Priority (highest to lowest):

Script parameters (e.g., -AppDir "custom")
Environment variables (e.g., ALBT_APP_DIR)
Project config (al-build.json in repo root)

Canonical Gate

After modifying AL code or tests, run:

pwsh "<skill-folder>/scripts/test.ps1"

Prerequisites:

Project config exists and customized (al-build.json)
Provision completed (run provision.ps1 once)
Docker container healthy

Requirements:

Zero warnings, zero errors
Faster iteration: pwsh "<skill-folder>/scripts/test.ps1" -TestCodeunit <id>
Force republish: pwsh "<skill-folder>/scripts/test.ps1" -Force

Outputs:

.output/TestResults/last.xml — JUnit test results
.output/TestResults/telemetry.jsonl — merged telemetry

Running Tests in Subtask (Recommended)

Use the Task tool with subagent_type: general-purpose to run tests. This keeps verbose build output contained and returns only essential results to the main conversation.

Task tool invocation:

subagent_type: general-purpose
prompt: |
  IMPORTANT: This is a READ-ONLY task. Do NOT edit any files.

  Run the AL build gate:
  pwsh "<skill-folder>/scripts/test.ps1"

  Report back:
  1. Build result: success or failure
  2. Test result: pass count, fail count
  3. If failures: include the relevant error messages and stack traces
  4. If warnings: list them
  5. If failures and telemetry is relevant: include key entries from .output/TestResults/telemetry.jsonl

  Do not include full console output - only the summary above.

Why subtask?

Build/test output is verbose (compilation logs, test runner output)
Main task only needs results and actionable error context
Keeps conversation focused on the development task

Troubleshooting

Build fails and no config exists

If /al-build:test fails and al-build.json doesn't exist in repo root:

Run /al-build:init to create config
Customize settings as needed
Run /al-build:provision once
Re-run /al-build:test

Config Issues

Config not loading: Ensure al-build.json is in git repo root (same level as .git/)
Provision not found: Run /al-build:provision (one-time)
Wrong test app: Update testAppName in al-build.json to match your test app

Build Failures

Check compiler output for error messages
Ensure symbols are provisioned (user runs: pwsh provision.ps1)
Verify container is healthy: docker ps

Test Failures

Check .output/TestResults/last.xml for assertion failures
Use telemetry for debugging: see telemetry-first-test-debugging skill
Run specific codeunit: pwsh "<skill-folder>/scripts/test.ps1" -TestCodeunit <id>

Container Issues

Check container health: docker inspect <name> --format '{{.State.Health.Status}}'
View container logs: docker logs <name>

al-build

When & Why to Use This Skill

Use Cases