Skip to content
Development
Command

/al-spec-create

Create or revise the canonical AL technical specification through AL Spec Agent, preserving approved architecture and human approval. ALDC workflow (Copilot prompt al-spec.create); invoke explicitly.

BOOST
From plugin
aldc-al-development-collection
11211 skills28 agents11 commands4 MCP
Install
> /plugin marketplace add javiarmesto/ALDC-AL-Development-Collection
> /plugin install aldc@aldc-marketplace

How it fires

How this command gets triggered: by you, by Claude, or both.

  • Fires itselfClaude auto-loads it when your prompt matches the work.
  • You can call itInvoke it directly when you want it.
  • Slash command/al-spec-create

Context preview

What this command does when you run it.

Create or revise the canonical AL technical specification through AL Spec Agent, preserving approved architecture and human approval. ALDC workflow (Copilot prompt al-spec.create); invoke explicitly.

Command definition

al-spec-create.md
description: Create or revise the canonical AL technical specification through AL Spec Agent, preserving approved architecture and human approval. ALDC workflow (Copilot prompt al-spec.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.

AL specification entrypoint

Use `al-spec-agent` with the requirement, complexity and scope in `$ARGUMENTS`. Read and follow [the canonical specification contract](${PLUGIN_ROOT}/agents/al-spec-agent.agent.md) in full before authoring. This entrypoint does not define another specification workflow. Resolve the role link from this installed prompt's directory.

Pass the approved requirement/architecture, current spec path if revising, and any Architect-assigned scope. If this host cannot route to the named custom agent, read that same role contract in the current session and state the routing limit; do not claim another agent executed. Preserve the role's write scope and approval gate. For single-spec the output remains `.github/plans/{req_name}/{req_name}.spec.md`. For multi-spec pass one assigned SPEC-ID, its exact output path from the approved architecture, architecture revision and required approved predecessor contracts. Do not change the root requirement name to the unit slug or write an aggregate spec. Follow approved authoring groups and preserve both dependency types. Return the assigned spec for current joint consistency review and human approval.

Read more
Ships withaldc-al-development-collection

Skills-based, spec-driven, TDD-orchestrated development framework for Microsoft Dynamics 365 Business Central. Engineering systems, visibly reasoned.

Get the whole plugin