| name | skill-manifest |
| description | Generates a handoff manifest at the end of the ALDC pipeline so CIRCE and DELFOS can consume the extension's published surface without sharing a workspace. Use when the Conductor pipeline has completed successfully (extension compiles, all tests pass, all HITL gates cleared) and you need to emit the extension manifest from al-spec.md and the compiled .al objects. |
Skill: Extension Manifest Generator
Generates a handoff manifest at the end of the ALDC pipeline, enabling CIRCE and/or DELFOS to consume the extension's published surface without sharing a workspace.
Trigger
This skill activates after the Conductor pipeline completes successfully (all sub-agents finalized, all HITL gates passed). The agent MUST NOT generate the manifest until the extension compiles and all tests pass.
The skill reads from:
- The
al-spec.md (or equivalent spec file) for the completed extension
- The actual
.al source files in the project directory
- The
app.json for publisher, version, and extension metadata
The skill outputs a single {extension-name}-manifest.md file in the project root or a designated output/ directory.
Interactive Gate (HITL — Required)
Before generating the manifest, the agent MUST ask the user:
The extension pipeline is complete. I can generate a handoff manifest
for consumption by other frameworks in the ecosystem.
Who will consume this manifest?
(a) CIRCE — to build a Copilot Studio agent against this extension
(b) DELFOS — to build a Power BI dashboard against this extension's data
(c) Both CIRCE and DELFOS
Which option? (a / b / c)
The agent waits for the user's response. No manifest is generated without explicit selection.
If the user selects (c) Both, the agent generates a single unified manifest containing all sections for both targets, clearly labeled.
Additional Interactive Gate — CIRCE Connection Details
When the target includes CIRCE (options a or c), the agent MUST ask:
To generate the CIRCE connection section, I need your BC environment details:
BC Environment name: ___
Company name: ___
MCP Configuration Code (from Page 8351): ___
If you haven't created the MCP configuration yet, I can generate the
manifest with placeholder values that you'll fill in after configuring
Page 8351.
Manifest Structure
Header (always included)
Extension Manifest — {Extension Name}
Generated by: ALDC Conductor (v{version})
Date: {YYYY-MM-DD}
Pipeline complexity: {LOW | MEDIUM | HIGH}
Target consumers: {CIRCE | DELFOS | CIRCE + DELFOS}
Repository:
Repo: {repo URL}
Branch: {branch}
AL source path: {src/ | app/}
Spec reference: {path to al-spec.md in repo}
Section: CIRCE — MCP Connection Context (CIRCE only)
Include ONLY when target includes CIRCE. This section is intentionally lightweight. The BC MCP server (configured on Page 8351 "Model Context Protocol (MCP) Server Configurations") already exposes all API pages as tools automatically. The manifest only provides connection coordinates and a map of relevant tool names.
Connection coordinates: BC Environment, Company, MCP Configuration Code.
Relevant MCP Tools table: entityName, Domain, Purpose. In static mode, tools follow the naming pattern List<object>_PAG<ID> (read), Create<object>_PAG<ID> (create), ListUpdate<object>_PAG<ID> (modify), Delete<object>_PAG<ID> (delete), <action>_PAG<ID> (bound actions). In dynamic mode (required when >70 API pages), only 3 meta-tools appear: bc_actions_search, bc_actions_describe, bc_actions_invoke.
Tool lists: Custom tools created by this extension, Standard BC tools relevant to this domain.
Repo reference: URL for when the CIRCE agent needs to inspect business logic via GitHub MCP.
Do NOT include field-level details, OData routes, action parameters, or authentication details in this section. The MCP server provides all of that automatically when Copilot Studio connects with the environment + company + configurationName coordinates.
Section: Published API Pages (DELFOS only)
Include ONLY when target includes DELFOS. For each API page in the extension:
| Field | Description |
|---|
| OData v4 route | Full route including publisher, group, version |
| Source table | The BC table exposed by this page |
| Key fields | ODataKeyFields (typically SystemId) |
| Field table | AL Field Name, API Field Name, Type, Description |
| Filters supported | Notable filter capabilities |
| Repo source path | Relative path to the .al file |
Section: Published API Queries (DELFOS only)
Include ONLY when target includes DELFOS. For each API query in the extension:
| Field | Description |
|---|
| OData v4 route | Full route including publisher, group, version |
| Purpose | What this query aggregates or exposes |
| Source tables | Tables involved in the query |
| Columns table | Column Name, Type, Source |
| Repo source path | Relative path to the .al file |
Section: Data Structure (DELFOS only)
Include ONLY when target includes DELFOS. For each table created or extended by the extension:
| Field | Description |
|---|
| Purpose | What the table stores |
| Primary key | Key field(s) |
| Records volume estimate | Low (<1K), Medium (1K–100K), High (>100K) |
| Fields table | Field Name, Type, Dimension/Measure Candidate, Description |
| Relations table | Field, Related Table, Related Field, Cardinality |
| Table extension base | Base table name (if tableextension) |
| Repo source path | Relative path to the .al file |
Dimension/Measure classification: Text, Code, Date, Boolean → Dimension. Decimal, Integer (quantities/amounts) → Measure. When ambiguous, mark as (review) so the DELFOS Architect validates.
Section: Star Schema Hints (DELFOS only)
Include ONLY when target includes DELFOS. These are suggestions for the DELFOS Architect, not prescriptions.
Suggested fact tables: Tables that contain transactional data with numeric measures.
Suggested dimension tables: Tables that provide descriptive context (lookups, categories, entities).
Suggested relationships table: Fact Table, Fact Key, Dimension Table, Dimension Key, Cardinality.
Known gaps: Data that would enhance the model but is not currently stored or exposed. Include DAX measure suggestions where applicable.
bc-data-source-mapping compatibility: YES or NO. When YES, DELFOS can feed the manifest data directly into the bc-data-source-mapping skill without additional lookups.
Mark any uncertain mapping with (review).
Footer (always included)
Consuming instructions:
CIRCE: Copy this manifest to your CIRCE workspace. The CIRCE Architect
will use the MCP Connection Context section to configure the Dynamics 365
Business Central connector in Copilot Studio. Use GitHub MCP for deeper
inspection of business logic in codeunits and event subscribers.
DELFOS: Copy this manifest to your DELFOS workspace and reference it when
invoking the Data Modeling Expert. The Published API Pages and Data Structure
sections feed directly into the bc-data-source-mapping skill. Star Schema
Hints provide a starting point for the DELFOS Architect's validation.
Skills Evidencing block: skill loaded, source data inspected, sections generated, HITL gates passed.
Agent Behavior Rules
-
Read the completed spec and compiled AL objects before generating any section. Do not hallucinate endpoints, fields, or actions that do not exist in the codebase.
-
Every field, every endpoint, every tool name in the manifest MUST correspond to an actual AL object in the extension. If unsure, flag it and ask the user.
-
Repo source paths must be real relative paths to actual .al files. Verify against the project structure.
-
CIRCE sections stay lightweight. The BC MCP server already exposes API structure as tools. The manifest only provides connection coordinates (environment, company, MCP configuration code) and a map of relevant tool names. Do not duplicate what the MCP already provides.
-
Star Schema Hints are suggestions, not prescriptions. DELFOS Architect will validate them. Mark any uncertain mapping with (review).
-
Dimension/Measure candidate follows Power BI conventions: text, code, date, boolean → Dimension; decimal, integer (quantities/amounts) → Measure. When ambiguous, mark as (review).
-
Skills Evidencing block is mandatory. List exactly which sections were generated and confirm the HITL gate was passed.
Manifest File Naming Convention
Output filename follows this pattern: {extension-name}-manifest.md
Examples: lead-tracking-manifest.md, vibeleads-manifest.md, frontier-incidents-manifest.md
Reference URLs
