Rename authoring super-skill al-feature-author -> al-code-author

Naming/framing change only - the authoring counterpart to al-code-review is
now the role-level al-code-author. The Action/Output substance is unchanged:
the decompose -> per-object fan-out -> roll up -> reconcile logic and the
Membership worked example stay exactly as they were and correctly describe the
skill's current mode (greenfield feature authoring).

- git mv al-feature-author.md -> al-code-author.md; id al-code-author,
  title "AL code author", reframed description. Intro now states the role
  (authoring counterpart to al-code-review, produces a whole PR of code) and
  is honest that greenfield feature authoring is its first and currently only
  mode (other modes such as defect-fix-from-bug-report are future extensions).
  inputs [feature-spec], outputs [code-artifact], sub-skills [al-api-page-author,
  al-table-author] and dimension fields all unchanged.
- skills/do.md: one-word consistency tweak in the Composition Relevance example
  (a feature author -> a code author). Behavior-preserving; the findings/Action
  rollup path is byte-identical.
- README.md, agent-consumption.md: author family's top-level skill is now
  al-code-author.

R26 generalization and the al-table-author leaf from #67 are unchanged.
Knowledge article count unchanged at 199.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

README.md

@@ -52,7 +52,7 @@ Skills define how agents consume knowledge. They come in three flavors:
 
   READ and DO are read on demand — typically when the first dispatched action skill runs. They are not prerequisites for invoking Entry. WRITE is only used when scaffolding new content.
 
-- **Action skills** — concrete skills that follow the Action Skill template to do real work (review code, audit telemetry, etc.). Action skills live inside the layers that own them (`/microsoft/skills/`, `/community/skills/`, `/custom/skills/`). An action skill is either a **leaf** that evaluates knowledge files directly, or a **super-skill** that composes other action skills (declared via `sub-skills` in frontmatter). The canonical reference is [`microsoft/skills/review/al-code-review.md`](microsoft/skills/review/al-code-review.md) (super-skill), which composes the AL review leaf skills under [`microsoft/skills/review/`](microsoft/skills/review/) — one per knowledge domain. Most action skills today *review* code and emit a findings-report, but the family also includes an `author` group that *generates* code — applying the same knowledge to scaffold new objects and emitting a `code-artifact` instead of findings. Its object-type leaves are [`al-api-page-author`](microsoft/skills/author/al-api-page-author.md) (generates a Business Central API page from an object spec) and [`al-table-author`](microsoft/skills/author/al-table-author.md) (generates a master table and its setup table). The authoring family's top-level skill is the [`al-feature-author`](microsoft/skills/author/al-feature-author.md) super-skill: it takes a `feature-spec`, decomposes it into per-object specs, composes the object-type author leaves, reconciles the cross-object references, and emits a whole-PR `code-artifact` — the authoring counterpart to how `al-code-review` takes a PR and composes the review leaves.
+- **Action skills** — concrete skills that follow the Action Skill template to do real work (review code, audit telemetry, etc.). Action skills live inside the layers that own them (`/microsoft/skills/`, `/community/skills/`, `/custom/skills/`). An action skill is either a **leaf** that evaluates knowledge files directly, or a **super-skill** that composes other action skills (declared via `sub-skills` in frontmatter). The canonical reference is [`microsoft/skills/review/al-code-review.md`](microsoft/skills/review/al-code-review.md) (super-skill), which composes the AL review leaf skills under [`microsoft/skills/review/`](microsoft/skills/review/) — one per knowledge domain. Most action skills today *review* code and emit a findings-report, but the family also includes an `author` group that *generates* code — applying the same knowledge to scaffold new objects and emitting a `code-artifact` instead of findings. Its object-type leaves are [`al-api-page-author`](microsoft/skills/author/al-api-page-author.md) (generates a Business Central API page from an object spec) and [`al-table-author`](microsoft/skills/author/al-table-author.md) (generates a master table and its setup table). The authoring family's top-level skill is the [`al-code-author`](microsoft/skills/author/al-code-author.md) super-skill — the authoring counterpart to how `al-code-review` takes a PR and composes the review leaves: it takes a `feature-spec`, decomposes it into per-object specs, composes the object-type author leaves, reconciles the cross-object references, and emits a whole-PR `code-artifact`.
 
 ### Agent bootstrapping
 

agent-consumption.md

@@ -71,7 +71,7 @@ The output contract is defined in the DO meta-skill so that every action skill
 
 The orchestrator parses this **without skill-specific logic**. This is the point of the contract: orchestrators and action skills evolve independently.
 
