al-codebase-research

name	al-codebase-research
description	AL-aware codebase research and context gathering for Business Central development. Use when analyzing AL projects to understand existing objects, extensions, event architecture, project structure, performance patterns, and dependencies. Returns structured findings about Tables, Pages, Codeunits, event subscribers/publishers, AL-Go structure, and implementation options.

AL Codebase Research

Overview

This skill provides comprehensive AL-specific context gathering for Microsoft Dynamics 365 Business Central development. It researches AL codebases to identify relevant objects, extensions, events, project structure, and patterns needed for implementation planning.

When to Use

• Analyzing AL project structure before implementation
• Identifying base Business Central objects and existing extensions
• Mapping event architecture (subscribers/publishers)
• Understanding project conventions (naming, object IDs, folders)
• Finding performance-critical areas (large tables, filtering)
• Discovering existing patterns and test structures
• Gathering context for architectural decisions

Instructions

1. Research Task Comprehensively

Start with AL-Specific Discovery:

• Search for relevant AL object types (Table, Codeunit, Page, etc.)
• Identify base Business Central objects involved
• Find existing extensions (TableExtension, PageExtension)
• Locate event subscribers and publishers
• Check project structure (src/ folder organization)
• Review app.json for dependencies

AL Object Discovery Pattern:

1. Search for base object name (e.g., "Customer", "Sales Header")
2. Find TableExtensions of that object
3. Identify related Codeunits and event handlers
4. Check PageExtensions for UI impact
5. Review test codeunits for patterns
6. Map event subscribers/publishers

2. Stop Research at 90% Confidence

You have enough context when you can answer:

• ✅ What AL objects (Tables, Pages, Codeunits) are relevant?
• ✅ Are there existing extensions of base objects?
• ✅ What events (subscribers/publishers) exist or are needed?
• ✅ How does the existing AL code work in this area?
• ✅ What project structure is used (src/ folder)?
• ✅ What patterns/conventions does the AL codebase follow?
• ✅ What dependencies/symbols are involved?
• ✅ Any performance considerations (large tables, SetLoadFields)?

Don't over-research - Stop when you have actionable AL context, not 100% certainty.

3. Check Existing Context Files

Before starting research, ALWAYS check for existing context in .github/plans/:

• project-context.md → Project overview, AL structure
• session-memory.md → Recent work, decisions, patterns
• *-arch.md → Architectural designs
• *-spec.md → Technical specifications
• *-diagnosis.md → Recent debugging findings

If files exist:

• Read them before conducting research
• Reference architectural decisions in findings
• Use defined object IDs from specs
• Note recent patterns from session memory

4. Return Structured Findings

Provide a structured summary with AL-specific sections (see Output Format below).

AL-Specific Research Guidelines

Base Objects vs Extensions

Always identify:

• Base BC objects involved (e.g., Table 18 "Customer")
• Existing extensions (e.g., TableExtension 50100 "Customer Ext")
• Extension pattern used (TableExtension, PageExtension, EnumExtension)
• Can base object be modified? (NO for standard BC, only extend)

Event Architecture Analysis

Map the event landscape:

• Existing event subscribers: What events are already hooked?
• Available integration events: What can we subscribe to?
• Event publishers: Any custom events we need to call?
• Event patterns: OnBefore, OnAfter, OnValidate patterns

Project Structure

Identify project organization:

• Source folder: /src, /app, root?
• Feature-based folders: /CustomerManagement, /SalesWorkflow?
• Test organization: Separate location?
• Dependencies: Check app.json

Performance Context

Identify performance-critical areas:

• Large tables (Customer, Item, G/L Entry) requiring SetLoadFields
• Queries needing early filtering
• Temporary tables for intermediate processing

Naming and Structure Patterns

Document codebase conventions:

• Object ID ranges
• Naming patterns (prefixes, suffixes, abbreviations)
• Feature-based vs object-type-based folders

Output Format

## AL Codebase Research: {Task Name}

### Relevant AL Objects
- **Base Objects**: {List with Table/Codeunit IDs}
- **Existing Extensions**: {List with extension IDs and files}
- **Related AL Objects**: {Codeunits, Pages, etc.}

