al-dev-toolkit

Run an arggoplanner (dotProject) task end-to-end: fetch task + timeline + attachments + cross-task references via the read-only mysql-planner MCP, scope to the latest unsatisfied request, then drive /al-planning → /al-implementation. Designed for fresh VS Code Copilot Chat conversations.

Package user feedback + conversation context + Copilot Chat session log into a single shareable markdown report for the plugin maintainer. Use when something in al-dev-toolkit didn't behave as expected — wrong agent ran, hook didn't fire, slash command misbehaved, build cycle stalled.

One-time setup for a BC project using al-dev-toolkit. Writes project-level instructions so future agent sessions pick up project config, plugin routing, and AL-file workflow guarding automatically. Run once per project.

BC AL compiler error resolution specialist. Use PROACTIVELY when AL build fails, CodeCop errors occur, or app.json issues arise. Fixes errors with minimal diffs, no architectural changes.

BC AL code review specialist. Reviews AL code for quality, security, and CodeCop compliance. Use after writing or modifying AL code. Performance is handled by the dedicated performance-reviewer agent.

BC AL implementation specialist. Writes AL code from a plan or applies targeted changes to existing code. Reads project rules at startup for consistent style.

OnPrem codeunit reuse reviewer. Given a plan and the current project, identifies new codeunits in the plan that could be merged into existing project codeunits instead of minted new. Respects LS Retail Panel/Command, handler codeunit, and dedicated event-subscriber exceptions.

BC AL performance review specialist. Reviews AL code exclusively for performance issues — SetLoadFields, N+1 queries, FlowField misuse, missing bulk operations, caching opportunities. Use after writing or modifying AL code, in parallel with code-reviewer.

AL coding conventions — variable naming, declaration order, self-reference, error labels, file organization. Read before writing or reviewing AL code.

Implement AL code from a plan. Use when a plan file exists (in .github/plans/ or conversation context) and the user wants to implement it — phrases like 'implement this', 'build it', 'go ahead', 'start coding'. Dispatches coder subagents, builds, and runs reviewers. Do NOT use without a plan — use al-planning first.

Use when writing new AL objects or designing extensibility. Covers events, interfaces, temp tables, TryFunction, setup tables, notifications, enums, handler codeunits, CommitBehavior, GuiAllowed, dedup guards.

Use when writing or reviewing AL code that reads from the database. Covers SetLoadFields, FindSet vs Get, set-based ops, FlowField handling, caching, query objects, unnecessary Validate.

Plan a BC feature before implementing it. Use when the user asks for a new feature, multi-object change, or significant AL implementation that needs design — involves 3+ files, new tables/pages/codeunits, event subscriptions, or architectural decisions. Produces a plan file, does NOT write code. Do NOT use for simple 1-2 file changes (use quick) or vague ideas (use brainstorming).

5 hooks across 3 events