pr-summary
- Repo stars 2
- License Apache-2.0
- Author repo ai-dev
PR Summary
This skill generates a structured summary of all changes on the current branch relative to a base branch (default: master).
Workflow
1. Gather branch context
git branch --show-current
git log master..HEAD --oneline
git diff master...HEAD --stat
git log master..HEAD --format="%s%n%b"
If the user supplied a different base branch as an argument, substitute it for master.
Extract the work item number from the branch name (first run of 4+ digits):
| Branch | Work item |
|---|---|
feature/12345-add-foo |
12345 |
feedback/58340/from-luke |
58340 |
JTD-56566-missing-screen |
56566 |
docs/59478 |
59478 |
2. Analyse the changes
Group changes into logical themes by reading the commit messages and diff stat. Common themes for this project:
- New features — new screens, controls, device integrations, service bus consumers
- Bug fixes — correctness fixes (mention what was wrong and what was corrected)
- Renames / breaking changes — entity or contract renames, API changes
- Service bus / messaging — MassTransit consumers, message contracts, RabbitMQ configuration
- Device integration — RFID, camera, BlackMoth, or other device changes
- UI changes — WPF views, XAML resources, InTruck or Console screens
- Dead code removal — deleted files, unused services, obsolete utilities
- Tooling / config — CLAUDE.md, skills, CI, migrations, feature flags
3. Produce the title and description
Title — one line following the project's PR title format: JTD <work-item> - Brief description
- Use the work item number extracted from the branch name
- Brief description: imperative, ≤ 70 characters total
- Example:
JTD 58106 - Handle missing RORO bin weights using tipping records
Output the title first in a code block, then the description below it.
Description — output the entire description inside a single fenced markdown code block (```markdown) so the user can copy-paste it directly into Azure DevOps. Use this structure inside the block:
```markdown
## Description — Work Item #<id>
### <Theme 1 — e.g. "New Feature: Trailer Management Screen">
- Bullet describing the change. Mention affected components (InTruck, Console, ServiceBus, Shared, Devices) where relevant.
### <Theme 2>
- ...
### Bug Fixes
- **<Short label>** — what was wrong and what was changed to fix it.
### Dead Code / Cleanup
- List deleted files or removed abstractions with a one-line rationale.
### Tooling & Config
- Any non-code changes (CLAUDE.md, skills, CI, feature flags).
---
**Files changed:** X | **Insertions:** +Y | **Deletions:** -Z
```
Rules:
- Use
###headings for each theme; omit sections that have no relevant changes. - Keep bullets concise — one sentence per item, no padding.
- Always include the
Work Item #<id>in the description heading. - Always include the files/insertions/deletions line at the bottom (read from
git diff --statsummary line). - If the branch has zero commits ahead of master, say so and exit.
- The entire description (everything inside the markdown code block) must not exceed 3500 characters. If the draft exceeds this limit, shorten bullets — summarise groups of related changes into a single bullet, drop minor cleanup items, and abbreviate file lists — until it fits. Never truncate mid-sentence; always produce complete, grammatical bullets.
4. Offer next steps
After the summary, ask if the user wants to:
- Create the PR now (
gh pr create) using the summary as the body - Review the changes first (
/code-review) - Adjust any section of the summary
- Fluxly category
- Engineering
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 94 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @LLM-Dev-Studio · Apache-2.0
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Plug-and-play
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Unspecified
- Detected file/system behavior
-
- Read-only
- Write / modify
- Detected network behavior
- Local-only
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. Workflow
If the user supplied a different base branch as an argument, substitute it for master. Extract the work item number from the branch name (first run of 4+ digits): Branch · Work item
Group changes into logical themes by reading the commit messages and diff stat. Common themes for this project: New features — new screens, controls, device integrations, service bus consumers Bug fixes — correctness fixes (mention what was wrong and what was…
Title — one line following the project's PR title format: JTD <work-item> - Brief description Use the work item number extracted from the branch name Brief description: imperative, ≤ 70 characters total
Description — Work Item <id>
Bullet describing the change. Mention affected components (InTruck, Console, ServiceBus, Shared, Devices) where relevant.
# PR Summary
This skill generates a structured summary of all changes on the current branch relative to a base branch (default: `master`).
## Workflow
### 1. Gather branch context
```bash
git branch --show-current
git log master..HEAD --oneline
git diff master...HEAD --stat
git log master..HEAD --format="%s%n%b"
```
If the user supplied a different base branch as an argument, substitute it for `master`.
Extract the **work item number** from the branch name (first run of 4+ digits):
| Branch | Work item |
|---|---|
| `feature/12345-add-foo` | `12345` |
| `feedback/58340/from-luke` | `58340` |
| `JTD-56566-missing-screen` | `56566` |
| `docs/59478` | `59478` |
### 2. Analyse the changes
Group changes into logical themes by reading the commit messages and diff stat. Common themes for this project:
- **New features** — new screens, controls, device integrations, service bus consumers
- **Bug fixes** — correctness fixes (mention what was wrong and what was corrected)
- **Renames / breaking changes** — entity or contract renames, API changes
- **Service bus / messaging** — MassTransit consumers, message contracts, RabbitMQ configuration
- **Device integration** — RFID, camera, BlackMoth, or other device changes
- **UI changes** — WPF views, XAML resources, InTruck or Console screens
- **Dead code removal** — deleted files, unused services, obsolete utilities
- **Tooling / config** — CLAUDE.md, skills, CI, migrations, feature flags
### 3. Produce the title and description
**Title** — one line following the project's PR title format: `JTD <work-item> - Brief description`
- Use the work item number extracted from the branch name
- Brief description: imperative, ≤ 70 characters total
- Example: `JTD 58106 - Handle missing RORO bin weights using tipping records`
… Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Workflow → 1. Gather branch context → 2. Analyse the changes → 3. Produce the title and description → Description — Work Item <id> → <Theme 1 — e.g. "New Feature: Trailer Management Screen">
terms -> work item number · New features · Bug fixes · Renames / breaking changes · Service bus / messaging · Device integration · UI changes · Dead code removal
files/cmd -> master · feature/12345-add-foo · 12345 · feedback/58340/from-luke · 58340 · JTD-56566-missing-screen · 56566 · docs/59478
body sha256 -> f68ac7010cb9
Decide Fit First
Design Intent
How To Use It
Boundaries And Review