feature-branch-pr-writing

name	feature-branch-pr-writing
version	1.6.6
model	sonnet
description	Use this skill when the user asks to write, draft, create, or improve a PR description for a Shopware core repository PR — AND that PR targets a non-trunk feature branch (not trunk itself). Trigger phrases like "write a PR description", "draft the PR", "what should I put in the PR body". The skill detects the target branch and only activates for non-trunk targets; for trunk-targeting PRs, use pr-description-writing instead. Do NOT activate mid-implementation — only when the user is ready to describe finished changes. Produces a conventional-commit title and a narrative-prose description with topical subsections, leveraging the diff against the target branch and any related PRs in the chain.
allowed-tools	Read, Grep, Glob, Bash, AskUserQuestion

Feature-Branch PR Description Drafting

Draft a PR title (conventional commit format) and description (narrative prose with topical subsections) for PRs targeting non-trunk feature branches. Analyzes the diff against the target branch, detects related PRs in the chain, and asks targeted questions for missing context.

Output scope: Presents formatted title + description text. Does not create or update PRs on GitHub. Does not write to any files.

Phase 1 — Assess Branch State

Determine what we're working with: branch, target, PR status, diff, and chain.

1. Load references/branch-and-pr-detection.md and execute Steps 1-4. Route as feature-branch-pr-writing.
2. Get the diff:
   • If a PR exists: read its diff and changed files from GitHub (a GitHub MCP server, the gh CLI, or the API — whatever the session has)
   • If no PR: run git diff <target>...HEAD --stat and git log <target>..HEAD --oneline
