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:
- Auto-Assignee:
- Assigns the Pull Request or Issue to the author (or
@me) immediately upon creation.
- 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.
- Subsystem / Area Labeling:
- Inspects modified files in the pull request:
frontend/**, web/**, src/** -> area/frontendbackend/**, api/**, pkg/** -> area/backendagent/**, ai-service/** -> area/ai-agentworker/**, cmd/** -> area/worker.github/**, scripts/**, Makefile -> area/ci-cddocs/**, .agents/skills/** -> area/documentation
- Automated Diff Size Classification:
- Computes total lines changed:
< 50 lines -> size/XS< 250 lines -> size/S< 500 lines -> size/M< 1000 lines -> size/L1000+ lines -> size/XL
- 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:
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:
# 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:
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.
1---2name: github-pr-issue-automation3description: Standard operating procedures for automated PR/issue creation, auto-assignment, conventional label categorization, and professional GitHub markdown standards for AI agents and human contributors.4---56# GitHub PR & Issue Visual Automation Skill78This 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.910---1112## 1. Automated GitHub Actions Triage Pipeline1314When any PR or issue is opened, the GitHub Actions triage automation executes automatically:15161. **Auto-Assignee**:17 - Assigns the Pull Request or Issue to the author (or `@me`) immediately upon creation.182. **Conventional Type Labeling**:19 - Inspects the PR title prefix (`feat:`, `fix:`, `perf:`, `refactor:`, `docs:`, `db:`, `ci:`, `test:`, `ui:`) and automatically applies the matching color-coded `type/*` label.203. **Subsystem / Area Labeling**:21 - Inspects modified files in the pull request:22 - `frontend/**`, `web/**`, `src/**` -> `area/frontend`23 - `backend/**`, `api/**`, `pkg/**` -> `area/backend`24 - `agent/**`, `ai-service/**` -> `area/ai-agent`25 - `worker/**`, `cmd/**` -> `area/worker`26 - `.github/**`, `scripts/**`, `Makefile` -> `area/ci-cd`27 - `docs/**`, `.agents/skills/**` -> `area/documentation`284. **Automated Diff Size Classification**:29 - Computes total lines changed:30 - `< 50 lines` -> `size/XS`31 - `< 250 lines` -> `size/S`32 - `< 500 lines` -> `size/M`33 - `< 1000 lines` -> `size/L`34 - `1000+ lines` -> `size/XL`355. **Lifecycle Status**:36 - Non-draft PRs receive `status/ready-for-review`; drafts receive `status/in-progress`.3738---3940## 2. CLI Standards for Agents: Opening Pull Requests4142When instructed to open a Pull Request, agents must use `gh pr create` with explicit parameters:4344```bash45gh pr create \46 --base main \47 --head <github-username>/<parent-branch>/<feature> \48 --title "<type>(<scope>): <concise imperative summary>" \49 --assignee "@me" \50 --label "type/<type>,area/<subsystem>,status/ready-for-review" \51 --body "..."52```5354### Visual Formatting Checklist for PR Bodies55Every PR description generated by agents MUST include:56- **Executive Summary**: 2-3 concise sentences explaining the problem and resolution.57- **Conventional Type Checkbox**: Explicitly mark the type of change.58- **Subsystem Impact Table**: Markdown table displaying all affected services.59- **Quality Assurance Checklist**: Showing exact test commands executed (`make test`, `make pre-commit`).60- **Security Certification**: Affirming zero secrets or tokens committed.6162---6364## 3. Label Synchronization Engine6566To synchronize or update the repository's color-coded labels, run:6768```bash69# Preview labels without changes70./scripts/github-labels-sync.sh --dry-run7172# Synchronize labels to GitHub73./scripts/github-labels-sync.sh74```7576---7778## 4. Modern Issue Forms7980Issues are created through standardized YAML issue forms in `.github/ISSUE_TEMPLATE/`:81- `bug_report.yml`: Structured bug reproduction steps, environment, logs.82- `feature_request.yml`: Problem statement, target subsystem, architecture proposal.83- `task.yml`: Engineering task, acceptance criteria, test commands.8485---8687## 5. Required GitHub Actions Workflows in Every Repository8889> [!IMPORTANT]90> **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.9192### Canonical Workflow Checklist9394| File | Purpose | Trigger |95| :--- | :--- | :--- |96| `pr-branch-cleanup.yml` | Auto-deletes remote feature branch when a PR is closed (merged or abandoned). Prevents stale branch buildup. | `pull_request: [closed]` |97| `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]` |98| `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`) |99100### Verification Command101102To confirm all three workflows exist in a repository:103104```bash105ls .github/workflows/106# Expected output includes:107# ci.yml108# jules-pr-review.yml109# pr-branch-cleanup.yml110```111112### Canonical References113114- **`pr-branch-cleanup.yml`**: See `.agents/skills/git-post-merge-cleanup/SKILL.md` Section 4 for full YAML and safety details.115- **`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.116- **`ci.yml`**: See `.agents/skills/ci-cd-workflow/SKILL.md` Section 4 for DSA-specific CI job structure and local mirrors.117118### Agent Responsibility119120> [!IMPORTANT]121> 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.122
Career-Cafe