/al-agent-create

description: End-to-end workflow to create a coded Business Central agent using the Agent SDK. Orchestrates the 7 phases following the official Agent Template structure. Generates all required objects by applying patterns from skill-agent-toolkit, skill-agent-task-patterns and skill-agent-instructions. ALDC workflow (Copilot prompt al-agent.create); 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.

Workflow: Create Coded Agent (Agent SDK)

End-to-end orchestration to produce a production-ready agent. This prompt does not contain SDK knowledge — it applies patterns from the loaded skills:

• `skill-agent-toolkit` → registration, 3 interfaces, Setup Codeunit, ConfigurationDialog, project structure
• `skill-agent-task-patterns` → Patterns A–H for task integration (Phase 6)
• `skill-agent-instructions` → Responsibilities-Guidelines-Instructions framework (Phase 7)

Human validation gates

🛑 markers require human approval before proceeding to the next phase.

Phase 1 — Agent specification

1.1 Gather requirements

Ask the developer:

1. **Agent purpose** — business process being automated 2. **Creation rules** — single instance? multi? always? 3. **Trigger type** — manual (page action) / EventSubscriber / email / mixed? 4. **Data scope** — tables and pages the agent needs access to 5. **Setup properties** — any agent-specific configuration beyond standard? 6. **Message processing** — input validation? output post-processing? 7. **User intervention suggestions** — what help options when stuck? 8. **Summary KPIs** — what metrics on hover card? 9. **Annotations** — what preconditions to validate (licensing, config completeness)?

1.2 Generate Agent Spec

# Agent Specification: {Agent Name}

## Identity
- Name: {Name}
- Initials: {3-4 chars}
- Object ID Range: {e.g. 52100-52199}

## Project Structure
See skill-agent-toolkit project structure section.

## Creation Rules
- Instance Model: {Single / Multi / Always}

## Interfaces
### IAgentFactory
- Setup Page: Page {ID} "{Agent} Setup" (ConfigurationDialog)
- Default Profile: {Profile ID}
- Default Permissions: {PermissionSet ID}

### IAgentMetadata
- Annotations: {precondition checks}
- Summary KPIs: {metrics for hover card}
- Custom Message Page: {Yes/No}

### IAgentTaskExecution
- Input Validation: {what to check}
- Output Post-Processing: {signatures, formatting}
- User Intervention Suggestions: {list}
- Page Context: {page-specific context}

## Task Integration
- Triggers: {events or page actions}
- ExternalId Pattern: {format}
- Patterns Applied: {A / B / C / D / E / F / G / H}

🛑 **STOP — Review spec b