# Github Pr Issue Automation

> Standard operating procedures for automated PR/issue creation, auto-assignment, conventional label categorization, and professional GitHub markdown standards for AI agents and human contributors.

- Skill: `career-cafe/github-pr-issue-automation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add career-cafe/github-pr-issue-automation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/career-cafe/github-pr-issue-automation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Career-Cafe (https://skillmd.com/u/career-cafe)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/career-cafe/github-pr-issue-automation

---


# GitHub PR & Issue Visual Automation Skill

This skill defines the official standards for authoring structured, professional, and automated Pull Requests and Issues on GitHub, and operating the automated triage and label synchronization system.

---

## 1. Automated GitHub Actions Triage Pipeline

When any PR or issue is opened, the GitHub Actions triage automation executes automatically:

1. **Auto-Assignee**:
   - Assigns the Pull Request or Issue to the author (or `@me`) immediately upon creation.
2. **Conventional Type Labeling**:
   - Inspects the PR title prefix (`feat:`, `fix:`, `perf:`, `refactor:`, `docs:`, `db:`, `ci:`, `test:`, `ui:`) and automatically applies the matching color-coded `type/*` label.
3. **Subsystem / Area Labeling**:
   - Inspects modified files in the pull request:
     - `frontend/**`, `web/**`, `src/**` -> `area/frontend`
     - `backend/**`, `api/**`, `pkg/**` -> `area/backend`
     - `agent/**`, `ai-service/**` -> `area/ai-agent`
     - `worker/**`, `cmd/**` -> `area/worker`
     - `.github/**`, `scripts/**`, `Makefile` -> `area/ci-cd`
     - `docs/**`, `.agents/skills/**` -> `area/documentation`
4. **Automated Diff Size Classification**:
   - Computes total lines changed:
     - `< 50 lines` -> `size/XS`
     - `< 250 lines` -> `size/S`
     - `< 500 lines` -> `size/M`
     - `< 1000 lines` -> `size/L`
     - `1000+ lines` -> `size/XL`
5. **Lifecycle Status**:
   - Non-draft PRs receive `status/ready-for-review`; drafts receive `status/in-progress`.

---

## 2. CLI Standards for Agents: Opening Pull Requests

When instructed to open a Pull Request, agents must use `gh pr create` with explicit parameters:

```bash
gh pr create \
  --base main \
  --head <github-username>/<parent-branch>/<feature> \
  --title "<type>(<scope>): <concise imperative summary>" \
  --assignee "@me" \
  --label "type/<type>,area/<subsystem>,status/ready-for-review" \
  --body "..."
```

### Visual Formatting Checklist for PR Bodies
Every PR description generated by agents MUST include:
- **Executive Summary**: 2-3 concise sentences explaining the problem and resolution.
- **Conventional Type Checkbox**: Explicitly mark the type of change.
- **Subsystem Impact Table**: Markdown table displaying all affected services.
- **Quality Assurance Checklist**: Showing exact test commands executed (`make test`, `make pre-commit`).
- **Security Certification**: Affirming zero secrets or tokens committed.

---

## 3. Label Synchronization Engine

To synchronize or update the repository's color-coded labels, run:

```bash
# Preview labels without changes
./scripts/github-labels-sync.sh --dry-run

# Synchronize labels to GitHub
./scripts/github-labels-sync.sh
```

---

## 4. Modern Issue Forms

Issues are created through standardized YAML issue forms in `.github/ISSUE_TEMPLATE/`:
- `bug_report.yml`: Structured bug reproduction steps, environment, logs.
- `feature_request.yml`: Problem statement, target subsystem, architecture proposal.
- `task.yml`: Engineering task, acceptance criteria, test commands.

---

## 5. Required GitHub Actions Workflows in Every Repository

> [!IMPORTANT]
> **Every project repository MUST have the following three GitHub Actions workflow files** deployed under `.github/workflows/`. These are not optional — they are the automated operational backbone of the repository. When setting up a new repository or onboarding an existing one, verify all three exist before any other work.

### Canonical Workflow Checklist

| File | Purpose | Trigger |
| :--- | :--- | :--- |
| `pr-branch-cleanup.yml` | Auto-deletes remote feature branch when a PR is closed (merged or abandoned). Prevents stale branch buildup. | `pull_request: [closed]` |
| `jules-pr-review.yml` | Assigns `@google-labs-jules[bot]` as a reviewer on every non-draft PR. This triggers the Jules 38-dimension autonomous review loop. | `pull_request: [opened, synchronize, reopened]` |
| `ci.yml` | Runs the full test and build pipeline (gofmt, `go test -race`, `go build`, `go mod tidy`) as an enforced quality gate before merging. | `push` (any branch), `pull_request` (→ `main`) |

### Verification Command

To confirm all three workflows exist in a repository:

```bash
ls .github/workflows/
# Expected output includes:
#   ci.yml
#   jules-pr-review.yml
#   pr-branch-cleanup.yml
```

### Canonical References

- **`pr-branch-cleanup.yml`**: See `.agents/skills/git-post-merge-cleanup/SKILL.md` Section 4 for full YAML and safety details.
- **`jules-pr-review.yml`**: See `.agents/skills/jules-ai-engineering-workflow/SKILL.md` Section 5 for full YAML, Jules app installation, and draft PR behavior.
- **`ci.yml`**: See `.agents/skills/ci-cd-workflow/SKILL.md` Section 4 for DSA-specific CI job structure and local mirrors.

### Agent Responsibility

> [!IMPORTANT]
> When an AI agent sets up, scaffolds, or clones a repository, it MUST verify that all three workflows are present. If any are missing, the agent MUST create them immediately before committing any other code — these workflows are infrastructure, not a nice-to-have.