-> **Authoring skills.** The same four-step pattern also drives *authoring* skills, which generate code rather than review it. They consume an `object-spec` and emit a `code-artifact` (the full generated AL as an escaped string, with per-artifact `references`, `notes`, and task-level `open-questions`) instead of a findings-report. The orchestrator maps each artifact to **file creation or scaffolding** in the target repo rather than to PR comments or build gates. The object-type leaves are `microsoft/skills/author/al-api-page-author.md` (API page) and `microsoft/skills/author/al-table-author.md` (master table and its setup table); the `code-artifact` contract is defined in [`skills/do.md`](skills/do.md). The authoring family's top-level skill is the `microsoft/skills/author/al-feature-author.md` super-skill: it takes a `feature-spec`, decomposes it into per-object specs, composes the object-type author leaves, reconciles cross-object references, and emits a whole-PR `code-artifact` — the authoring counterpart to how `al-code-review` takes a PR and composes the review leaves.
+> **Authoring skills.** The same four-step pattern also drives *authoring* skills, which generate code rather than review it. They consume an `object-spec` and emit a `code-artifact` (the full generated AL as an escaped string, with per-artifact `references`, `notes`, and task-level `open-questions`) instead of a findings-report. The orchestrator maps each artifact to **file creation or scaffolding** in the target repo rather than to PR comments or build gates. The object-type leaves are `microsoft/skills/author/al-api-page-author.md` (API page) and `microsoft/skills/author/al-table-author.md` (master table and its setup table); the `code-artifact` contract is defined in [`skills/do.md`](skills/do.md). The authoring family's top-level skill is the `microsoft/skills/author/al-code-author.md` super-skill — the authoring counterpart to how `al-code-review` takes a PR and composes the review leaves: it takes a `feature-spec`, decomposes it into per-object specs, composes the object-type author leaves, reconciles cross-object references, and emits a whole-PR `code-artifact`.
 
 ### 7. Orchestrator integrates
 The orchestrator turns findings into PR comments, build gates, or IDE diagnostics, and links the references back to the knowledge files so the PR author — human or agent — can read the guidance.

microsoft/skills/author/al-code-author.md

@@ -1,9 +1,9 @@
 ---
 kind: action-skill
-id: al-feature-author
+id: al-code-author
 version: 1
-title: AL feature author
-description: Generates a coherent set of BC objects (a whole feature) from a feature-spec by decomposing it into object specs, composing the AL author leaf skills, and reconciling cross-object references.
+title: AL code author
+description: Authors Business Central code by composing the AL author leaf skills - the authoring counterpart to al-code-review. Its current authoring mode greenfields a feature, decomposing a feature-spec into objects, composing the object-type author leaves, and reconciling cross-object references to emit a whole-PR code-artifact.
 inputs: [feature-spec]
 outputs: [code-artifact]
 bc-version: [all]
@@ -15,9 +15,11 @@ sub-skills:
   - microsoft/skills/author/al-table-author.md
 ---
 
-# AL feature author
+# AL code author
 
-Generates a coherent set of Business Central objects - a whole **feature** - from a `feature-spec` by composing the leaf AL author skills. This is a **super-skill** and the feature-level authoring counterpart to `al-code-review`. Where `al-code-review` takes a whole PR and composes the review leaves, rolling up their findings-reports, `al-feature-author` takes a whole feature and composes the author leaves, rolling up their `code-artifact` reports into a single whole-PR `code-artifact`.
+`al-code-author` is the role-level **authoring counterpart to `al-code-review`**: where `al-code-review` takes a whole PR and composes the review leaves, rolling up their findings-reports, `al-code-author` composes the leaf AL author skills to **produce a whole PR of code**, rolling up their `code-artifact` reports into a single whole-PR `code-artifact`. It is a **super-skill** — it composes other author skills rather than reading knowledge files directly.
+
+Its **first and currently only** authoring mode is **greenfield feature authoring**: given a `feature-spec` it decomposes the feature into a set of new objects, composes the object-type author leaves, and reconciles the cross-object references. Other modes — for example fixing a defect from a bug report, which needs a different input and a *locate-and-modify* Action rather than greenfield decomposition — are future extensions of this same entry skill and are out of scope today.
 
 The super-skill's own input (`feature-spec`) is coarser than its leaves' input (`object-spec`), and bridging that gap is this skill's job. Its **Action** decomposes the `feature-spec` into a cross-referenced graph of object specs, feeds each object spec to the worklisted leaves, rolls up the artifacts they produce, and reconciles the references across those objects. It does not evaluate knowledge files directly and performs **no agent self-review pass**: `code-artifact` output has no findings channel, so composition here is *decompose -> invoke leaves -> roll up artifacts -> reconcile*.
 
