---
name: compose-pr
description: Composes a ready-to-copy Pull Request title and description based on the current branch changes compared to the remote base branch. Does not create the actual Pull Request.
---

# /compose-pr

You are a PR content assistant. You do not create PRs, only compose them so a person or an agent can create them using the outputs. You must output: PR title, PR body, PR base branch, PR tribe label and an optional PR flow label.

When this command is triggered, execute these steps **in order**.

---

## Step 1 — Detect the base branch

```bash
git branch -r | grep -E 'origin/(develop|main|master)' | head -5
```

Use `origin/develop` if it exists, otherwise fall back to `origin/main` or `origin/master`.

---

## Step 2 — Get the current branch and Jira Ticket ID

```bash
git branch --show-current
```

Try to extract a Jira Ticket ID from the branch name:
- `feature/SQ-123-some-description` → `SQ-123`
- `fix/SQ-456-some-fix` → `SQ-456`

---

## Step 3 — Collect the diff against the remote base branch

```bash
git fetch origin <BASE_BRANCH> && git diff origin/<BASE_BRANCH>...HEAD --stat && git log origin/<BASE_BRANCH>...HEAD --oneline
```

Identify which files changed and which modules are affected by mapping paths under `src/pages/dashboard/*` to their module name.

**If the branch has no commits ahead of the base**, stop and inform the user.

---

## Step 4 — Format outputs

Using the diff and commit messages from Steps 1–3, prepare the following outputs. **Do not** show the final copy/paste output until **Step 5**.

### PR Title

Format: `type(scope): [Jira Ticket ID] description`

- **type**: The kind of change being made. Must be one of:
  - `feat` – a new feature
  - `fix` – a bug fix
  - `chore` – maintenance tasks (deps, config, tooling)
  - `refactor` – code change that neither fixes a bug nor adds a feature
  - `perf` – performance improvements
  - `docs` – documentation only changes
  - `test` – adding or updating tests
  - `ci` – CI/CD changes
- **scope**: The main affected module or technical area (e.g., `chats`, `learning`, `goals`, `apps`, `files`). Maps to folders inside `src/pages/dashboard/*`. Use `tech` for cross-project changes.
- **description**: Short, imperative sentence. Lowercase. No period at the end.

**Examples:**

- `fix(chats): [SQDP-3627] resolve message pagination on slow connections`
- `feat(learning): [SQDP-3627] add certificate download feature`
- `fix(goals): [SQDP-3627] handle validation error on empty submission`
- `chore(tech): [SQDP-3627] upgrade core dependencies to latest versions`
- `refactor(files): [SQDP-3627] extract file preview into reusable component`
- `perf(apps): [SQDP-3627] lazy-load app list to reduce initial render time`

### PR Description

Output the full markdown body with:
- **Summary** auto-filled from the diff and commit messages, **formatted with markdown, not raw paragraphs**. Start with one short introductory sentence. Use **bullets** for each distinct change or area (e.g. new files, commands, config). Use **bold** for labels/names (e.g. file names, command names, module names). Keep it scannable: 2–6 bullet points preferred over a single long paragraph. Stay factual and concise; no invention.
- **Screenshots, GIFs or Videos**: Keep this section **exactly** as in the template — a single line, the HTML comment only: `<!-- Add screenshots or videos of the views you modified -->`.
- **Jira Card** pre-filled with the ticket from Step 2 (or left as placeholder if none found)
- **Flow** mark the correct checkbox

```markdown
## Summary

<auto-filled: short intro if needed, then bullet list with **bold** terms where helpful including features, bug fixes, improvements, and other relevant information>

## Screenshots, GIFs or Videos

<!-- Add screenshots or videos of the views you modified -->

## Jira Card

[Jira Ticket ID](https://humand.atlassian.net/browse/JiraTicketID)

## Flow

<!-- Taken from the ticket's Flow field -->
- [ ] Regular
- [ ] Hotfix
- [ ] Bugfix

## Additional Context (optional)

<!-- Add any other relevant information here -->
```

### Labels

In this repo, the **tribe label** (the GitHub label for tribe) identifies the team who owns the Jira ticket and the work in the PR. It answers "**who** owns this?", not "**what type** of change is it?". Do **not** infer the tribe from the diff alone.

- If the user or the ticket context names the tribe, use the matching label. You can search [this json](./pr-tribe-by-ticket.json) by JiraTicketID.
- Otherwise **ask the user** which tribe owns the ticket — do **not** guess.

1. **Tribe label (required — exactly one):**
   - `talent`
   - `comm`
   - `data`
   - `ops`
   - `people foundation`
   - `time management`

2. **Flow label (optional — leave empty if Regular flow):**
   - Bugfix → `stg fix`
   - Hotfix → `hot fix`
   - Regular flow → no additional label.


---

## Step 5 — Output everything

1. **PR Title** — fenced code block with the final title line.
2. **PR Description** — fenced `markdown` block with the full body as composed in Step 4.
3. **PR base branch** — fenced block with the short branch name only (no `origin/` prefix), e.g. `develop`.
4. **PR tribe label** — fenced block with the tribe label only.
5. **PR flow label** — fenced block with the optional flow label.

## Rules

- Always run the git commands before generating any output.
- Never make up file changes — only summarize what the diff actually shows.
- Format the Summary with markdown: use bullet lists and **bold** for key names; avoid a single long raw paragraph.
- Keep the Summary factual and concise — 2 to 6 bullet points (or equivalent) max.
- If multiple modules are affected, use the most impacted one as the scope, or `tech` for broad changes.
- Step 5 must output all five parts (items 1–5) together in one response, as specified in **Step 5 — Output everything**.
- Do NOT create the PR. Only output markdown.
- The **PR tribe label** must match the owning tribe for the ticket; if unknown, ask the user — never infer it from paths or change type alone.