菜单
Composes a Business Central release branch from selected merged features and guides deployment to TEST and PROD. Use when: compose a release branch, build a release wave, deploy to TEST, deploy to PROD, cut a release, select features for a wave, BC Admin Center deployment, hotfix deployment.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | bc-ship-release |
| description | Composes a Business Central release branch from selected merged features and guides deployment to TEST and PROD. Use when: compose a release branch, build a release wave, deploy to TEST, deploy to PROD, cut a release, select features for a wave, BC Admin Center deployment, hotfix deployment. |
Compose a release/* branch from a chosen set of merged features and guide deployment. Core
procedure of the bc-deploy agent. Selective deployment is the point: not every
merged feature has to go into the same wave.
List PRs merged to main since the last release tag. For each: ticket ID, description, merge
date, and whether docs/functional/ABC-{ID}-*.md exists.
Ask the user which merged features to include (numbered list). Do not assume "all".
app.json version correct.Block any feature that fails and tell the user why.
git checkout main && git pull origin main
git checkout -b release/2025-06-wave-1
git merge feature/ABC-123-payment-tolerance --no-ff -m "feat: include ABC-123 payment tolerance"
git push origin release/2025-06-wave-1
git tag rc/2025-06-wave-1 release/2025-06-wave-1 && git push origin rc/2025-06-wave-1
If feature branches were deleted after merge, cherry-pick the merge-commit SHA instead
(git log --oneline main | grep ABC-123).
changelog.d/)The customer-facing changelog is built from fragment files, not from raw commit subjects.
Read all fragments: list changelog.d/*.md (ignore README.md). Parse each one's YAML
front matter (workitem, type, module) and body (headline + optional detail bullets).
Cross-check against a git-log fallback:
git log --pretty=format:"%s" --no-merges <last-tag>..HEAD | grep -oE "#[0-9]+" | sort -u
For any ticket id in the log with no matching fragment, warn the user and offer to create one. If there are no fragments at all, fall back to the grouped git-log changelog.
Group by type in Keep a Changelog order — Added, Changed, Fixed, Deprecated,
Removed, Security — then by module, then work item.
Build the version section and insert it into CHANGELOG.md immediately after the
## [Unreleased] block (newest on top):
## [{version}] - {date}
### Added
- **{module}**: {headline} (#{workitem})
- {detail bullet}
### Fixed
- **{module}**: {headline} (#{workitem})
Delete the consumed fragments (git rm changelog.d/*.md, keeping only README.md) — a
released fragment must never linger, or it would be double-counted next release.
release/* triggers the deployment workflow if configured in
.github/AL-Go-Settings.json (environments: [{ name: TEST, branch: release/* }]). Check
the Actions tab. See ../../../docs/al-go-upgrade.md..app, then BC Admin Center → Environments → TEST → Upload Extension.Prerequisites — all must be true:
bc-docs-feature).Then tag v2025-06-wave-1, deploy to PROD, verify, close ADO tickets, notify the customer.
Branch from main (not a release branch); merge the fix to main; deploy to PROD directly;
backport to any active release/* via cherry-pick if TEST needs it too.
| Stage | ADO status |
|---|---|
| Release composed | Testing |
| Deployed to TEST | In Test |
| Customer approved | Approved |
| Deployed to PROD | Done / Closed |
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.