원클릭으로 Manus에서 모든 스킬 실행

bc-ship-pull-request

스타2

포크0

업데이트2026년 7월 3일 10:35

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 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

AlexanderErdelyi

AlexanderErdelyi/bc-alm-template

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

BC · Ship a Pull Request

Turn a finished feature branch into a review-ready PR. Core procedure of the bc-pr agent.

1 — Read the spec

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.

2 — Build the changelog from commits

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

Features — feat: · Bug Fixes — fix: · Refactoring — refactor: · Performance — perf: · Chores — chore:/docs:/test:/style: · Other — the rest.
Extract every work-item id (#123 / AB#123) referenced across the commits.
Changelog-fragment cross-check (if the repo uses them): for any ticket id in the commits with no matching 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.

3 — Fetch work-item context

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).

4 — Compose the PR

Use ../../PULL_REQUEST_TEMPLATE.md.

Title: [ABC-{ID}] <short description matching the brief>
Work-item link: Closes AB#123 (Azure DevOps Boards) or Closes #123 (GitHub Issues) — match the backend the repo was initialized with.
Type of change: derive from the spec (Feature / Bug Fix / Hotfix / Refactor / Docs).
Changes summary: the grouped changelog from Step 2 (Features / Bug Fixes / Refactoring / …).
Related work items: the table from Step 3.
Affected AL Objects table — extract from 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

Build info: build status (from al_build), and git diff --shortstat (files changed, +insertions / −deletions).
Spec link: 📄 specs/<Area>/<type>-<ID>-<slug>/
Testing: reference acceptance-criteria.md and the test codeunit.
Deployment notes: any manual setup, config, or data migration.

5 — Run the quality checklist

Reuse bc-review-self and report each item ✅/❌. Items needing a build → "requires build verification".

6 — Confirm, then flag blockers

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.

Output

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.

Next step

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).

이 저장소의 다른 Skills

같은 저장소

bc-build-feature

AlexanderErdelyi/bc-alm-template

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.

2026-07-062

bc-spec-author

AlexanderErdelyi/bc-alm-template

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.

2026-07-062

bc-plan-user-story

AlexanderErdelyi/bc-alm-template

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.

2026-07-032

bc-breakdown-feature

AlexanderErdelyi/bc-alm-template

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.

2026-07-032

bc-docs-feature

AlexanderErdelyi/bc-alm-template

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.

2026-07-032

bc-init-template

AlexanderErdelyi/bc-alm-template

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.

2026-07-032

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.

BC · Ship a Pull Request

Turn a finished feature branch into a review-ready PR. Core procedure of the bc-pr agent.

1 — Read the spec

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.

2 — Build the changelog from commits

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

Features — feat: · Bug Fixes — fix: · Refactoring — refactor: · Performance — perf: · Chores — chore:/docs:/test:/style: · Other — the rest.
Extract every work-item id (#123 / AB#123) referenced across the commits.
Changelog-fragment cross-check (if the repo uses them): for any ticket id in the commits with no matching 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.

3 — Fetch work-item context

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).

4 — Compose the PR

Use ../../PULL_REQUEST_TEMPLATE.md.

Title: [ABC-{ID}] <short description matching the brief>
Work-item link: Closes AB#123 (Azure DevOps Boards) or Closes #123 (GitHub Issues) — match the backend the repo was initialized with.
Type of change: derive from the spec (Feature / Bug Fix / Hotfix / Refactor / Docs).
Changes summary: the grouped changelog from Step 2 (Features / Bug Fixes / Refactoring / …).
Related work items: the table from Step 3.
Affected AL Objects table — extract from 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

Build info: build status (from al_build), and git diff --shortstat (files changed, +insertions / −deletions).
Spec link: 📄 specs/<Area>/<type>-<ID>-<slug>/
Testing: reference acceptance-criteria.md and the test codeunit.
Deployment notes: any manual setup, config, or data migration.

5 — Run the quality checklist

Reuse bc-review-self and report each item ✅/❌. Items needing a build → "requires build verification".

6 — Confirm, then flag blockers

Output

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.

Next step

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).