Add AL implementation guidance skill

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
Jesper Schulz-Wedde 2026-09-16 13:20:57 +02:00
parent d608d89cf0
commit 1cb2b32afe
16 changed files with 1120 additions and 31 deletions

View file

@ -32,6 +32,7 @@ READ and DO are read on demand — typically by the first action skill the agent
|---|---|
| [`al-code-review/SKILL.md`](al-code-review/SKILL.md) | Exposes BCQuality through the standard `SKILL.md` format when this repository is installed as a plugin. |
| [`al-development-plan/SKILL.md`](al-development-plan/SKILL.md) | Enriches an existing AL plan read-only through the standard `SKILL.md` format; does not generate a plan or implement code. |
| [`al-implementation-guidance/SKILL.md`](al-implementation-guidance/SKILL.md) | Consults BCQuality read-only at bounded implementation checkpoints; the consuming agent still owns edits, tests, and delivery. |
Each adapter is deliberately thin. It translates the caller's request into an
Entry task context, then follows Entry's dispatch without owning routing,
@ -49,6 +50,9 @@ This gives the two skill formats distinct roles:
- `microsoft/skills/development/al-development-plan.md` is the read-only
knowledge-enrichment interface for existing plans. Consumers own format
normalization, planning, implementation, and delivery.
- `microsoft/skills/development/al-implementation-guidance.md` is the focused
implementation-time consultation interface. It uses the current diff and
decision context, and never becomes an implementation workflow.
Each host adapter deliberately shares its name with the internal action skill
for the same operation. Their locations distinguish the host integration from

View file

@ -0,0 +1,22 @@
---
name: al-implementation-guidance
description: Consult BCQuality read-only for focused Business Central AL constraints affecting the current implementation or validation decision. Does not edit or run the workflow.
---
# AL implementation guidance
This host-native adapter translates current implementation evidence into Entry's task context. It does not generate or replace a plan, edit the target, own consumed-guidance state, run an implementation or review/fix loop, compile, deploy, stage, commit, or publish.
## Execute
1. Resolve `PLUGIN_ROOT` to the directory containing this plugin's root `plugin.json`, two levels above this file.
2. Preserve the caller's `development-plan`, readable `repository`, `implementation-diff`, and `decision-context` verbatim. Preserve optional `consumed-guidance` verbatim. The consumer must provide stable decision and evidence identifiers and normalize any workflow-specific payload.
3. Build the task context for `PLUGIN_ROOT/skills/entry.md`:
- Set `goal` to focused, read-only BCQuality consultation for the supplied current implementation decision.
- List only actually supplied inputs from `[development-plan, repository, implementation-diff, decision-context, consumed-guidance]` in `inputs-available`.
- Set `technologies: [al]` only when established, and pass other applicability dimensions only when supplied or reliably determined.
- Apply `BCQUALITY_ENABLED_LAYERS` and `BCQUALITY_DISABLED_SKILLS` as described in the `al-code-review` adapter.
4. Read and execute Entry, including Preparation. Resolve BCQuality paths against `PLUGIN_ROOT`, never the target repository. Keep index, report, and scratch artifacts outside the target. An unreadable corpus is a failure, not empty knowledge.
5. Follow Entry's dispatch and verify its output metadata before invocation. This operation accepts only `implementation-guidance-report`; return `failed` rather than execute another output kind. Pass the supplied inputs unchanged and return the report unchanged. Return Entry's `no-match` or `failed` record unchanged when nothing is dispatched.
The dispatched skill returns `not-applicable` when required focus context is missing. Exact previously consumed path/decision/evidence matches are omitted deterministically, while changed evidence can produce new guidance. `no-knowledge` is not a correctness claim. The consumer retains all implementation, validation, state, review, and delivery ownership.

View file

