personio-github

Personio GitHub conventions, gh CLI operations, org code search, draft PR creation, and CI failure analysis — the single home for working with GitHub at Personio.

Installation

claude plugin install personio-github@personio-claude-code-marketplace

What does this plugin do?

It gives Claude the Personio GitHub baseline — the Personio-Internal org, the ~/dev/<repo> checkout convention, where shared workflow code lives, and where the docs are — plus the everyday tooling to act on GitHub via the gh CLI, search code across the org, and open draft PRs that follow each repo's own commit/ticket convention.

gh-cli

Drive GitHub from the gh CLI — inspect PRs (checks/diff/list), CI runs, issues, releases. Prefers gh over any GitHub MCP when both exist, and scopes to Personio-Internal. Also carries Personio's GitHub baseline conventions: the Personio-Internal org, the ~/dev/<repo> checkout convention, shared workflow code in Personio-Internal/github, and docs in TechDocs (via the personio-mcp-server MCP).

What you need

• The gh CLI installed and authenticated (gh auth status; gh auth login if not).
• Optional: the Personio TechDocs MCP (personio-mcp-server) for the docs answers — otherwise it points you at the install step.

Quick Start

"Use gh to check the CI status of PR 412 in payroll-service"
"List my open PRs in data-registry"
"What's our GitHub org and where do repos get cloned?"

Example

"Fetch the logs for CI run 12345" → gh run view 12345 --log. For why a run failed (root cause + fix), use the ci-failure-analysis skill (in this plugin).

"I need the personio-web repo locally" → Claude checks ~/dev/personio-web, and if it's missing, offers to gh repo clone Personio-Internal/personio-web ~/dev/personio-web (with your consent) rather than guessing a path.

Why would you want this?

• gh operations scoped to Personio-Internal and routed correctly (search/PR/CI go to the right skill).
• Picks gh over a GitHub MCP when both exist — the supported, lower-overhead path.
• Consistent answers to "what's the org / where's the repo / where are the docs" without web guessing; the ~/dev/<repo> convention resolved so other skills find local checkouts.

github-code-search

Search code across every Personio-Internal repo with gh search code (always --owner=Personio-Internal).

What you need

• The gh CLI installed and authenticated.

Quick Start

"Find all repos with a .mcp.json"
"Search the org for @GetMapping in Kotlin"

Example

"Which repos depend on personio-cdk-core?" → gh search code "personio-cdk-core" --owner=Personio-Internal --filename=build.gradle.kts. Note: GitHub's code index is eventually consistent, so an empty result isn't proof — confirm against a local clone.

Why would you want this?

• One query spans the whole org instead of cloning repo after repo.
• Org scoping and the special-char/-- gotchas handled for you.

create-pr

Open draft PRs that follow the repo's own convention. It resolves the repo's commit-message + JIRA-ticket-placement convention (documented in the repo's CLAUDE.md), asks for a JIRA ticket if none was mentioned (optional — skipping is fine), then pushes and opens the PR.

Pancake-aware: on a pancake stacked-diffs branch it submits via pk submit (draft) instead of raw git/gh, so the PR stays within the stack with the correct base.

What you need

• The gh CLI installed and authenticated, and a branch with changes to submit.
• Optional: pancake (pk) for stacked diffs.

Quick Start

"Create a PR for my changes"
"Push and open a pull request for the auth refactoring"

Example

"Create a PR for my changes" on a normal branch → resolves the commit convention, asks for an optional JIRA ticket, commits, pushes, and opens a draft PR, ending with PR created: <URL>. On a pancake-tracked branch it runs pk submit (draft) instead.

How the commit convention is resolved

The convention lives in the repo's CLAUDE.md — already auto-loaded into context, version-controlled, and team-shared. create-pr reads it directly; on repeat PRs there's no lookup and no agent dispatch.

When CLAUDE.md doesn't document one yet, create-pr delegates a one-time detection to the read-only commit-convention-detector agent (keeping the file-scan out of the main conversation). The agent inspects repo signals — commit template, PR template, CONTRIBUTING.md/CLAUDE.md, recent git log (and commitlint/Husky in JS repos) — and returns a compact verdict, falling back to Conventional Commits when nothing is found. With your consent it then writes a small managed block into the existing CLAUDE.md:

<!-- personio-github:commit-convention (auto-managed; edit or delete to change) -->
## Commit convention
- Format: …
- Ticket commit footer: `Refs: KEY-N` (or `none`)
- Ticket PR-title prefix: `[KEY-N] ` (or `none`)
<!-- /personio-github:commit-convention -->

It never creates a CLAUDE.md where none exists (it just detects ephemerally for that PR). Refresh by editing or deleting that block, or asking Claude to re-detect.

Why would you want this?

• Always-draft PRs that respect each repo's commit/ticket style instead of forcing one format.
• Works with both plain git and pancake stacks — no broken stack bases.
• The convention is detected once and documented in CLAUDE.md, so later PRs are instant.

github-actions

Explains how Personio's GitHub Actions CI/CD is set up: shared composite actions and reusable workflows from Personio-Internal/github, safe-settings governance, merge queue, ArgoCD deployments + E2E gates, self-hosted runners, and the external-action allowlist. Also applies Personio conventions when you're reading or editing files under .github/**.

What you need

• The personio-mcp-server MCP for live, current-catalog detail (dispatches the cicd-docs-researcher agent to search TechDocs on demand). If the MCP is unreachable, the skill answers from its durable built-in model and points at personio-common:install-personio-mcp-desktop.

Quick Start

"How do deployments work for Kotlin services at Personio?"
"What reusable workflows can I use for a Kotlin service?"
"How is the merge queue configured here?"
"I'm editing .github/workflows/ci.yml — which runner label should I use?"

Example

"How is the merge queue set up?" → explains safe-settings policy-as-code in Personio-Internal/github, the rulesets entry needed in .github/repos/<repo>.yml, and the merge_group trigger that workflows must declare. Dispatches cicd-docs-researcher for the current how-to page from TechDocs.

Why would you want this?

• Correct Personio CI/CD conventions applied while you author .github/** files — right runner, right trigger, right shared action reference — without manually consulting docs.
• On-demand TechDocs research (via cicd-docs-researcher) for current detail, with a durable offline model as fallback when the MCP is unavailable.

ci-failure-analysis

Diagnoses why CI failed on a PR. Fetches the failing checks and their logs, analyzes the failure (test / build / lint / infrastructure), correlates it with the PR diff, and proposes concrete fixes referencing specific files. Runs on a read-only gh allowlist — it inspects, it doesn't mutate.

What you need

• The gh CLI installed and authenticated (gh auth status).
• A PR number (or a PR URL) with at least one failing check.

Quick Start

"CI is failing on my PR #245, what's wrong?"
"Why is CI red on https://github.com/Personio-Internal/<repo>/pull/55?"
"The lint check keeps failing on PR #88"

Example

"All checks are red after my push, PR #312" → runs gh pr checks 312, pulls the failed job logs with gh run view <id> --log-failed, correlates against gh pr diff 312, then reports each failure with its root cause, the file/line, and a concrete fix — flaky/infra failures called out separately from code failures.

Why would you want this?

• Goes straight from "CI is red" to a root-caused, file-specific fix instead of generic advice.
• Read-only by construction — fetches logs and diffs, never changes the PR or re-runs jobs on its own.
• Distinguishes code failures from flaky/infrastructure failures, so you don't "fix" a runner timeout.