Claude Code adapter — generated by scripts/sync-plugin-support.js, do not edit. Canonical source: prompts/al-context.create.prompt.md (sha256 4fc888854e259401fcdc12f182116ae8376da9abf1330b60dc298c59ed4e3304). This workflow was written for @workspace use … in GitHub Copilot Chat. Apply these harness mappings and treat everything else as binding:

Copilot surface in the contract	Claude Code equivalent
#runSubagent / runSubagent / agents:	The Task tool with subagent_type: "aldc:<agent>"; one invocation carries everything inline (subagents are stateless)
#askQuestions / vscode/askQuestions	AskUserQuestion (main session only; a subagent returns its questions in its structured output)
handoffs: entries, and send: false on one	No equivalent — the gate is yours to keep. In Copilot a handoff is a button the human clicks, and send: false additionally hands them the prompt to review before it is sent; the host supplies the approval. Claude Code delegates through the Task tool, with no click and no review step. So never auto-delegate: present your output, get explicit approval, and only then delegate or route to another role. The handoff's routing is carried by the plugin's role entry skills; its human gate is carried by this rule
@al-architect, @al-spec-agent, @al-conductor, @al-developer, @al-developer-reviewer, @al-triage, @al-presales, @al-agent-builder, @dredd	/aldc:architect, /aldc:spec, /aldc:conduct, /aldc:develop, /aldc:review, /aldc:triage, /aldc:presales, /aldc:agent-builder, /aldc:audit (or claude --agent aldc:<agent>)
@workspace use <workflow>	/aldc:<workflow> with dots replaced by dashes (al-spec.create -> /aldc:al-spec-create); already rewritten below
${input:Name} prompt variables	Take the value from $ARGUMENTS; ask through AskUserQuestion when missing. Already rewritten below as <Name from $ARGUMENTS>
execute / runInTerminal, AL compilation or symbol restore	Developer/Implementer: discovered official AL MCP mcp__al__al_compile / mcp__al__al_build / mcp__al__al_downloadsymbols, or an installed ALTool/AL-Go runner through Bash. Use the correct App/Test project; unavailable capabilities are never simulated. Publishing retains its separate human/CI gate and is not granted by this adapter
edit, read/readFile, search, #codebase	Edit/Write, Read, Grep/Glob
#changes, changes, search/changes	Read-only git status / git diff through Bash only where granted; otherwise read the caller-supplied diff artifact or return the missing evidence request
read/problems, al_get_diagnostics, #testFailure	Discovered mcp__al__al_getdiagnostics for the explicit project, or actual compiler/test output. Diagnostics are not evidence of a fresh compile or executed tests. No result: record not-run / unavailable
al-symbols-mcp/*, upstash/context7/*, microsoft-learn/*, microsoft-docs/*	Tools named mcp__al-symbols-mcp__*, mcp__context7__*, mcp__microsoft-docs__* (or the mcp__plugin_aldc_… form). A server that is not loaded is unavailable; do not simulate it
sshadowsdk.al-lsp-for-agents/*, #usages, semantic definition/reference queries	Claude LSP with the existing AL LSP for Agents companion; discover the actual operations and project context first. VS Code tool identifiers are not Claude tool names
ms-dynamics-smb.al/*, vscode.mermaid-chat-features/*	VS Code tool identifiers do not exist here. Use only a separately discovered Claude capability; never rename community tools as Microsoft tools
vscode/memory, vscode/*	Not available; keep state in the canonical .claude/plans/ artifacts of the project
todo	TodoWrite for in-session tracking; durable state stays in .claude/plans/
"load skill-x"	The Skill tool (aldc:<skill-name>) or read ${CLAUDE_PROJECT_DIR}/.claude/skills/<skill-name>/SKILL.md
.github/instructions/*.instructions.md (applyTo)	${CLAUDE_PROJECT_DIR}/.claude/rules/*.md (paths:); /aldc:al-initialize copies them to the project's .claude/rules/ for auto-apply in the main session; inject inline for subagents exactly as the contract says
.github/skills/, .github/plans/…, docs/templates/	${CLAUDE_PROJECT_DIR}/.claude/skills/, .claude/plans/… (project-owned, aldc.yaml -> plans.root), ${CLAUDE_PROJECT_DIR}/claude-plugin/docs/templates/; already rewritten below
python … runtime helpers, --aldc-root	Paths already point at ${CLAUDE_PLUGIN_ROOT}; use python or python3, whichever exists (stdlib only)
aldc.yaml	${CLAUDE_PROJECT_DIR}/aldc.yaml when the project has one, otherwise ${CLAUDE_PROJECT_DIR}/claude-plugin/aldc.yaml

Read ${CLAUDE_PROJECT_DIR}/claude-plugin/docs/claude-al-tooling.md for this surface’s LSP/MCP bindings, then ${CLAUDE_PROJECT_DIR}/.claude/skills/skill-migrate/references/cli-al-tools.md for the shared role/evidence contract. The Claude guide supersedes older capability-availability examples, never role responsibilities or human gates.

AL Context File Generator

Generate a comprehensive context.md file that serves as the master context document for AI assistants and developers working on this AL/Business Central project.

Purpose

The context.md file provides:

• Project Overview: What this extension does and its business purpose
• Architecture Snapshot: How the code is organized and key patterns used
• Critical Decisions: Important architectural choices and their rationale
• Integration Points: Dependencies, events, APIs exposed/consumed
• Quick Navigation: Where to find specific functionality

This enables AI assistants to load complete project context quickly and make informed suggestions.

Execution Steps

1. Analyze Project Structure

Load project metadata:

# Get app.json configuration
@read_file app.json

# Understand dependencies
@al_get_package_dependencies

# Map directory structure
@list_dir src/

Identify key patterns:

# Find all table extensions
@search "tableextension" *.al

# Find all page extensions
@search "pageextension" *.al

# Find event subscribers
@search "EventSubscriber" *.al

# Find published integration events
@search "IntegrationEvent" *.al

# Find API pages
@search "APIPublisher\|APIVersion" *.al

2. Analyze Business Domain

Understand what the extension does:

• Read README.md if exists
• Analyze table/page names to understand business entities
• Check codeunit names for business processes
• Review comments and XML docs for business rules

Key questions to answer:

• What business problem does this solve?
• Who are the end users?
• What standard BC functionality does it extend?
• What industry/vertical is this for (if applicable)?

3. Document Architecture Patterns

Identify and document:

• Organization Strategy: Feature-based vs object-type folders?
• Naming Conventions: Prefixes, suffixes, patterns used
• Extension Patterns: How are standard objects extended?
• Event Usage: Subscriber patterns, custom events published
• Data Model: Key tables and their relationships
• Processing Logic: Main codeunits and their responsibilities
• UI Structure: Page organization and user flows

4. Map Integration Points

Document:

• Dependencies: What other extensions are required?
• Events Subscribed: Which standard BC events are hooked?
• Events Published: What integration events does this extension provide?
• APIs: REST/OData endpoints exposed
• External Integrations: External systems connected (if any)
• Web Services: SOAP services published (if any)

5. Capture Critical Decisions

Document key architectural choices:

• Why certain tables are structured in specific ways
• Why specific event patterns were chosen
• Performance optimization decisions
• Security/permission design rationale
• Any constraints or limitations to be aware of

6. Generate context.md

Create the file at project root with this structure:

# Project Context - [Extension Name]

> **Auto-generated**: [Date]  
> **Purpose**: Master context document for AI assistants and developers

## 1. Project Overview

### Business Purpose
[What business problem does this extension solve?]

### Target Users
- [User role 1]: [What they do with this extension]
- [User role 2]: [What they do with this extension]

### Extension Metadata
- **App ID**: [from app.json]
- **Version**: [current version]
- **Publisher**: [publisher name]
- **Platform**: [Business Central version target]
- **License**: [if applicable]

## 2. Architecture Overview

### Organization Strategy
[Describe how code is organized - feature-based folders, naming patterns, etc.]

src/ ├── [Feature1]/ │ ├── Data/ # Tables, table extensions │ ├── Processing/ # Codeunits, business logic │ └── UI/ # Pages, page extensions └── [Feature2]/ └── ...

### Key Design Patterns
- **[Pattern 1]**: [Description and rationale]
- **[Pattern 2]**: [Description and rationale]

### Naming Conventions
- **Tables**: [Pattern, e.g., "Prefix_EntityName"]
- **Pages**: [Pattern]
- **Codeunits**: [Pattern]
- **Fields**: [Pattern]
- **Variables**: [Pattern]

## 3. Data Model

### Core Tables
| Table | Object ID | Purpose | Key Relationships |
|-------|-----------|---------|-------------------|
| [Table 1] | [ID] | [Purpose] | → [Related tables] |
| [Table 2] | [ID] | [Purpose] | → [Related tables] |

### Table Extensions
| Extends | New Fields | Purpose |
|---------|------------|---------|
| [Standard Table] | [Field 1, Field 2] | [Why extended] |

### Key FlowFields
- **[Table].[FlowField]**: [What it calculates and why]

## 4. Processing Logic

### Main Codeunits
| Codeunit | Purpose | Key Methods |
|----------|---------|-------------|
| [Name] | [Responsibility] | [Method1(), Method2()] |

### Business Flows
1. **[Flow Name]** (e.g., "Order Approval Flow")
   - Entry point: [Where it starts]
   - Steps: [Key processing steps]
   - Events: [Events published/subscribed]
   - Output: [What it produces]

## 5. UI Structure

### Main Pages
| Page | Type | Purpose | Extends |
|------|------|---------|---------|
| [Page Name] | Card/List/Document | [Purpose] | [Base page if extension] |

### User Flows
1. **[User Task]**: [Navigation path and steps]

## 6. Integration Points

### Dependencies
```json
[List key dependencies from app.json]

Event Subscribers

Published Events

APIs / Web Services

• [API Name]: [Endpoint, purpose, auth method]

External Systems

• [System Name]: [Integration type, data exchanged]

7. Critical Decisions & Rationale

Decision 1: [Title]

Problem: [What problem was being solved]
Decision: [What was decided]
Rationale: [Why this approach]
Trade-offs: [What was given up]

Decision 2: [Title]

[Same structure]

8. Performance Considerations

• [Optimization 1]: [Description, where implemented]
• [Optimization 2]: [Description, where implemented]

Known Bottlenecks

• [Area]: [Description and mitigation strategy]

9. Security & Permissions

Permission Sets

• [Permission Set]: [Purpose, scope]

Data Security

• [How sensitive data is protected]

10. Testing Strategy

Test Coverage

• Unit tests: [Scope]
• Integration tests: [Scope]
• UI tests: [Scope if any]

Test Data

• [How test data is generated/managed]

11. Quick Navigation Guide

To Find...

• Customer-related logic: src/[FeatureFolder]/
• Posting logic: src/[ProcessingFolder]/
• API endpoints: src/[APIFolder]/
• Event subscribers: Search for [EventSubscriber]

Common Tasks

• Adding a new field: [Process/pattern to follow]
• Subscribing to events: [Pattern/location]
• Creating API endpoint: [Pattern/location]

12. Known Limitations

• [Limitation 1]: [Description and workaround if any]
• [Limitation 2]: [Description and workaround if any]

13. Future Roadmap

• Planned Features: [If documented]
• Deprecations: [Anything being phased out]

14. Development Guidelines

Before Making Changes

1. [Guideline 1]
2. [Guideline 2]

Code Review Checklist

• Follows naming conventions
• XML documentation added
• Events used instead of modifications
• Permission sets updated
• Tests added/updated

15. Useful Commands

# Build project
al_build

# Download symbols
al_downloadsymbols

# Run tests
@workspace /al-test

# Generate permissions
al_generatepermissionset

16. References

• Documentation: [Link to detailed docs if exists]
• Wiki: [Link to wiki if exists]
• Related Extensions: [Dependencies or companion extensions]

Maintenance: Update this file when:

• Major architectural changes occur
• New features/modules are added
• Integration points change
• Critical decisions are made

Usage: AI assistants should load this file first when providing assistance on this project.

### 7. Validation Gates

**Before finalizing:**
- ✅ File is under 500 lines for quick loading
- ✅ All sections have actual content (remove empty sections)
- ✅ Links to code examples are accurate
- ✅ Metadata from app.json is correct
- ✅ Architecture diagrams are clear
- ✅ Navigation paths are tested

### 8. Placement & Integration

**Where to create:**
- Place `context.md` at project root (next to app.json)
- If multiple projects, create in each project root

**Git configuration:**
```gitignore
# Add to .gitignore if context contains sensitive info:
# context.md

README integration: Update README.md to reference context.md:

## For AI Assistants
See [context.md](./context.md) for complete project context.

Output Format

Deliver:

1. ✅ Complete context.md file at project root
2. ✅ Summary of what was documented
3. ✅ List of any sections that need manual review/input
4. ✅ Recommendation on update frequency

Key Principles

• Concise but Complete: Include everything AI needs, nothing it doesn't
• Code-Focused: Link to actual code, not just describe
• Living Document: Easy to update as project evolves
• Quick Load: Optimized for AI context window efficiency
• Self-Contained: Should make sense without external docs

Success Criteria

A successful context.md enables:

• ✅ New AI assistant can understand project in <2 minutes
• ✅ Developers can orient themselves quickly
• ✅ Architectural decisions are clear and justified
• ✅ Navigation to specific functionality is straightforward
• ✅ Integration points are well-documented