Claude Code adapter — generated by scripts/sync-plugin-support.js, do not edit. Canonical source: prompts/al-pr-prepare.prompt.md (sha256 e6c5e60c501f779c8e3d899bc7d3f326a3fe0d545c767540a48f07ebc483e8ab). 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 Pull Request Preparation

Your goal is to prepare a pull request draft for the branch <Branch from $ARGUMENTS> summarizing all modifications, test evidence, and validation steps.

🔒 Human Gate: Pre-PR Review

Before generating PR draft document:

1. Review code changes - Present summary of all modifications
2. Security check - Confirm no sensitive data in commits
3. Quality validation - Verify tests pass and build succeeds
4. Human approval required - Obtain confirmation before creating PR draft

Process

1. Change Analysis

Inspect Branch Differences

Use codebase to analyze modifications:

codebase: Compare <Branch from $ARGUMENTS> with main branch

Use githubRepo to gather context:

githubRepo: Get branch information and commit history

Gather:

• Modified files and line counts
• New files added
• Deleted files
• Commit messages and references
• Related issues or work items

Classify Changes

Categorize into:

1. New Features - New AL objects, functionality, APIs
2. Bug Fixes - Corrections, refactors, optimizations
3. Tests - Test codeunits, scenarios, data
4. Configuration - app.json, permissions, dependencies
5. Documentation - README, comments, API docs

2. Extract Metadata

Find References: Scan commit messages for:

• Issue references (#123)
• Work item IDs
• Requirement numbers

Pattern matching:

• Fixes #123
• Closes #456
• Related to WORK-789

Identify Reviewers: If <Reviewer from $ARGUMENTS> is specified, include in the draft.

3. Generate PR Draft

Create /reports/pr-draft.md with this structure:

# Pull Request: [Feature/Fix Title]

**Branch:** `<Branch from $ARGUMENTS>`
**Target:** `main`
**Author:** [Author Name]
**Date:** [Current Date]

## Overview

[2-3 sentence description of changes]

**Type of Change:**
- [ ] New Feature
- [ ] Bug Fix
- [ ] Refactoring
- [ ] Performance Improvement
- [ ] Documentation
- [ ] Configuration Change

## Related Issues

- Closes #[issue-number]
- Relates to #[issue-number]

## Changes Summary

### File Changes

| Category | Files | +Lines | -Lines |
|----------|-------|--------|--------|
| New Features | [#] | [#] | [#] |
| Bug Fixes | [#] | [#] | [#] |
| Tests | [#] | [#] | [#] |
| Docs | [#] | [#] | [#] |
| **Total** | **[#]** | **[#]** | **[#]** |

### AL Objects Modified

#### New Objects

| Type | ID | Name | Purpose |
|------|----|----- |---------|
| Table | [ID] | [Name] | [Purpose] |
| Page | [ID] | [Name] | [Purpose] |
| Codeunit | [ID] | [Name] | [Purpose] |

#### Modified Objects

| Type | ID | Name | Changes |
|------|----|----- |---------|
| TableExt | [ID] | [Name] | [Description] |
| PageExt | [ID] | [Name] | [Description] |

#### Deleted Objects

| Type | ID | Name | Reason |
|------|----|----- |-------|
| [Type] | [ID] | [Name] | [Reason] |

## Technical Details

### Architecture Changes
[Describe design pattern or architecture changes]

### Dependencies
**New:** [List new dependencies]
**Modified:** [old version → new version]
**Removed:** [List removed dependencies]

### Database Changes
- [ ] New tables
- [ ] New fields
- [ ] Modified fields
- [ ] New keys

**Migration Notes:** [Any data migration needed]

### API Changes
**New Endpoints:**
- `GET /api/[endpoint]` - [Description]

**Modified Endpoints:**
- `[Method] /api/[endpoint]` - [Changes]

**Breaking Changes:** [List breaking changes]

### Events
**Published:** [New events and purpose]
**Subscribed:** [New subscribers and purpose]

## Testing

### Test Scenarios

1. **Scenario:** [Description]
   - **Steps:** [How to test]
   - **Expected:** [Expected result]
   - **Result:** ✅ Pass / ❌ Fail

### Automated Tests

- ✅ Unit Tests: [X/Y passed]
- ✅ Integration Tests: [X/Y passed]
- ✅ Code Coverage: [X]%

### Performance Impact

- [ ] No impact
- [ ] Improvement: [Details]
- [ ] Potential impact: [Mitigation]

## Review Checklist

### Code Quality
- [ ] Follows AL naming conventions
- [ ] Follows AL style guidelines
- [ ] No compiler warnings
- [ ] Error handling implemented
- [ ] Logging adequate

### Security
- [ ] No hardcoded secrets
- [ ] Permissions reviewed
- [ ] Input validation
- [ ] No SQL injection risks

### Testing
- [ ] All tests pass
- [ ] New code has tests
- [ ] Edge cases tested
- [ ] Manual testing done

### Documentation
- [ ] Code comments added
- [ ] API docs updated
- [ ] README updated
- [ ] Help text added

### BC Specific
- [ ] Object IDs in range
- [ ] Event patterns correct
- [ ] Page layouts user-friendly
- [ ] Translations handled

### Deployment
- [ ] Build succeeds
- [ ] Package creates
- [ ] Deployment steps documented
- [ ] Rollback plan ready

## Deployment Notes

### Steps
1. [Deployment instructions]
2. [Configuration changes]
3. [Verification steps]

### Prerequisites
[Requirements for deployment]

### Rollback Plan
[How to rollback if needed]

## Screenshots

### Before
[Previous state]

### After
[New state]

## Additional Notes

### Known Issues
[Limitations or known issues]

### Future Enhancements
[Potential improvements]

### Breaking Changes
[Breaking changes affecting existing functionality]

## Reviewer Notes

**Suggested Reviewers:**
- <Reviewer from $ARGUMENTS> - [Reason]

**Focus Areas:**
1. [Area to review carefully]
2. [Another focus area]

**Questions:**
[Specific questions or concerns]

---

**Generated by:** AL PR Preparation Workflow
**Generated on:** [Timestamp]

Output

Primary: /reports/pr-draft.md Format: Complete markdown document ready for PR creation

Success Criteria

• ✅ PR draft file created under /reports/pr-draft.md
• ✅ Changes summarized by category
• ✅ All modified AL objects documented
• ✅ Related issues referenced
• ✅ Review checklist complete
• ✅ Deployment notes clear

Common PR Patterns

Feature Addition

• Emphasize new capabilities
• User benefit focus
• Comprehensive testing
• Document APIs/events

Bug Fix

• Reference original issue
• Explain root cause
• Show before/after
• Include regression tests

Refactoring

• Explain motivation
• Show no functional changes
• Highlight improvements
• Demonstrate coverage

Performance Optimization

• Include benchmarks
• Show improvements
• Document approach
• Note trade-offs

Tips

• Be concise but thorough
• Use tables for structure
• Include file names and line numbers
• Link to related documentation
• Provide context for changes
• Make reviewer's job easy
• Include visual evidence
• Anticipate questions
• Document decisions
• Keep security visible

Next Steps

For final validation:

@AL Development Conductor   # TDD orchestration with review subagent
@AL Implementation Specialist   # Direct testing and fixes

PR draft ready for GitHub submission.