$npx -y skills add microsoft/BCQuality --skill bcquality-al-reviewReview Business Central AL code changes using the BCQuality knowledge base. Use when reviewing an AL pull request, a working-tree diff, or a single AL file, and you want findings backed by BCQuality's curated, BC-specific quality rules.
| 1 | # BCQuality AL review |
| 2 | |
| 3 | This skill drives the BCQuality **Entry protocol** over the knowledge base that ships |
| 4 | inside this plugin. It is the plugin entry point for consumers (orchestrators, CLIs) |
| 5 | that do not already know BCQuality's internal conventions — the only convention they |
| 6 | need is "invoke this skill for an AL review." |
| 7 | |
| 8 | BCQuality itself is orchestrator-agnostic content: knowledge files plus routing and |
| 9 | action skills. This bridge is the thin consumer glue that lets a plugin host run that |
| 10 | content without hardcoding BCQuality's layout. |
| 11 | |
| 12 | ## When to use |
| 13 | |
| 14 | - Reviewing an AL pull request or an uncommitted working-tree diff. |
| 15 | - Reviewing a single AL file. |
| 16 | - Any task whose goal is "review Business Central / AL code for quality issues." |
| 17 | |
| 18 | Do **not** use this skill to *generate* AL code — it only reviews. |
| 19 | |
| 20 | ## Plugin root |
| 21 | |
| 22 | Resolve `PLUGIN_ROOT` to the directory that contains this plugin's |
| 23 | `.claude-plugin/plugin.json`. This skill lives at |
| 24 | `PLUGIN_ROOT/skills/bcquality-al-review/SKILL.md`, so `PLUGIN_ROOT` is two levels up |
| 25 | from this file. All paths below are relative to `PLUGIN_ROOT`. If the host exposes a |
| 26 | plugin-root environment variable, prefer it. |
| 27 | |
| 28 | ## Steps |
| 29 | |
| 30 | 1. **Refresh the knowledge index (best effort).** If `pwsh` is available, run |
| 31 | `pwsh PLUGIN_ROOT/tools/Build-KnowledgeIndex.ps1` from `PLUGIN_ROOT` to (re)generate |
| 32 | `PLUGIN_ROOT/knowledge-index.json` over the installed tree. This is a discovery |
| 33 | accelerator only — if `pwsh` is missing or the build fails, continue; the review |
| 34 | skills fall back to path-based discovery. |
| 35 | |
| 36 | 2. **Run Entry.** Read `PLUGIN_ROOT/skills/entry.md` and execute it against a |
| 37 | task context describing the review: |
| 38 | |
| 39 | ```yaml |
| 40 | task-context: |
| 41 | goal: "Review the AL changes for quality issues" |
| 42 | inputs-available: [pr-diff] # or [file-path] for single-file review |
| 43 | technologies: [al] |
| 44 | enabled-layers: [microsoft, community, custom] # see "Layer selection" below |
| 45 | ``` |
| 46 | |
| 47 | **Layer selection.** `enabled-layers` defaults to all three layers. A host can |
| 48 | narrow it by setting the `BCQUALITY_ENABLED_LAYERS` environment variable to a |
| 49 | comma-separated subset (e.g. `microsoft` or `microsoft,community`); when set, pass |
| 50 | exactly those layers instead of the default. This is the plugin path's only knob |
| 51 | for layer policy — see the limitation in Notes. |
| 52 | |
| 53 | Fill `bc-version`, `countries`, and `application-area` only when the caller |
| 54 | supplies them; omit them otherwise (an omitted dimension is unconstrained). |
| 55 | |
| 56 | 3. **Follow the dispatch record.** Entry returns a dispatch record naming the action |
| 57 | skill(s) to invoke — for a PR review this is normally |
| 58 | `microsoft/skills/review/al-code-review.md`. For each dispatched skill, read the |
| 59 | file and execute its Source → Relevance → Worklist → Action steps, reading |
| 60 | `PLUGIN_ROOT/skills/read.md` and `PLUGIN_ROOT/skills/do.md` on demand. |
| 61 | When `al-code-review` composes its leaves and the host supports child contexts or |
| 62 | separate model calls, run each leaf in an isolated context and roll up the returned |
| 63 | JSON. Pass each call the exact index rows for that leaf's domain so references can |
| 64 | be copied verbatim. This is the preferred execution profile for fast/small models; |
| 65 | do not force one generation to retain all domain knowledge at once. |
| 66 | |
| 67 | 4. **Emit findings.** Produce the rolled-up findings report in the DO output contract, |
| 68 | including each review finding's producer-supplied `domain` label (`outcome`, |
| 69 | `findings`, `references`, `confidence`, `suppressed`). Do not invent a different |
| 70 | shape; downstream consumers parse the DO contract without skill-specific logic. |
| 71 | Apply DO's reference-integrity gate before returning: every knowledge-backed path |
| 72 | must exist in the installed tree, must have been opened in full, and must be copied |
| 73 | verbatim. Never synthesize a plausible article slug. |
| 74 | |
| 75 | If Entry returns `no-match` or `failed`, return the dispatch record unchanged so the |
| 76 | caller can log the reason. |
| 77 | |
| 78 | ## Notes |
| 79 | |
| 80 | - This skill adds nothing to BCQuality's knowledge or routing logic; it only bootstraps |
| 81 | the existing Entry protocol from a plugin host. Knowledge and skill changes belong in |
| 82 | the layers under `PLUGIN_ROOT/microsoft/`, `PLUGIN_ROOT/community/`, and |
| 83 | `PLUGIN_ROOT/custom/`, not here. |
| 84 | - **Layer pruning is coarser than the URL/clone model.** In the clone model a consumer |
| 85 | prunes its checkout to policy *before* the agent runs, and the knowledge index is |
| 86 | rebuilt over the pruned tree, so a denied layer can never leak into discovery. A |
| 87 | plugin install ships the whole tree, so this bridge can only *narrow discovery* via |
| 88 | `enabled-layers` (`BCQUALITY_ENABLED_LAYERS`) — the denied layers' files still exist on |
| 89 | disk. Treat `enabled-layers` as |