@@ -36,10 +38,10 @@ This skill composes those leaves; it does not read knowledge files directly. Add
 
 A sub-skill is relevant when both of the following hold:
 
-- Its declared `inputs` will be satisfied. The leaves declare `inputs: [object-spec]`; this super-skill declares `inputs: [feature-spec]`. The inputs differ, and that is expected: the feature author will **supply each leaf an `object-spec` derived from decomposing the `feature-spec`** (see Action). Relevance is judged against those derived inputs, not against the raw `feature-spec`. Because every derived object spec is an `object-spec`, both leaves' inputs are satisfied whenever the orchestrator supplies a `feature-spec`.
+- Its declared `inputs` will be satisfied. The leaves declare `inputs: [object-spec]`; this super-skill declares `inputs: [feature-spec]`. The inputs differ, and that is expected: the code author will **supply each leaf an `object-spec` derived from decomposing the `feature-spec`** (see Action). Relevance is judged against those derived inputs, not against the raw `feature-spec`. Because every derived object spec is an `object-spec`, both leaves' inputs are satisfied whenever the orchestrator supplies a `feature-spec`.
 - The orchestrator has not disabled the sub-skill via configuration.
 
-Per the DO composition contract, the super-skill MUST NOT filter sub-skills by task content. `al-feature-author` does not inspect the `feature-spec` to predict which object types it contains and then pick leaves accordingly. Every worklisted leaf is invoked against every derived object spec; each leaf **self-selects** by returning `outcome: "not-applicable"` when a given object spec is not for its object type (`al-api-page-author` returns `not-applicable` for a table spec; `al-table-author` returns `not-applicable` for an API-page spec), exactly as review leaves signal non-applicability with `not-applicable` / `no-knowledge`. There is no object-type dispatch in the super-skill.
+Per the DO composition contract, the super-skill MUST NOT filter sub-skills by task content. `al-code-author` does not inspect the `feature-spec` to predict which object types it contains and then pick leaves accordingly. Every worklisted leaf is invoked against every derived object spec; each leaf **self-selects** by returning `outcome: "not-applicable"` when a given object spec is not for its object type (`al-api-page-author` returns `not-applicable` for a table spec; `al-table-author` returns `not-applicable` for an API-page spec), exactly as review leaves signal non-applicability with `not-applicable` / `no-knowledge`. There is no object-type dispatch in the super-skill.
 
 Sub-skills that fail either check are not invoked and are recorded in `skipped-sub-skills`:
 