3. Chain detection: list PRs targeting the same feature branch (via the same GitHub access). Record titles, numbers, merge state, and any cross-references in bodies. Identify predecessor/successor relationships.
4. Present a brief assessment to the user: branch name, target branch, PR status (exists / doesn't exist / has existing description), change magnitude (files touched, lines changed, areas affected), related PRs in the chain.

Phase 2 — Analyze Changes

Understand the full story of the branch relative to the target.

1. Synthesize the full branch scope from the diff, commits, and file changes. Understand the totality: features, fixes, cleanups, refactors.
2. Determine scope: map file paths to Shopware areas. This informs the conventional commit scope for the title.

File path pattern	Scope
src/Core/Checkout/Cart/	cart
src/Core/Checkout/Order/	order
src/Core/Checkout/Promotion/	promotion
src/Core/Content/Product/	product
src/Core/Content/Media/	media
src/Core/Content/Category/	category
src/Core/Content/Cms/	cms
src/Core/Content/Mail/	mail
src/Core/Framework/DataAbstractionLayer/	dal
src/Core/Framework/App/	app-system
src/Core/System/SystemConfig/	system-config
src/Core/System/NumberRange/	number-range
src/Storefront/	storefront
src/Administration/	admin
src/Elasticsearch/	elasticsearch

For changes spanning multiple areas, use the scope of the primary story. If no specific scope fits, omit the parenthetical scope entirely: fix: description.

3. Identify narrative candidates. A branch often contains multiple threads. Present them to the user:

   "This branch contains: (a) ..., (b) .... What's the primary story?"

4. The user confirms or reframes the story. This drives the title's type/scope and which aspects get depth vs. a brief mention.
5. Assess description depth based on the confirmed story's complexity.
6. Leverage session context: if the user has been debugging, implementing, or discussing in the current session, use that knowledge. Don't re-ask what's already known.

Phase 3 — Gather Context

Fill the gaps. Ask targeted questions only for information not in the diff, chain detection, or session context.

1. Inventory what's known from the diff, chain, and session:
   • Why the change was made (motivation)
   • What changed (from diff)
   • Which prior PRs established the pattern
   • Related PRs (blocked by, follows, follow-up)
   • Design alternatives considered
   • Trade-offs or limitations
   • Tracking issue
2. Ask only what's missing, one question at a time:
   • "What triggered this change?"
   • "Which prior PR established the pattern being followed?"
   • "Are there PRs blocked by this one?"
   • "Were there design alternatives you considered and rejected?"
   • "Should reviewers know about any deliberate trade-offs or limitations?"
   • "Is there a tracking issue for this feature?"
3. Skip questions the session already answers. If the user has been working on this and the session contains motivation, design decisions, and chain context, go straight to drafting.
4. Load references/writing-rules.md to internalize style constraints and anti-slop rules.

Phase 4 — Draft

Generate the conventional commit title and narrative description.

1. Load references/description-examples.md for sizing calibration
2. Generate the title: <type>(<scope>): <description>

Type	When to use
fix	Bug fix
feat	New feature or capability
refactor	Code restructuring with no behavioral change
perf	Performance improvement
chore	Maintenance, dependency updates, tooling
docs	Documentation only
test	Test additions or corrections
style	Code style (formatting, semicolons, etc.)

Title description rules: imperative mood, lowercase first letter, no period, under ~60 characters after type/scope. Describe the behavioral change, not the implementation.

3. Draft the description:
   • Opening context paragraph: state the prior situation, what this PR does about it, and reference predecessor PRs in the chain when applicable.
   • Topical ### subsections: each covers one concern or aspect of the change. Choose headers based on what the PR actually does, not from a fixed list. Good: "Event-based type override", "DI decentralization". Bad: "Changes", "What changed", "Updates".
   • Tables for structured mappings (file moves, new classes with locations, config key changes, loader-to-route delegations).
   • ## References section at the end with cross-references: Ref #issue, Blocked by #PR, Follows #PR, Follow-up: #PR. Never use closes or fixes.
4. Self-check each subsection: state in one sentence what contract it describes (what goes in, what comes out, why it exists). If you can't collapse the subsection to one contract-level sentence, it's restating the diff. Rewrite.
5. Diagram reasoning (two steps):
   • Would the reviewer understand this better by seeing it than reading about it? If no, skip.
   • If yes: can it fit one focused diagram, or should it split by concern? A single diagram that tries to show everything is as hard to follow as the prose it replaced.
6. Scale length to complexity:
   • Small (~2 paragraphs, 2 subsections): single-concern refactors, review feedback fixes.
   • Medium (~3 paragraphs, 3-4 subsections, tables): multi-file features following established patterns, structural moves.
   • Large (~6+ paragraphs, 6+ subsections, tables, potentially diagrams): new subsystems with multiple integration points.
   • Determine the tier from the story's complexity, not the diff size.
7. Present the full draft to the user: title clearly labeled, then the description formatted as GitHub markdown

Phase 5 — Validate and Present

Verify the draft against anti-slop rules, then deliver.

1. Anti-slop validation pass — load references/writing-rules.md, then check the draft literally (not from memory):
   • First: search the draft text for em dash (—) and en dash (–) characters. Remove every instance. This is the most common violation and must be checked first as a literal character search, not a mental scan.
   • Second: for each subsection, verify it states a contract, not implementation steps. If a paragraph walks through method internals a reviewer will see in the diff, compress to contract level.
   • Then re-read each sentence against: banned vocabulary, banned sentence patterns, banned formats, colon/semicolon overuse, sentence rhythm, tone
   • If any violations found, rewrite the affected sentences and re-check the rewritten sentences
2. Output the title — clearly labeled, in conventional commit format
3. Output the description — as GitHub-rendered markdown (no hard line wraps, let lines run to natural length)
4. Flag any assumptions: inferred chain relationships, guessed issue numbers, trade-off decisions the user should verify
5. If the user wants changes, revise and present again
6. Do not create PRs, update PRs, or write to any files. The user takes the output and uses it as they see fit.

Boundaries

• Never create or update PRs on GitHub
• Never write to any files
• Never auto-commit
• Only present formatted text output for the user to use
• Works on feature branches targeting non-trunk branches only