Help us improve
Share bugs, ideas, or general feedback.
From al-dev-toolkit
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.
npx claudepluginhub andreipopaarggo/al-dev-toolkit --plugin al-dev-toolkitHow this skill is triggered — by the user, by Claude, or both
Slash command
/al-dev-toolkit:al-implementation [optional: additional instructions or plan path][optional: additional instructions or plan path]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
The main agent acts as a **pure orchestrator**. It runs subagents, runs builds, and reports results.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
The main agent acts as a pure orchestrator. It runs subagents, runs builds, and reports results.
- Do NOT write or edit AL code directly. All coding is done by coder subagents. - Do NOT read .al source files to "verify" coder output. That is the reviewers' job. - Do NOT fix build errors directly. Run a build-error-resolver subagent. - Do NOT fix review findings directly. Run a coder subagent for fixes. - Exception: reading project config files (app.json, CodeCop.json, .github/copilot-instructions.md) is allowed. - Exception: editing the `plan.status` line in a plan file's YAML frontmatter is allowed (and required for lifecycle transitions).Check for a plan in this priority order:
/implement path/to/plan.md), read that file.github/plans/LATEST for the most recent plan path. If the file exists and the referenced plan file exists, use it.If no plan is found by any method, ask the user.
After reading the plan file, detect its format:
---\n, it is new-format — parse the YAML frontmatter block between the first two --- lines per plan-schema.md. Use YAML as authoritative for:
objects[] — what exists, types, IDs, file paths, deps, satisfied requirementsimplementation_sequence — order of coder dispatchrequirements[] — for spec-reviewer inputproject.* — for pre-implementation config validationplan.status — lifecycle state---\n, it is legacy prose-only — continue with existing prose-reading behavior (enumerate objects from ### <Name> headings under ## Objects).Mutate status on dispatch: before starting Step 3, if the plan is new-format and plan.status == draft, update it to implementing. After a successful full cycle (Step 8 reached with no blocking reviewer verdicts — see Step 8 for exact conditions), update it to complete. Use the Edit tool to change only the status: line in the frontmatter; do not touch any other field or the prose body.
Note: this skill owns only the draft → implementing and implementing → complete transitions. The implementing → draft rollback (plan revision) is owned by al-planning, not this skill.
app.json — verify object ID ranges match the planCodeCop.json (if exists) — extract mandatoryAffixesRun subagents using the coder agent with Sonnet for all coding work.
Coder prompt contents depend on plan format. Legacy prose plans: paste the full plan content into every coder's prompt (do not tell coders to read the plan file). New-format plans: paste only the per-object context described below, not the full plan. Either way, do not ask the coder to read the plan file.
Every coder prompt must include:
[DISPATCH_CONTEXT: orchestrated] at the top of the prompt — tells the coder that this skill will run the build in Step 4 and the coder must NOT build itself (per-file builds in parallel dispatches fail on cross-file dependencies).Dispatch sizing (legacy prose plans):
Dispatch sizing (new-format plans with frontmatter):
Use objects[] + depends_on to compute a DAG. Dispatch independent objects (no unfulfilled deps) in parallel; dispatch dependents only after their prerequisites complete. Respect implementation_sequence when it orders objects that are otherwise parallelizable.
For each coder, include in the prompt:
objects[].key, type, id, name, file, extends, satisfiesproject.* from frontmatter)Example split for a 6-file new-format plan where objects[] has keys [CustomerExt, ItemExt, CreditMgt, SalesPostSub, CreditCard, PermissionSet] with SalesPostSub.depends_on=[CreditMgt]:
After all coders complete, verify no cross-file conflicts (duplicate IDs, mismatched references).
Building is mandatory after any coder subagent edits — do not skip to review without a clean build.
scope: "current" to compile and produce the .app.severities: ["error"] (and scope: "current") to retrieve any errors as a structured list. Do not parse terminal output.If #ms-dynamics-smb.al/al_build returns success: false OR #ms-dynamics-smb.al/al_get_diagnostics returns a non-empty error list, run a subagent using the build-error-resolver agent with Sonnet to fix them.
Max 3 build-fix cycles. If still failing after 3, stop and report remaining errors to the user.
After a successful build, run a subagent using the spec-reviewer agent with Sonnet. Step 6 MUST NOT start until this step returns PASS.
PASTE the full plan content into the spec-reviewer's prompt. The agent has its own verification protocol (COVERAGE / EXISTS / SUBSTANTIVE / WIRED — see the agent's own skill file). For new-format plans with requirements[], the agent runs a deterministic Requirement Coverage check against objects[].satisfies before per-object verification.
If GAPS: Run a coder subagent to fix spec gaps (include [DISPATCH_CONTEXT: orchestrated] in the coder's prompt — this skill handles the rebuild below). Rebuild to verify fixes compile. Then re-run spec-reviewer. Repeat up to 3 times. If still GAPS after 3 attempts, STOP and escalate to the user with the outstanding gaps — do not proceed to Step 6 and do not silently accept the gaps.
If PASS: Proceed to Step 6.
Do not shortcut this step. Code-reviewer and performance-reviewer verify how code is built (style, security, performance). Spec-reviewer verifies that the right code was built. Running Step 6 first wastes reviewer budget on code that may need to be rewritten.
After spec compliance passes, run TWO parallel subagents (both with Sonnet):
| Agent | Focus |
|---|---|
code-reviewer | Quality & Security — naming, Labels, DataClassification, error handling, CodeCop |
performance-reviewer | Performance — SetLoadFields, N+1, FlowField misuse, bulk ops, caching |
Both agents have their review rules referenced in their Required Reading sections.
Verdict resolution: If either says BLOCK → BLOCK. If either says FIX FIRST → FIX FIRST. APPROVE only when both approve.
[DISPATCH_CONTEXT: orchestrated] in the coder's prompt — this skill handles the rebuild below)scope: "current"), then #ms-dynamics-smb.al/al_get_diagnostics (severities: ["error"]) — if errors remain, dispatch build-error-resolver (max 3 build-fix cycles) until clean. Building after code fixes is mandatory.If the plan is new-format and all of the following are true:
code-reviewer and performance-reviewer both returned APPROVE, OR returned non-APPROVE verdicts whose fixes were applied in Step 7 and the post-fix rebuild + spot-check passedspec-reviewer returned PASSthen update plan.status: implementing → complete in the plan file (Edit tool, modify only the status: line) before presenting the summary. If any of those are false, leave status as implementing and note the blocking reviewer/build state.
Present a summary:
plan.statusSTOP. Ask if the user wants anything else.
$ARGUMENTS