### Event Architecture
- **Subscribers Available**: {What events exist}
- **Publishers to Call**: {Custom events if applicable}
- **Pattern**: {OnBefore/OnAfter/OnValidate patterns}

### Project Structure
- **Source Location**: {/src, /app, or root}
- **Organization**: {Feature-based or object-type folders}
- **Dependencies**: {app.json dependencies}

### Key Functions/Classes to Reference
- **{File}**: {Key procedures or patterns to follow}

### Patterns & Conventions
- **Object IDs**: {Range for this feature}
- **Naming**: {Conventions observed (26-char limit, PascalCase, etc.)}
- **Folders**: {Organization pattern}
- **Performance**: {SetLoadFields usage, filtering patterns}

### Performance Considerations
- {Large tables requiring SetLoadFields}
- {Filtering strategy}
- {Temporary table needs}

### Dependencies
- **Required Symbols**: {Base Application, System Application, etc.}
- **Extension Dependencies**: {Other extensions}
- **Packages**: {.alpackages/ status}

### Implementation Options
1. **Option A**: {Approach with pros/cons}
2. **Option B**: {Alternative with pros/cons}
3. **Option C**: {Third option if applicable}

**Recommendation**: {Which option and why}

### Open Questions
- {Question 1}
- {Question 2}

### Existing Tests
- {Test codeunits found}
- {Test patterns to follow}
- {Coverage gaps}

### Uncertainties (if any)
- ❓ {Things that couldn't be determined}

Research Guidelines

Work Autonomously

• NO pausing for user feedback
• NO asking clarifying questions (document uncertainties)
• NO implementing code or writing plans
• Focus on research and findings only

Prioritize Breadth Over Depth

• Start with high-level AL object overview
• Then drill down into relevant areas
• Document file paths, object types, object IDs
• Note existing tests and testing patterns

Document AL-Specific Details

• Object IDs: Actual IDs from code (e.g., Table 18, Codeunit 80)
• File Paths: Exact paths (/app/CustomerManagement/Customer.TableExt.al)
• Function Signatures: Event subscriber signatures, procedure names
• AL Patterns: SetLoadFields, event subscribers, error handling

Stop When Actionable

You've researched enough when someone can:

• Create a structured plan with specific AL objects
• Assign proper object IDs and naming
• Design event architecture
• Structure tests per AL-Go conventions
• Apply AL performance patterns

Flag Uncertainties

If you can't find something or aren't sure, document it:

### Uncertainties
- ❓ Could not locate existing email validation - may need to create from scratch
- ❓ No event publisher for custom validation event - recommend adding one

Resources

AL Patterns Reference

AL coding patterns are documented in instruction files:

• Event-driven architecture → al-events.instructions.md
• Naming conventions → al-naming-conventions.instructions.md
• Performance patterns → al-performance.instructions.md
• Error handling → al-error-handling.instructions.md
• Extensions → al-extensions.instructions.md
• Testing & structure → al-testing.instructions.md

Your role: Research codebase patterns, don't re-document AL syntax. Focus on project-specific findings.

Example Research Session

Task: "Add email validation to Customer"

Research Steps:

1. Search for "Customer" → Find Table 18 "Customer"
2. Search for "TableExtension Customer" → Find existing extensions
3. Search for "OnBeforeValidateEvent Email" → Find event subscribers
4. Check /app and /test structure → Verify AL-Go
5. Review app.json → Check dependencies
6. Search for "Email validation" → Find similar patterns
7. Check problems → Any current issues with Customer table
8. Review test files → Understand testing patterns

Findings Returned:

• Base object: Table 18 "Customer" with "E-Mail" field
• Extension: TableExtension 50100 exists, no email validation yet
• Event: OnBeforeValidateEvent available for "E-Mail" field
• Structure: AL-Go compliant (app/ and test/ separation)
• Pattern: Event subscriber recommended
• Tests: Use [Test] attribute and asserterror
• Options: 3 approaches (Event subscriber, Custom proc, Direct validation)
• Questions: Allow empty? Case-sensitive?

Best Practices

• Keep findings concise but comprehensive
• Always provide file paths and object IDs
• Map event architecture clearly
• Suggest 2-3 implementation options with tradeoffs
• Document uncertainties rather than guessing
• Reference existing context files when available
• Focus on facts, not opinions (save decisions for Architect)