From Code to Docs: Using GitHub Copilot to Automate Business Central Documentation
Spec-driven AL development with GitHub Copilot for Business Central: a docs-to-code workflow using agents, skills and living documentation in a Git repo. The session demos user stories, specs, architecture decisions, change control notices, release notes and SharePoint sync via GitHub Actions.
- Introduction and speaker introductions
- Session overview and presentation structure
- The uncomfortable truth about documentation
- How projects evolve and documentation falls behind
- Consequences of lacking documentation
- The comfortable truth and need for documentation throughout lifecycle
- Traditional code-to-docs approach limitations
- New docs-to-code approach with GitHub Copilot
- From docs to code paradigm shift
- Spec-driven development vs rapid coding
- Problems with AI agents without specifications
- Main characteristics of spec-driven development
- Living artifacts and documentation requirements
- Keeping documentation alive in GitHub
- Documentation as source of truth for agents
- Agent framework overview and accountability
- Business consultant and architect agent roles
- Analysis documents and customer decision-making
- Developer agents and sequential workflow
- Agent skills and documentation consistency
- Documentation skills and development lifecycle
- Moving from PowerPoint to code and Visual Studio
- AL Development Collection extension and baseline
- Copilot skill collection and open source community
- Biceps framework and document delivery to SharePoint
- Symlinks for managing multiple agent frameworks
- Standardizing agentic framework across teams
- User story generation and decomposition from requirements
- Converting requirements to formatted user stories with templates
- Documentation organization, templates, and SharePoint integration
- Specifications and architecture decision documentation
- Feasibility analysis, risk assessment, and quality review process
- Change control notice creation and customer approval
- Customer approval handoff and developer phase with AI model selection
- Phase implementation results, release notes generation, and testing documentation
- Testing strategy and available resources
- Recommended tools and GitHub repositories
- Q&A: Project management approach
- Q&A: Release notes with screenshots and available tools
- Q&A: Specification branching, integration, and branch management
- Branch deletion strategy, commit history tracking, and closing remarks
- Discussion on prototypes vs documentation and proof of concepts
Overview
The session argues that documentation usually falls behind as projects evolve, and that this causes misunderstandings between customer and team. The speakers propose a docs-to-code approach: requirements, user stories, specifications and architecture decisions are captured and approved first, kept in a GitHub repository, and used as the source of truth for Copilot agents. They stress that the agents have no accountability, so humans must review and own every document.
The demo walks through a sequential agent framework (business consultant, architect, analyst, developer) and Copilot skills that enforce output structure. It covers user story generation, Word templates filled by a Python script, SharePoint delivery with GitHub Actions, a change control notice with customer approval, model selection, release notes and testing steps. The speakers say the framework is not perfect and should be adapted to each organization. The Q&A covers Jira, branching, screenshots and proof of concepts.
Key points
- Documentation is kept in the Git repository, updated before development starts and changed with each commit, so decisions are traceable to who made them and when.
- The agent workflow is sequential: business consultant (checks Microsoft Learn for existing functionality), architect, analyst (SWOT analysis), then developer agents working from atomic task plans. All generated documents need human review.
- Copilot skills give structured, consistent output where plain prompting does not. The demo includes skills for user stories, technical specs, architecture documents, feasibility analysis, change control, phase plans and release notes.
- A change control notice summarizes architecture decisions, specs, feasibility and risk, and needs customer sign-off before implementation begins.
- Suggested model use: strong models such as Opus for consultant, architect, analyst and skill creation, and cheaper models such as Haiku for development and review once tasks are well specified.
- Symlinks let several repositories share a standard agentic framework kept in a central repo with a protected main branch, and you can switch branches to test framework changes. A GitHub Action syncs user story documents to SharePoint when changes are pushed to main.
- Release notes are generated from repository context and include testing steps and limitations. Screenshots still need manual capture.
Features
| Feature | Status | At |
|---|---|---|
| Docs-to-code development methodology | status not stated | 12:53 |
| Spec-driven development framework | status not stated | 15:37 |
| Living artifacts in repositories | status not stated | 22:28 |
| AI agents with specification context | status not stated | 16:24 |
| Decision tracking with reviewer attribution | status not stated | 28:20 |
| Documentation as single source of truth for agents | status not stated | 30:04 |
| Business consultant agent | status not stated | 30:46 |
| Architect agent for specs and architecture documents | status not stated | 32:15 |
| Analyst agent with SWAT analysis | status not stated | 34:36 |
| Developer agent with plans | status not stated | 36:38 |
| GitHub Copilot skills for documentation | status not stated | 38:58 |
| Documentation skill | status not stated, demoed | 40:42 |
| AL Development Collection extension | status not stated, demoed | 43:21 |
| Copilot skill collection | status not stated, demoed | 45:00 |
| Biceps framework integration | status not stated | 45:46 |
| Symlinks for agent management | status not stated, demoed | 46:35 |
| Multi-department agentic framework standardization | status not stated, demoed | 49:15 |
| User story generation from requirements | status not stated, demoed | 51:27 |
| Skills-based document formatting with templates | status not stated, demoed | 54:57 |
| GitHub Actions integration for SharePoint documentation sync | status not stated, demoed | 58:46 |
| Architecture decision documentation with human-in-the-loop | status not stated, demoed | 59:37 |
| Feasibility analysis and risk assessment in specifications | status not stated, demoed | 1:02:05 |
| Change Control Notice with approval workflow | status not stated, demoed | 1:03:47 |
| AI model selection strategy for task complexity | status not stated | 1:06:33 |
| Release notes generation with AI | status not stated, demoed | 1:08:41 |
| Testing documentation in release notes | status not stated, demoed | 1:10:10 |
| Feature limitation documentation | status not stated, demoed | 1:10:38 |
| Test-driven development integration | status not stated | 1:11:42 |
| AL Copilot Skills | status not stated | 1:13:58 |
| OpenSpec framework | status not stated | 1:14:24 |
| Automated video-to-script generation for release notes | status not stated | 1:18:26 |
| Screenshot automation in documentation workflows | status not stated | 1:18:40 |
| Jira integration with specification documents | status not stated | 1:19:43 |
| Branch-based specification management | status not stated | 1:19:20 |
| Proof of concept approach for validation | status not stated | 1:22:05 |
AL objects mentioned
As heard in the captions. A name that matches one object page by exact type and name links to it; the others stay as named.
- codeunit “codeunit” at 4:52
- other “user story generator skill” at 40:57
- other “technical spec generator skill” at 40:57
- other “MADM file” at 52:48
- enum “enum” at 1:00:27
- table “related table” at 1:00:27
- enum 18350 “Status (IN)” at 1:10:38
Not found in BC28-30: codeunit “codeunit”, enum “enum”, table “related table”.
Quotes
- 3:55 “nobody cares or likes to document me both”
- 5:13 “yes we are going to stop how a project start. Yeah, when we are starting our project, we have clear requirements.”
- 9:11 “the point is the problem is not that we are flexible to add to up to the customer’s needs. The problem is we do”
- 9:51 “good solutions need good documentation not just at the beginning but throughout all the journey”
- 13:07 “with this new approach we capture and approve documentation at the first step of the of the process”
Disclaimers in the video
- 2:53 preview: a live demo no video. So let’s see if everything works well.
- 31:09 other: this is a framework we have been developing is good for us. Doesn’t need to be hood for you. You can adapt it to your organization.
- 33:37 other: we are providing a framework that we are working. It fit all operations doesn’t need to fit yours. You can rethink this.
- 1:05:24 other: all of these I’m showing you is not perfect you can adapt it to your organizations and provide more value to your customers
- 1:08:29 other: It works. Is it maintainable? uh perhaps not that much but it’s something you need to try and you need to do it in a control way before you moving into your day by day use
- 1:11:08 other: making it this way instead of putting your developer to just gr it down or having it without the skill …
- 1:18:13 other: this firmware is not perfect and I can say it many times. Uh you can add it manually
Presenters (as heard): Fernando Espano, Raul, Fernando, Aresto, Jeremy.
