菜单
Composes a high-quality Business Central pull request — description from spec and commits, AL quality checklist, and Azure DevOps work-item link. Use when: open a PR, write a pull request description, prepare the PR, fill the PR template, link the ADO work item, ready for review.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Implements Business Central AL objects to a spec, enforcing coding standards, version bumping app.json, and generating test codeunits. Use when: implement an AL feature, write AL code, build from a spec, create tableextension/codeunit/page, add a field, bump app.json version, generate test codeunit, code a BC change.
Authors the Business Central spec folder (index, brief, plan, acceptance-criteria, change-log) under its module/functional area so a developer can implement without guessing. Use when: create a spec, write the spec folder, draft brief and plan, prepare a feature for development, spec out an AL change, technical specification for BC.
Turns a raw Business Central request, ADO ticket, or meeting note into a crisp user story with testable acceptance criteria, ready to be specced. Use when: plan a BC feature, write a user story, break down a ticket, clarify requirements, draft acceptance criteria, what should this feature do, turn a request into a story.
Breaks a parent Business Central Feature/Epic into child user stories (with story points) plus one estimate-carrying task per story, in Azure DevOps or GitHub. Use when: break a feature into user stories, plan a feature in ADO, decompose an epic, create child stories with story points and hours, feature breakdown, split a feature into estimable work, create sub-issues for an epic.
Generates customer-facing functional documentation and a changelog entry for a shipped Business Central feature, checking spec-vs-implementation divergence first. Use when: write functional docs, document a feature for the customer, update the changelog, PROD documentation gate, end-user docs for BC, how-to documentation.
Guides an adopter through initializing this BC ALM template for their own project — interviews them for prefix, object ID range, publisher, repo, work-item system, branching and commit conventions, runs scripts/Initialize-Template.ps1 to apply everything, then regenerates project-specific copilot-instructions grounded in the real app. Use when: initialize the template, set up this repo for my project, customize the template, run guided setup, configure prefix and object range, onboard a new BC repo, replace ABC placeholders, first-time setup, generate project-specific copilot-instructions, my copilot-instructions still describe the template.
| name | bc-ship-pull-request |
| description | Composes a high-quality Business Central pull request — description from spec and commits, AL quality checklist, and Azure DevOps work-item link. Use when: open a PR, write a pull request description, prepare the PR, fill the PR template, link the ADO work item, ready for review. |
Turn a finished feature branch into a review-ready PR. Core procedure of the bc-pr agent.
specs/**/*-{ID}-*/brief.md, plan.md, acceptance-criteria.md. If there is no spec folder,
warn the user and send them to bc-spec-author (agent: bc-spec) first.
List commits since main and group them by conventional-commit type (this is what makes the
PR body scannable):
git log origin/main..HEAD --pretty=format:"%s" --no-merges # subjects
git diff origin/main...HEAD --shortstat # files/insertions/deletions
git log origin/main..HEAD --pretty=format:"%s" --no-merges | Select-String -Pattern "#\d+" -AllMatches
feat: · Bug Fixes — fix: · Refactoring — refactor: ·
Performance — perf: · Chores — chore:/docs:/test:/style: · Other — the rest.#123 / AB#123) referenced across the commits.changelog.d/{id}-*.md fragment, warn and offer to create one before opening
the PR (see bc-build-feature). Do not delete fragments here — bc-ship-release consumes them.For each referenced id, pull Title / Type / State from the configured backend — azure-devops/*
(wit_get_work_item) or github/* (gh issue view) — and build a linked table:
| ID | Type | Title | State |
|---|---|---|---|
| #123 | User Story | Add payment tolerance | Active |
Skip this step gracefully if no work-item backend is configured (leave the id references as links).
Use ../../PULL_REQUEST_TEMPLATE.md.
[ABC-{ID}] <short description matching the brief>Closes AB#123 (Azure DevOps Boards) or Closes #123 (GitHub Issues) —
match the backend the repo was initialized with.plan.md:| Object Type | Object ID | Object Name | Change Summary |
|---|---|---|---|
| Table Extension | 50102 | Customer ABC Ext. | Added Payment Tolerance % field |
| Codeunit | 50103 | ABC Payment Tolerance Mgt. | New: tolerance calculation |
al_build), and git diff --shortstat (files changed,
+insertions / −deletions).📄 specs/<Area>/<type>-<ID>-<slug>/acceptance-criteria.md and the test codeunit.Reuse bc-review-self and report each item ✅/❌. Items needing a build →
"requires build verification".
Show the composed title + target + work items + commit count and ask before creating the PR. If anything in Step 5 fails, output a numbered "⚠️ Issues to resolve before opening PR" list with the exact file/line and the fix, and do not declare the PR ready.
The complete PR description, ready to paste, following the repo PR template — Summary, ADO Work Item, Type of Change, Affected AL Objects, Spec, Testing, Deployment Notes, Checklist.
After merge: bc-ship-release (agent: bc-deploy) to include the feature in a release
wave. If changes are requested, return to bc-build-feature (agent: bc-dev).