Turn the object-granularity al-object-author super-skill into the
feature/PR-level al-feature-author - the true authoring counterpart of
al-code-review, which takes a whole PR. feature-spec in -> whole-PR
code-artifact out.
- microsoft/skills/author/al-feature-author.md (renamed from
al-object-author.md): takes inputs [feature-spec]; decomposes it into a
cross-referenced object graph, allocates a contiguous object-ID block,
applies the mandatory affix, resolves cross-object references (API page
SourceTable = authored master), fans each derived object-spec out to the
worklisted leaves, rolls up their artifacts, reconciles the refs, and
enumerates the objects no current leaf authors (List/Card pages,
permission set, install codeunit) as open-questions. Worked example:
a Membership feature -> 3 artifacts (master table + setup table from
al-table-author, API page from al-api-page-author) rolling up to completed.
- skills/do.md (composition v1.1, STABLE-CONTRACT): add feature-spec to the
standard inputs; extend Relevance so a super-skill's inputs need not equal
its leaves' - it may derive the leaves' inputs by decomposing its own;
generalize Action rollup to findings-report OR code-artifact. Review
(findings) semantics read identically - behavior-preserving.
- .github/scripts/validate_frontmatter.py: add feature-spec to STANDARD_INPUTS.
#67 R26 generalization unchanged.
- README.md, agent-consumption.md: author family's top-level skill is now
al-feature-author.
The al-table-author leaf and the R26 generalization from #67 are unchanged.
Knowledge article count unchanged at 199.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add the second AL author leaf (al-table-author) and the al-object-author
super-skill that composes the author leaves, mirroring how al-code-review
composes the review leaves.
- microsoft/skills/author/al-table-author.md: new leaf that generates a BC
master table (and its setup singleton) from an object-spec, applying the
data-modeling knowledge (No. from number series in OnInsert via Codeunit
"No. Series", setup singleton, Last Date Modified in OnModify AND OnRename,
Blocked as inert data enforced in referencing code). Emits code-artifact.
- microsoft/skills/author/al-object-author.md: new super-skill composing
al-api-page-author + al-table-author; invokes all leaves whose inputs are
satisfied and rolls up artifacts/open-questions/outcome per do.md.
- .github/scripts/validate_frontmatter.py: generalize R26 leaf detection from
the al-*-review.md filename glob to a structural definition (an action-skill
sibling without sub-skills). Behavior-preserving for the review folder;
enables author super-skills. STABLE-CONTRACT change.
- README.md, agent-consumption.md: one-line note that the author family now
has the al-object-author super-skill.
do.md is unchanged. Knowledge article count unchanged at 199.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add the first authoring action skill (al-api-page-author) and extend the
stable DO contract with a second output kind (code-artifact) plus the
object-spec input. Reuses existing web-services API knowledge with no new
knowledge articles; article count unchanged.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
De-enumerate the AL review leaf list so it lives in exactly one place:
the al-code-review super-skill's frontmatter sub-skills list.
- al-code-review.md: drop the enumerated parenthetical from description
and remove the redundant bullet re-list in the Source section.
- README.md: remove the hardcoded count word and the enumerated domain
list from the leaf-skill sentence.
- validate_frontmatter.py: add cross-file rule R26 asserting a
super-skill's declared sub-skills exactly match the sibling
al-*-review.md leaf files on disk (missing, stale, and unregistered
leaves all fail CI).
Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
A closed range like [23..28] wrongly implies guidance stops applying after
BC28, so a reviewer targeting BC29+ would not match the file. Introduce an
open-ended shorthand [N..] meaning ''version N and every later version''.
- validate_frontmatter.py: RANGE_SHORTHAND allows an optional upper bound;
expand_bc_version returns the normalized string ''N..'' for open-ended.
- read.md: document the fourth bc-version form and its matching rule
(matches target >= N; not enumerable).
- write.md: prefer [N..] over a closed range for a feature introduced in N
and not expected to be removed.
- Apply [23..] to the actionable-errors article (actionable errors shipped
in BC23 and are not version-bounded above).
- README: mention [N..] in the frontmatter example.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Most of the corpus — FindSet/SetLoadFields/CalcFields patterns, permission
sets, SingleInstance codeunits, DataClassification, IsolatedStorage,
transaction scope, SecretText — describes BC platform behaviour that is
identical across supported versions. The seed [26..28] range on every
file implied a version-specificity the content does not actually have,
and there was no way to express "applies to every version" in the
schema the way [w1] and [all] already do for countries and
application-area.
Extend the v1 schema with a universal sentinel for bc-version, parallel
to the sentinels already defined for the other dimensions:
bc-version: [all] # applies to every BC version
[all] is mutually exclusive with explicit versions. Range shorthand
([26..28]) and explicit lists ([26, 27, 28]) continue to work for files
genuinely tied to a version-gated API or deprecation.
Update read.md (field definition, matching semantics, partial-context
rule), write.md (default to [all], use ranges only with a concrete
reason), README.md (frontmatter example), and the CI validator. All
forty existing knowledge files and the three action skills convert to
[all]; none of the current content is version-gated. Validator passes.
Python validator derived from READ, WRITE, DO, and Entry. Enforces
frontmatter shape, required sections, knowledge-file length and
no-code-blocks rule, sample-sibling naming (<slug>.good.al /
<slug>.bad.al), action-skill section ordering, and unique skill ids
per kind. Runs in GitHub Actions on PRs and pushes to main; emits
GitHub annotations when GITHUB_ACTIONS is set, plain text otherwise.
Warnings do not fail the build.
Passes cleanly against the existing microsoft-layer corpus.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
