bc-manifest-handoff-generator
Skill28 starsChanged 7 months agoMITView on GitHub
Generates a handoff manifest at the end of the ALDC pipeline so that CIRCE and/or DELFOS can consume the extension's published surface without sharing a workspace. Creates a single markdown manifest containing MCP connection context for CIRCE, published API pages and queries for DELFOS, data structure details, and star schema hints. Use when the conductor pipeline is complete, all tests pass, and a manifest is needed for handoff to CIRCE, DELFOS, or both.
In this repository38 other files it gives its agents.
- bc-agent-instructions-debuggerSkill
- bc-al-bug-fixSkill
- bc-al-code-reviewerSkill
- bc-al-project-contextSkill
- bc-api-page-generatorSkill
- bc-api-query-generatorSkill
- bc-approval-workflow-generatorSkill
- bc-attachments-generatorSkill
- skill-batch-processingSkill
- bc-business-events-generatorSkill
- bc-cds-page-generatorSkill
- bc-dataverse-entity-generatorSkill
- bc-dataverse-mapping-generatorSkill
- bc-field-propagationSkill
- bc-install-codeunit-generatorSkill
- bc-isolated-storage-generatorSkill
- bc-job-queueSkill
- bc-matrix-page-generatorSkill
- bc-number-series-generatorSkill
- bc-pricing-refactorSkill
- bc-report-selection-generatorSkill
- bc-reportsSkill
- bc-setup-table-generatorSkill
- bc-setup-wizard-generatorSkill
- bc-table-dimensions-generatorSkill
- bc-telemetry-generatorSkill
- bc-test-codeunit-generatorSkill
- bc-upgrade-codeunit-generatorSkill
- documentation-bc-analysis-generatorSkill
- documentation-bc-architecture-generatorSkill
- documentation-bc-ccn-generatorSkill
- documentation-bc-md-to-docx-converterSkill
- documentation-bc-phase-plan-generatorSkill
- documentation-bc-release-note-generatorSkill
- documentation-bc-technical-spec-generatorSkill
- documentation-bc-user-story-generatorSkill
- onprem-remote-deploySkill
- skill-contribution-assistantSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 24
Before generating the manifest, the agent MUST ask the user:
- Distinctive: line 39
If the user selects (c) Both, the agent generates a single unified manifest containing all sections for both targets, clearly labeled.
- Distinctive: line 43
When the target includes CIRCE (options a or c), the agent MUST ask:
- Distinctive: line 51
If you haven't created the MCP configuration yet, I can generate the manifest with placeholder values that you'll fill in after configuring …
- Very specific: line 57
Read references/manifest-structure.md for the complete manifest section specifications including Header, CIRCE MCP Connection Context, …
- Distinctive: line 73
Read the completed spec and compiled AL objects before generating any section.
- Distinctive: line 75
Every field, every endpoint, every tool name in the manifest MUST correspond to an actual AL object in the extension.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
.alsource files in the project directory - The
app.jsonfor 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
Read references/manifest-structure.md for the complete manifest section specifications including Header, CIRCE MCP Connection Context, Published API Pages, Published API Queries, Data Structure, Star Schema Hints, and Footer.
Summary of sections by target:
| Section | CIRCE | DELFOS |
| Header | ✓ | ✓ |
| CIRCE — MCP Connection Context | ✓ | — |
| Published API Pages | — | ✓ |
| Published API Queries | — | ✓ |
| Data Structure | — | ✓ |
| Star Schema Hints | — | ✓ |
| Footer | ✓ | ✓ |
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
.alfiles. 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: {extension-name}-manifest.md
Examples: lead-tracking-manifest.md, vibeleads-manifest.md, frontier-incidents-manifest.md
Reference URLs
- BC MCP Server Configuration
- Create Agent in Copilot Studio
- BC API Page Documentation
- Power BI Star Schema Guidance
- DELFOS bc-data-source-mapping skill: internal reference within the DELFOS framework
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

