Claude Code adapter — generated by scripts/sync-plugin-support.js, do not edit. Canonical source: prompts/al-memory.create.prompt.md (sha256 b7d76f77e364e136b033024a810f463fd1556d11066ec5010df75c06b4c573ba). 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 Memory File Generator

Generate and maintain a memory.md file that serves as the project memory - tracking decisions, changes, learnings, and important conversations across development sessions.

Purpose

The memory.md file provides:

• Session Continuity: What happened in previous sessions
• Decision Log: Why things were done a certain way
• Problem/Solution Patterns: What issues occurred and how they were solved
• TODO Tracking: What needs to be done next
• Learning Journal: Insights gained during development
• Context for AI: Prevents re-asking questions or repeating mistakes

This enables AI assistants and developers to pick up where they left off and build on previous work.

Execution Steps

1. Initialize Memory Structure

If memory.md doesn't exist, create with this template:

# Project Memory - [Extension Name]

> **Purpose**: Continuous memory across development sessions  
> **Maintained by**: AI assistants and developers  
> **Last Updated**: [Date]

## Quick Reference

**Current Focus**: [What we're working on now]  
**Next Steps**: [ImMEDIUMte next actions]  
**Blockers**: [Current blockers if any]

---

## Session Log

### [Date] - Session [N]

**Focus**: [What was worked on]

**Completed**:
- [Task 1]
- [Task 2]

**Decisions Made**:
- **[Decision]**: [Rationale]

**Problems Encountered**:
- **[Problem]**: [Solution or workaround]

**Next Session**:
- [ ] [Task to continue]
- [ ] [Task to start]

**Notes**:
- [Any important observations]

---

## Decision Log

### [Date] - [Decision Title]

**Context**: [Why this decision needed to be made]  
**Options Considered**:
1. [Option 1]: [Pros/Cons]
2. [Option 2]: [Pros/Cons]

**Decision**: [What was chosen]  
**Rationale**: [Why this option]  
**Impact**: [What this affects]  
**Review Date**: [When to revisit if applicable]

---

## Problem/Solution Patterns

### [Problem Category] - [Specific Issue]

**Symptom**: [What we observed]  
**Root Cause**: [What was actually wrong]  
**Solution**: [How we fixed it]  
**Prevention**: [How to avoid in future]  
**Related Code**: [File paths or line numbers]

---

## Learning Journal

### [Date] - [Topic/Insight]

**What We Learned**: [Key insight or pattern discovered]  
**Why It Matters**: [Impact on project]  
**Where Applied**: [Code locations]  
**Resources**: [Links to docs, articles that helped]

---

## Code Evolution

### [Feature/Module Name]

**v1.0** - [Date]
- Initial implementation
- [Key characteristics]

**v1.1** - [Date]
- Changed: [What changed]
- Reason: [Why it changed]
- Migration: [How to adapt if needed]

---

## TODO & Backlog

### High Priority
- [ ] [Task] - [Why important] - [Target date]

### Medium Priority
- [ ] [Task] - [Context]

### Future Ideas
- [ ] [Idea] - [Rationale]

### Done ✅
- [x] [Completed task] - [Date completed]

---

## Questions & Answers

### [Question]
**Asked**: [Date]  
**Answer**: [The answer found]  
**Source**: [Where answer came from - docs, testing, expert]

---

## Integration Points

### [External System/Extension Name]

**First Integrated**: [Date]  
**Current Status**: [Active/Deprecated/Planned]  
**Contact Point**: [Method - API/Event/etc]  
**Issues Encountered**: [Problems and solutions]  
**Dependencies**: [What depends on this]

---

## Performance Tracking

### [Feature/Operation]

**Baseline**: [Initial performance metrics]  
**Optimizations Applied**:
- [Date]: [Change] → [Result]

**Current State**: [Latest metrics]  
**Target**: [Performance goal]

---

## Testing Insights

### [Test Scenario]

**First Tested**: [Date]  
**Results**: [What we found]  
**Edge Cases Discovered**:
- [Edge case 1]: [How handled]

**Regression History**: [If this broke before, when and why]

---

## Communication Log

### [Date] - [Stakeholder/Team Member]

**Topic**: [What was discussed]  
**Decisions**: [Agreements reached]  
**Action Items**: [Who does what]  
**Follow-up**: [When to check back]

---

## Environment Notes

### Development Setup

**Last Working Config**: [Date]
- BC Version: [Version]
- Extensions: [Key extensions used]
- Settings: [Important VS Code/AL settings]

**Known Issues**:
- [Issue]: [Workaround]

---

## Deprecated Patterns

### [Pattern Name]

**Used**: [Date range when this was used]  
**Replaced By**: [New pattern]  
**Migration Guide**: [How to update old code]  
**Reason for Deprecation**: [Why we stopped using it]

---

## Useful Snippets

### [Snippet Name]
```al
[Code snippet that proved useful]

Use Case: [When to use this]
Source: [Where this came from]

Meeting Notes

[Date] - [Meeting Type]

Attendees: [Who was there]
Topics: [What was discussed]
Decisions: [What was decided]
Actions: [Who does what by when]

Maintenance Log

[Date] - [Maintenance Activity]

What: [What was maintained]
Why: [Reason for maintenance]
Changes: [What changed]
Impact: [What this affects]

### 2. If Memory File Exists - Update It

**Add new session entry:**
```powershell
# Check for recent changes
@changes

# Check current problems
@problems

# Check TODOs
@todos

Update with:

• New session log entry at the top
• Any decisions made in this session
• Problems solved
• Learnings discovered
• Progress on existing TODOs
• New TODOs identified

3. Session Entry Creation

For each development session, document:

Format:

### [Today's Date] - Session N

**Focus**: [Main task(s) worked on]

**Completed**:
- ✅ [Specific accomplishment 1]
- ✅ [Specific accomplishment 2]

**Decisions Made**:
- **[Decision Topic]**: [Choice made and brief reason]

**Problems Encountered**:
- **[Problem Description]**: 
  - Symptom: [What we saw]
  - Cause: [Root cause if known]
  - Solution: [How fixed or workaround]

**Learnings**:
- [Insight gained from this session]

**Next Session**:
- [ ] [Continue/start task 1]
- [ ] [Continue/start task 2]

**Files Changed**:
- `[file path]`: [What changed]

**Notes**:
- [Any other important context]

4. Decision Documentation

When architectural/technical decisions are made:

### [Date] - [Decision Title]

**Context**: 
[What situation required this decision? What were we trying to solve?]

**Options Considered**:
1. **[Option 1]**
   - Pros: [Benefits]
   - Cons: [Drawbacks]
   
2. **[Option 2]**
   - Pros: [Benefits]
   - Cons: [Drawbacks]

**Decision**: [What we chose]

**Rationale**: 
[Why this option was best given the context, constraints, and requirements]

**Implementation Notes**:
- [Key points about how this was implemented]

**Impact**: 
- Code: [What code was affected]
- Performance: [Performance implications if any]
- Maintenance: [Ongoing maintenance considerations]

**Review Date**: [Optional - when to revisit this decision]

**References**:
- [Links to documentation, discussions, etc.]

5. Problem/Solution Pattern Documentation

When bugs are fixed or challenges overcome:

### [Category] - [Problem Title]

**Date Encountered**: [Date]

**Symptom**: 
[What behavior did we observe? What was wrong?]

**Context**:
[When does this happen? What conditions trigger it?]

**Root Cause**: 
[What was actually causing the problem?]

**Solution**: 
[How we fixed it - code changes, configuration, etc.]

**Code Changed**:
```al
// Before
[problematic code]

// After
[fixed code]

Prevention: [How to avoid this in the future - pattern to follow, test to add, etc.]

Related:

• Files: [file paths]
• Similar issues: [References to related problems]
• Documentation: [Links to relevant docs]

### 6. Learning Capture

When discovering new patterns or insights:

```markdown
### [Date] - [Topic]

**What We Learned**:
[The key insight, pattern, or understanding gained]

**How We Learned It**:
[Through debugging, documentation, experimentation, etc.]

**Why It Matters**:
[Impact on the project, development efficiency, code quality, etc.]

**Where Applied**:
- `[file path]`: [How this learning was applied]

**Best Practice**:
[If this leads to a best practice for this project]

**Resources**:
- [Links to documentation that helped]
- [Code examples from BC or other sources]

7. Update Quick Reference

At the end of each session, update the top section:

## Quick Reference

**Current Focus**: [Update with current work]  
**Last Session**: [Date of last session]  
**Next Steps**: 
1. [Most imMEDIUMte next action]
2. [Second priority]

**Active Blockers**: 
- [Blocker 1]: [Status]

**Recent Achievements** (Last 7 days):
- [Achievement 1]
- [Achievement 2]

**Active Branch**: [Git branch if relevant]

8. Maintenance & Cleanup

Weekly:

• Move completed TODOs to "Done" section
• Archive old session entries (keep last 10, summarize older ones)
• Update code evolution section if major changes

Monthly:

• Review decision log - mark outdated decisions
• Consolidate similar problem/solution patterns
• Clean up deprecated patterns section
• Update environment notes if setup changed

Output Format

Deliver:

1. ✅ Created/updated memory.md at project root
2. ✅ Summary of key additions made
3. ✅ Highlight any important patterns/decisions documented
4. ✅ Suggest next session focus based on TODOs

Integration with Development Workflow

At Session Start

**AI Assistant**: Load memory.md to understand:
- What was done last session
- What the plan was for this session
- Any blockers or important context

During Development

**Capture**:
- Decisions as they're made
- Problems as they're encountered
- Learnings as they're discovered

At Session End

**Update**:
- Session log with completion status
- TODOs with progress
- Quick Reference with next steps

Key Principles

• Chronological: Most recent first for quick access
• Searchable: Use clear headings and keywords
• Contextual: Include enough context to understand later
• Actionable: TODOs and next steps are concrete
• Honest: Document failures and mistakes - they're learning opportunities
• Linked: Reference files, line numbers, other sections
• Concise: Important but brief - detailed docs go in context.md

Success Criteria

A successful memory.md enables:

• ✅ Picking up project after weeks away
• ✅ Understanding why code is the way it is
• ✅ Avoiding repeat mistakes
• ✅ Building on previous learnings
• ✅ Tracking progress over time
• ✅ AI assistant continuity across sessions

Collaboration

When multiple developers work on the project:

• Each adds their session entries
• Decisions are collaborative - note who participated
• Problem solutions are shared learning
• TODOs can be assigned to people
• Communication log tracks cross-team discussions