@ -63,15 +63,24 @@ application-area: [all]
`inputs` is a list of abstract input types the skill **accepts**. Standard values:
`pr-diff`, `object-list`, `file-path`, `folder-path`, `repository`,
`telemetry-query`, and `development-plan`. Semantics are any-of: the
`telemetry-query`, `development-plan`, `implementation-diff`,
`decision-context`, and `consumed-guidance`. Semantics are any-of: the
orchestrator supplies whichever listed input types it has, and the skill is
invoked with a non-empty subset of its declared `inputs`. A skill that cannot
proceed with the supplied subset MUST return `outcome: "not-applicable"`.
`implementation-diff` is the current patch or structured changed-file/source
context, including exact affected files. `decision-context` identifies the
current phase, bounded next decision, affected symbols, changed AL properties
or tokens, tests or acceptance obligations, and stable decision/evidence
identifiers. `consumed-guidance` is optional consumer-owned deduplication input;
BCQuality does not persist it.
`outputs` is always a single-element list naming the output kind:
- `findings-report` — evaluates an input and reports defects or observations.
- `development-guidance-report` — selects and summarizes applicable BCQuality knowledge for an existing development plan without changing the target repository.
- `implementation-guidance-report` — selects focused, additional BCQuality knowledge for a current implementation or validation decision without changing the target repository.
`file-path` is one file. `folder-path` is a directory whose recursively
contained files form the complete current-state input, such as a Business
@ -340,6 +349,108 @@ The skill is read-only with respect to the target repository: no edits, generate
Reference SHAs, when present, identify the files read; they do not prove runtime pinning on their own. The consumer records and verifies the actual immutable BCQuality checkout used for both enrichment and final review, plus its filtering policy and run provenance outside the target repository. See [agent-consumption.md](../agent-consumption.md).
## Implementation-guidance-report contract
An action skill with `outputs: [implementation-guidance-report]` emits one JSON document:
```json
{
"skill": { "id": "al-implementation-guidance", "version": 1 },
"outcome": "completed | not-applicable | no-knowledge | partial | failed",
"outcome-reason": "string",
"summary": {
"request": "string",
"phase": "string",
"decision": "string",
"decision-key": "string",
"evidence-fingerprint": "string",
"candidates": 0,
"selected": 0,
"omitted-consumed": 0
},
"pins": {
"knowledge-checkout": "full commit SHA | unpinned",
"development-plan": "consumer-supplied id/version/digest | unpinned",
"implementation-evidence": "consumer-supplied id/digest | unpinned"
},
"context": {
"bc-version": "string",
"technologies": ["string"],
"countries": ["string"],
"application-area": ["string"],
"affected-files": ["string"],
"affected-symbols": ["string"],
"changed-tokens": ["string"],
"unknown": ["bc-version | technologies | countries | application-area"]
},
"knowledge": [
{
"path": "string",
"sha": "string",
"used-for": "string",
"constraints": ["string"],
"sample-paths": ["string"]
}
],
"validation-considerations": [
{ "id": "string", "reason": "string", "evidence": "string" }
],
"deduplication": {
"strategy": "omit-exact-consumed-match",
"omitted": [
{
"path": "string",
"decision-key": "string",
"evidence-fingerprint": "string",
"prior-decision": "string"
}
]
},
"suppressed": [
{
"reference": { "path": "string", "sha": "string" },
"reason": "layer-precedence | configuration"
}
],
"unresolved": ["string"]
}
```
The report is strict JSON with no surrounding commentary and is read-only with
respect to both the target repository and consumer workflow state. Index,
report, and scratch artifacts stay outside the target.
`summary` is the compact current phase/decision record. Its decision key and
evidence fingerprint are copied from `decision-context`, not generated by the
skill. `pins` preserves consumer-supplied plan and implementation identifiers;
`knowledge-checkout` is the actual checkout SHA only when established, otherwise
`unpinned`. A pin records identity, not safety or correctness.
`candidates` is the number of unique relevant articles before consumed-guidance
omission, so `selected + omitted-consumed` cannot exceed it.
`context.affected-files`, `affected-symbols`, and `changed-tokens` contain exact
current implementation evidence, not broad planned domains. Paths use forward
slashes and are repository-relative. The knowledge, validation, suppression,
unknown-context, and reference-integrity rules from
`development-guidance-report` apply unchanged.
`deduplication.strategy` is always `omit-exact-consumed-match`. An omitted entry
must exactly match a supplied consumed article path, decision key, and evidence
fingerprint. Its path is absent from `knowledge`. `summary.omitted-consumed`
equals `deduplication.omitted.length`. A changed decision key or evidence
fingerprint permits the article to be selected again. The consumer owns and
persists consumed state; BCQuality remains stateless.
`completed` requires at least one selected article, complete evaluation, and no
material unresolved applicability. `not-applicable` means a required readable
repository, plan, implementation diff, or decision context is missing or the
task is outside applicability. `no-knowledge` requires empty `knowledge` and
means no additional applicable constraints for this exact decision/evidence;
it is not a functional-correctness, safety, completeness, or release claim.
`partial` keeps incomplete evaluation or materially unresolved applicability
explicit. `failed` covers retrieval, reference-integrity, or other errors.
`outcome-reason` is required for `partial` and `failed`.
## Composition (super-skills)
A **super-skill** is an action skill whose frontmatter declares a non-empty `sub-skills: [...]`. A super-skill does not evaluate knowledge files directly; it invokes other action skills and composes their output.
@ -440,4 +551,9 @@ Conforms to the DO output contract.
## How orchestrators consume output
An orchestrator invokes an action skill with an input appropriate to the skill's declared `inputs` and uses the single output kind declared in frontmatter. It maps a `findings-report` to PR comments, build gates, or IDE diagnostics, and a `development-guidance-report` to additional constraints for its existing implementation workflow. These are the two output schemas defined by this contract; the consumer retains ownership of implementation and delivery.
An orchestrator invokes an action skill with an input appropriate to the skill's
declared `inputs` and uses the single output kind declared in frontmatter. It
maps a `findings-report` to PR comments, build gates, or IDE diagnostics; a
`development-guidance-report` to constraints for an existing plan; and an
`implementation-guidance-report` to focused constraints for the next current
decision. The consumer retains ownership of implementation and delivery.

