AL review pipeline

Read the provider contract and task-context guidance. Resolve these links from this installed skill, not a sibling repository. This procedure supplements the caller's write scope, report format and human gate; it grants no extra tools and never authorizes changes to the provider or AL code.

Scope and independent evidence

Start from the requested files/diff and acceptance criteria. A standalone reviewer resolves context itself; a Conductor reviewer consumes the supplied phase context and reads precise references only for gaps. An explicitly attached object is a valid scope without a Git diff. Missing source means no code review has occurred. Read relevant rules explicitly; do not assume another agent loaded them for you. Verify claims in an implementer's report against current code and evidence. Never approve code generated in your own context as an independent review.

Execute the selected provider

1. Select the provider from this project's configuration. In plugin mode discover the exact configured identity in the host and load its instructions here; home, entryPoint and workspace belong to multiroot selection. Do not fall back to a different clone or rename a skill implicitly.
2. Follow the loaded provider's execution model. For an instruction-based skill, loading starts the workflow: apply its Entry/routing, READ/DO and dispatched checks to the actual inputs. You produce their results; do not wait for the host to emit them automatically or recursively invoke the same skill. A tool invocation is required only when the loaded provider actually requires one.
3. Derive layers and filters from supported provider configuration/defaults. Preserve the actual routing result. Do not pick only the most obvious leaf: account for each dispatched check and each applicable child of a super-skill as completed, not applicable, skipped with reason, partial, failed or pending. Follow provider relevance rules; do not execute irrelevant checks merely to fill a table. Reuse already-read knowledge within this invocation. Entry may return more than one top-level skill in dispatch[] — for example the al-code-review super-skill plus the Community al-agents-review leaf, which is a first-level peer and not one of the super-skill's children. Execute every dispatched entry and retain every resulting findings-report; never treat the first report as the whole run. Roll each one into sub-results and account for it in coverage under its own domain label. When the provider documents bounded retrieval helpers (BCQuality: tools/Search-Knowledge.ps1 for the catalog and tools/Get-KnowledgeArticles.ps1 for bodies), prefer them over ad-hoc reads where an execution capability exists: they page deterministically, cap each response, and return per-article SHA-256 so a cited body is provably the one that was read. Without that capability, use the provider's native bounded reads through EOF and never treat a retrieval failure as an empty result.
4. Index refresh is independent. If writes/PowerShell are unavailable or forbidden, record provider.index.status: not-attempted and use the provider's documented path-based lookup. When the project carries an installer receipt (.github/aldc-bcquality-index.json) whose corpusSha matches the observed corpus revision, report provider.index.status: prebuilt with the receipt's generator, index path, SHA-256 and corpus revision; a bare status is refused. Map the receipt into the observation as indexPath → index.path, indexSha256 → index.sha256; generator and corpusSha carry over unchanged. Then use the provider's index-backed retrieval — including its bounded pagination and per-article content-hash validation. A mismatched or absent receipt is not-attempted, not a failure. A missing fresh index alone does not cancel code review. If lookup fails, name the exact resource, attempted operation and observed error.
5. Retain actual sub-results and references. Reading a leaf or describing its intended behavior is not a completed check. An executed attempt can fail or be partial; executed: true does not mean success. Never reconstruct unobserved results afterwards as evidence. Zero findings is valid for completed checks.

Cover gaps without inventing parity

Only completed provider results reduce native coverage. Check applicable ALDC rules/skills for uncovered domains: naming, performance, error handling, events, permissions, APIs and testing. Check extension boundaries, actual project layout, and approved acceptance criteria. Do not require a particular folder layout merely because it appears in an example; identify the project's governing rule. Do not assume a custom BCQuality layer exists or covers ALDC conventions. Where no native equivalent exists, report the coverage gap explicitly.

Separate findings from coverage. A valid minor convention finding need not imply a compiler/runtime error. Cite the exact applicable rule and file location; retain, resolve or retract it based on evidence, not because another provider found nothing. contracts.namingConvention in aldc.yaml names planning documents, not AL files.

Security and BCQuality disposition

Always run the five security checks of review.security against al-security.instructions.md, whatever the provider covered. They exist because every agent-built app audited in October 2026 failed the same points (MCP with writes for everything, wide permission sets, unencrypted keys, var events that skip a check).

Reading an article is not applying it. Open each article of the BCQuality selection and give it a disposition in review.bcquality.articles (applied, not-applicable with reason, or dismissed with a technical reason citing file:line). The requirement not asking for something is never a reason to dismiss an applicable article: report it as a finding instead.

Where the selection comes from. Use the selection the caller supplied (Conductor passes it inline). When there is none and BCQuality is enabled, make it yourself before reviewing: from the configured BCQuality root, pick the knowledge articles that concern the domains and object types of the changed code, using the provider's catalog search (BCQuality: tools/Search-Knowledge.ps1), its knowledge skill (al-knowledge) or its documented path-based lookup. Record how you selected them in provider.detail. With enabled: false there is no selection and nothing is probed.

Two execution paths for BCQuality. In the October 2026 Claude Code runs a provider skill loaded inside a subagent never completed Entry → dispatch → leaves; this host has not been measured. So:

1. Selection path (primary, always). The selection comes from the same BCQuality root the provider is loaded from. Reading every selected article and giving each a disposition is an executed BCQuality check for those articles: set review.bcquality.outcome: "selection-completed" and provider.execution: "aldc-selection" with the number of articles. Do not mark the review partial because Entry was not run.
2. Provider path (extra, when feasible). You may also run the provider's Entry flow (al-code-review) as described above. If it completes, keep its sub-results verbatim and set outcome: "completed". If it does not complete, record that in provider.detail and keep the selection result; it is not a failure. A selected article without a disposition is the only BCQuality reason for partial.

When the app extends Agent Metadata Provider, also fill review.agent-sdk from the Completeness checklist in al-agent-toolkit.instructions.md.

Return an honest result

Use the shared review report for direct/Conductor reviews; Dredd keeps its advisory Audit-Report format. In either format include a compact coverage list with domain/check, status, source and evidence/reason, plus the provider identity and independent index state. Keep original provider sub-results intact; coverage is the caller's summary. A requested check left pending makes the overall result partial. Provider failure with fully completed, adequate native coverage may still complete the stated native scope, but must not be presented as a completed BCQuality review.

Compilation and tests are separate evidence: record current-artifact evidence as validated or not validated and say whether supplied or actually executed. Static analysis and Problems are not a build or a runtime test. For an explicitly static review, absence of a build is a limitation, not an invented AL defect. For a delivery gate requiring build/tests, missing evidence keeps that gate pending. A partial/failed review never becomes approval merely because finding counts are zero.

When declared review criteria were supplied (<req>.bcq-criteria.json), report them in review.criteria after the findings are final: a criterion is unmet when a retained finding cites its path (match on references[0].path), met when its domain was completed by the provider and no retained finding cites it, and not-evaluated when that domain's check did not complete. Count house rules (layer: custom) separately. This is bookkeeping over findings that already exist; it adds no finding, changes no severity and never alters the verdict.