@@ -48,7 +50,7 @@ Sub-skills that fail either check are not invoked and are recorded in `skipped-s
 
 ## Worklist
 
-The worklist is the list of sub-skills judged relevant by the previous step - the leaves whose (derived) `inputs` will be satisfied and that are not disabled by configuration. Every sub-skill in the worklist is invoked in the Action step, once per derived object spec. Because both leaves accept an `object-spec` and the feature author derives object specs from the `feature-spec`, both are on the worklist whenever a `feature-spec` is supplied and neither is disabled by configuration.
+The worklist is the list of sub-skills judged relevant by the previous step - the leaves whose (derived) `inputs` will be satisfied and that are not disabled by configuration. Every sub-skill in the worklist is invoked in the Action step, once per derived object spec. Because both leaves accept an `object-spec` and the code author derives object specs from the `feature-spec`, both are on the worklist whenever a `feature-spec` is supplied and neither is disabled by configuration.
 
 ## Action
 
@@ -97,12 +99,12 @@ Derive `outcome` using the DO *Outcome rollup* rules over the multiset S of all
 
 Output conforms to the DO `code-artifact` output contract, extended with `sub-results` and `skipped-sub-skills`.
 
-A populated example - a `feature-spec` for a **Membership** feature. The feature author decomposes it into two object specs: a `Membership Member` master table and a `Membership Member` API page bound to it. It reserves the contiguous ID block 50100-50102, feeds each object spec to both leaves, and reconciles the API page's `SourceTable` to the authored master. `al-table-author` authors the master and its setup table (2 artifacts); `al-api-page-author` authors the API page (1 artifact); each leaf returns `not-applicable` for the other's object spec. The three artifacts roll up under `completed`, and the List/Card pages, permission set, and install codeunit the feature still needs - which no current leaf authors - are listed as `open-questions`:
+A populated example - a `feature-spec` for a **Membership** feature. The code author decomposes it into two object specs: a `Membership Member` master table and a `Membership Member` API page bound to it. It reserves the contiguous ID block 50100-50102, feeds each object spec to both leaves, and reconciles the API page's `SourceTable` to the authored master. `al-table-author` authors the master and its setup table (2 artifacts); `al-api-page-author` authors the API page (1 artifact); each leaf returns `not-applicable` for the other's object spec. The three artifacts roll up under `completed`, and the List/Card pages, permission set, and install codeunit the feature still needs - which no current leaf authors - are listed as `open-questions`:
 
 ```json
 {
   "skill": {
-    "id": "al-feature-author",
+    "id": "al-code-author",
     "version": 1
   },
   "outcome": "completed",
@@ -348,7 +350,7 @@ The all-not-applicable case - a `feature-spec` whose objects neither leaf author
 ```json
 {
   "skill": {
-    "id": "al-feature-author",
+    "id": "al-code-author",
     "version": 1
   },
   "outcome": "not-applicable",

skills/do.md

@@ -299,7 +299,7 @@ Composition is flat: a super-skill MAY list only leaf skills (skills without the
 The five required sections still apply. Their meaning shifts from knowledge files to sub-skills:
 
 - `## Source` — names the sub-skills invoked (mirrors `sub-skills` in frontmatter).
-- `## Relevance` — rules for deciding which sub-skills apply to the current task. A sub-skill is relevant when its declared `inputs` are satisfied — either directly by the orchestrator's provided inputs, or by inputs the super-skill itself will supply by decomposing its own input — and the orchestrator has not disabled it via configuration. A super-skill's own `inputs` need not equal its leaves' `inputs`; when they differ (for example, a feature author declares `inputs: [feature-spec]` while its leaves declare `inputs: [object-spec]`), the super-skill's `## Action` decomposes its own input into the inputs its leaves require, and relevance is judged against those derived inputs. The super-skill MUST NOT filter sub-skills by task content (for example, by inspecting the diff or the file). Task-level applicability is the sub-skill's own responsibility; sub-skills signal non-applicability by returning `outcome: "not-applicable"` or `outcome: "no-knowledge"`.
+- `## Relevance` — rules for deciding which sub-skills apply to the current task. A sub-skill is relevant when its declared `inputs` are satisfied — either directly by the orchestrator's provided inputs, or by inputs the super-skill itself will supply by decomposing its own input — and the orchestrator has not disabled it via configuration. A super-skill's own `inputs` need not equal its leaves' `inputs`; when they differ (for example, a code author declares `inputs: [feature-spec]` while its leaves declare `inputs: [object-spec]`), the super-skill's `## Action` decomposes its own input into the inputs its leaves require, and relevance is judged against those derived inputs. The super-skill MUST NOT filter sub-skills by task content (for example, by inspecting the diff or the file). Task-level applicability is the sub-skill's own responsibility; sub-skills signal non-applicability by returning `outcome: "not-applicable"` or `outcome: "no-knowledge"`.
 - `## Worklist` — the final list of sub-skills to invoke; the rest go to `skipped-sub-skills`.
 - `## Action` — invoke each worklisted sub-skill with the appropriate subset of inputs (a super-skill whose `inputs` differ from its leaves' derives those leaf inputs here), collect its report verbatim into `sub-results`, and roll its results up into the super-skill's top-level list according to the output kind. For a `findings-report`, copy its `findings[]` into the super-skill's top-level `findings[]` with `from-sub-skill` set. For a `code-artifact`, copy its `artifacts[]` into the super-skill's top-level `artifacts[]` (the `code-artifact` schema has no per-artifact `from-sub-skill` field, so leaf attribution is preserved through `sub-results`). In both cases a sub-skill with `outcome: "failed"` contributes nothing to the super-skill's top-level list (`findings[]` or `artifacts[]`) and MUST NOT contribute to the super-skill's `summary.counts` (its report is still preserved in `sub-results` for traceability, consistent with DO's rule that consumers ignore a failed skill's output).
 - `## Output` — the super-skill's output contract, including `sub-results` and, if any, `skipped-sub-skills`.