View file

@ -23,6 +23,9 @@ task-context:
inputs-available: # values the orchestrator has ready to pass to a chosen skill
- development-plan
- repository
- implementation-diff
- decision-context
- consumed-guidance
- pr-diff
- file-path
- folder-path
@ -48,7 +51,7 @@ Before routing, ensure the knowledge index is current for the **live** clone. Th
It defaults to indexing this checkout and writes `knowledge-index.json` at the root in well under a second. When in doubt, rebuild: a sub-second rebuild is always cheaper than a stale or over-listing index, which is a correctness risk.
- The paths above assume the checkout root is the current directory. A caller that enters Entry from elsewhere — a plugin host, whose working directory is the user's own project — MUST resolve them against the BCQuality root it already knows instead. The generator resolves its own root, so invoking it by absolute path indexes and writes the right tree.
- For read-only plan enrichment, generated artifacts MUST remain outside the target repository. When the target contains the BCQuality checkout, or that checkout is immutable, pass the generator's `-IndexPath` to an external runner-owned artifact location and supply that resolved index path to the dispatched skill. Do not regenerate inside the target or modify the immutable checkout. If generation is unavailable, use READ's path-based discovery; retrieval failure is not an empty corpus.
- For read-only development guidance, generated artifacts MUST remain outside the target repository. When the target contains the BCQuality checkout, or that checkout is immutable, pass the generator's `-IndexPath` to an external runner-owned artifact location and supply that resolved index path to the dispatched skill. Do not regenerate inside the target or modify the immutable checkout. If generation is unavailable, use READ's path-based discovery; retrieval failure is not an empty corpus.
- Pruning is the consumer's job, not Entry's, and not every consumer does it: an installation that ships the whole tree gets no deny guarantee from this step. There, `enabled-layers` narrows discovery only, and the unlisted layers' files remain on disk.
- This is a side step. It MUST NOT change Entry's output — the dispatch record below is the only thing Entry emits, and build logs are never part of the dispatch JSON.
@ -128,7 +131,7 @@ Emit a single JSON document conforming to the output contract below. Entry does
- `skill.version` — copied from the dispatched skill's frontmatter so the orchestrator can detect drift between dispatch time and execution.
- `rationale` — short human-readable string, for logs and traceability.
- `inputs` — the intersection of `task-context.inputs-available` and the skill's declared `inputs`. The agent MUST pass exactly this subset when invoking the skill. Sending a strict intersection avoids accidental information leakage between skills.
- `outputs` — the dispatched skill's complete, single-element `outputs` value copied from frontmatter. This lets an orchestrator distinguish `findings-report` from read-only `development-guidance-report` before invocation. Check the declared contract and actual skill; output metadata is not a sandbox or proof of side effects. Unknown output kinds must not be silently treated as a supported report.
- `outputs` — the dispatched skill's complete, single-element `outputs` value copied from frontmatter. This lets an orchestrator distinguish `findings-report`, read-only `development-guidance-report`, and focused read-only `implementation-guidance-report` before invocation. Check the declared contract and actual skill; output metadata is not a sandbox or proof of side effects. Unknown output kinds must not be silently treated as a supported report.
Ordering of `dispatch[]` is not significant.