/al-pr-prepare

description: Prepare a clean, documented pull request draft for AL features or fixes with summary, testing notes, and checklist. ALDC workflow (Copilot prompt al-pr-prepare); invoke explicitly.
disable-model-invocation: true

> **Copilot CLI adapter — generated; do not edit this distribution.** > Select a role using /agent or copilot --agent <id>. Role names in this contract > are routing destinations, never chat mentions or evidence of an invocation. > Delegate only through the native task tool, using the exact discovered agent ID > as agent_type (for example al-planning-subagent). Inspect list_agents and the > actual task schema first. Keep all canonical human gates. Pass bounded context > inline; wait for completion (read_agent for a background task) before consuming > the result. A delegated role returns questions to its caller for the human gate. > If task or the requested custom agent is unavailable in this context, return > the blocked handoff to the caller/user. Never impersonate a missing subagent, > silently substitute general-purpose, or launch another CLI process to fake it. > Tool aliases in frontmatter select capabilities; call the actual tools exposed > by the host: view, glob, grep/rg, edit/create/apply_patch, bash/powershell, > web_fetch, task. Use a capability only when granted to this role and available. > Load domain skills through the host's skill mechanism when exposed, otherwise > read the complete bundled SKILL.md. A read is not a native skill invocation. > Resolve PLUGIN_ROOT to this installed agent's plugin directory (not the project > or original checkout). It is a path placeholder here, not a promised global > shell variable. Read docs/copilot-cli-al-tooling.md there for LSP/MCP bindings; > it supersedes older availability examples in the shared terminal contract at > skills/skill-migrate/references/cli-al-tools.md, never role duties or human gates. > Project instructions and matching .github/instructions rules remain binding; > pass the relevant excerpts to delegated roles. Canonical artifacts remain in > .github/plans/. Role write scopes are behavioral, not filesystem sandboxes. > AL execution requires a verified terminal command/runner or an actually exposed > MCP capability. Reuse the configured AL LSP for Agents wrapper through native > CLI semantic tools when exposed to this role. Inspect the catalog; do not invent > tool aliases or broaden read-only grants to enable rename/write operations. > Editor debugger controls remain separate from semantic navigation. Official AL > MCP selectors use al/<tool>; only Developer/Implementer receive compile/build/ > restore. Discover the actual callable names and pass the correct App/Test path. > No official publish/authentication tool is granted by this adapter. Triage alone > receives the optional dedicated bc-profiling and bc-snapshot proxies; discover > their schemas and confirm an authorized target/window before capture. Other > roles consume evidence. Capture does not prove autonomous snapshot debugging. > Symbol MCP: before any tools/call, verify AL CLI prerequisites are already > provisioned; this provider may auto-install AL tools on first use. A read-only > role must return that prerequisite to the caller, never bootstrap software. > Load symbols via al_packages(action: load, path: absolute consumer path). > The MCP process may run from the plugin cache; never assume its cwd is the > consumer. Use the discovered schema and report missing .app packages explicitly. > Record missing capabilities and unexecuted checks explicitly; never simulate.

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 O