/al-initialize

description: Initialize AL development environment and workspace for Business Central. ALDC workflow (Copilot prompt al-initialize); invoke explicitly.
disable-model-invocation: true

> **Copilot CLI adapter — generated; do not edit this distribution.** > Select a role using /agent or copilot --agent <id>. Role names in this contract > are routing destinations, never chat mentions or evidence of an invocation. > Delegate only through the native task tool, using the exact discovered agent ID > as agent_type (for example al-planning-subagent). Inspect list_agents and the > actual task schema first. Keep all canonical human gates. Pass bounded context > inline; wait for completion (read_agent for a background task) before consuming > the result. A delegated role returns questions to its caller for the human gate. > If task or the requested custom agent is unavailable in this context, return > the blocked handoff to the caller/user. Never impersonate a missing subagent, > silently substitute general-purpose, or launch another CLI process to fake it. > Tool aliases in frontmatter select capabilities; call the actual tools exposed > by the host: view, glob, grep/rg, edit/create/apply_patch, bash/powershell, > web_fetch, task. Use a capability only when granted to this role and available. > Load domain skills through the host's skill mechanism when exposed, otherwise > read the complete bundled SKILL.md. A read is not a native skill invocation. > Resolve PLUGIN_ROOT to this installed agent's plugin directory (not the project > or original checkout). It is a path placeholder here, not a promised global > shell variable. Read docs/copilot-cli-al-tooling.md there for LSP/MCP bindings; > it supersedes older availability examples in the shared terminal contract at > skills/skill-migrate/references/cli-al-tools.md, never role duties or human gates. > Project instructions and matching .github/instructions rules remain binding; > pass the relevant excerpts to delegated roles. Canonical artifacts remain in > .github/plans/. Role write scopes are behavioral, not filesystem sandboxes. > AL execution requires a verified terminal command/runner or an actually exposed > MCP capability. Reuse the configured AL LSP for Agents wrapper through native > CLI semantic tools when exposed to this role. Inspect the catalog; do not invent > tool aliases or broaden read-only grants to enable rename/write operations. > Editor debugger controls remain separate from semantic navigation. Official AL > MCP selectors use al/<tool>; only Developer/Implementer receive compile/build/ > restore. Discover the actual callable names and pass the correct App/Test path. > No official publish/authentication tool is granted by this adapter. Triage alone > receives the optional dedicated bc-profiling and bc-snapshot proxies; discover > their schemas and confirm an authorized target/window before capture. Other > roles consume evidence. Capture does not prove autonomous snapshot debugging. > Symbol MCP: before any tools/call, verify AL CLI prerequisites are already > provisioned; this provider may auto-install AL tools on first use. A read-only > role must return that prerequisite to the caller, never bootstrap software. > Load symbols via al_packages(action: load, path: absolute consumer path). > The MCP process may run from the plugin cache; never assume its cwd is the > consumer. Use the discovered schema and report missing .app packages explicitly. > Record missing capabilities and unexecuted checks explicitly; never simulate.

AL Environment Initialization

Your goal is to initialize the AL development environment and workspace for `<ProjectName from $ARGUMENTS>`.

This workflow configures Copilot CLI and the approved AL project. Bootstrap alone adds no AL sources or manifest; project scaffolding below requires its own approved scope.

Execution scope — choose before any phase

When the request is to prepare/register an **existing** App or Test for AL MCP, use **MCP workspace preparation only** below and return its result. Do not run Phase 0 (plugin bootstrap), Phases 1–5, troubleshooting actions or the full-setup success checklist. This narrow mode does not install ALDC or change files. An explicit request to prepare the named existing project authorizes its bounded registration; reuse that authorization instead of requesting it again.

For full environment initialization, retain the existing phases and material approvals. Run MCP workspace preparation after the authorized project exists and before handing it to Architect/Spec/implementation. Do not treat an ordinary architecture request, plugin installation or a Doctor run as setup authorization. Doctor remains diagnostic; it never registers projects as a hidden side effect.

MCP workspace preparation only

This protocol concerns the **official AL MCP**, not AL LSP, the native editor symbol index, community symbol providers or a Business Central business-data MCP. Operation names below describe capabilities; inspect actual schemas and aliases in this host. Never transpose another host's wire prefix or native AL schema.

1. **Resolve the exact project.** Read the current project's `aldc.yaml` and `solution.roots`, then confirm the requested existing folder contains `app.json`. Resolve relative roots against that configuration file, not the first workspace folder. Record absolute path, app identity and target version. Prepare App by default when App is the requested scope. Prepare Test only when requested/needed within the authorized scope, separately by its own path. Never register the solution parent or the BCQuality corpus as an AL project. Missing/ambiguous roots require the smallest clarification, not scaffolding. 2. **Inspect the live connection.** Reuse the configured official AL MCP server and its real tool catalog. Discover the schemas of `al_getpackagedependencies` and `al_addproject`. If the provider or an operation is unavailabl