Team (team-*)v1.4.0

team-eo-common

Skills and tools for the Employee Organization (EO) team

by EO TeamView on GitHub ↗
eoemployee-organizationoperationscapscorrectnesstest-runnermigrationkotlin

team-eo-common

Skills and tools for the Employee Organization (EO) team at Personio.

Installation

claude plugin install team-eo-common@personio-claude-code-marketplace

What does this plugin do?

Claude Code skills and agents that apply across multiple EO teams — covering shared operational workflows including CAPS processes, EO-level operational reviews, correctness analysis, Firestation Manager tasks, and test execution.

Each skill names the domain, service, or workflow it applies to — see per-skill sections below as they are added.

eo-ops-review

Generates the weekly EO Operational Review report and publishes it to Confluence as a draft page. The report covers incidents, postmortem action items, correctness targets, API availability and latency SLOs, alerting health, open security vulnerabilities, and E2E test results.

What you need:

  • Atlassian MCP connected and authenticated (plugin:atlassian:atlassian)
  • Datadog MCP connected and authenticated (claude.ai Datadog)
  • Personio VPN active (required for the SDLC security metrics endpoint)
  • A Confluence account with write access to the EO space

Quick Start:

"Run the EO ops review"
"Generate the EO ops review for April 19 to April 25"
"Run the EO ops review for the last 14 days"

What it produces:

A Confluence draft page under the correct year/month folder in the EO Operational Review space, containing:

  1. Incidents & Postmortems — recent EO incidents from Confluence, plus all open postmortem action items grouped by project
  2. Correctness — a correctness targets tracking table (actual vs. monthly targets with prorata), bugs breaching TTR, and bugs breaching the 45-day age SLA
  3. Availability — global EO availability %, plus any API availability SLOs in breach
  4. Performance — backend gateway requests < 500ms and frontend LCP P75 / Loading Time P75 by team (period + MTD), plus API latency SLOs in breach
  5. Alerting Health — top 3 alerting monitors by volume
  6. Security — open CVEs for EO team repos from the SDLC security metrics endpoint
  7. E2E Tests — failing and flaky test counts per team for the last 24 hours

The page is created as a draft. Review it in Confluence and publish when ready.

eo-fsm-false-positive-detection

For EO Firestation Managers (FSMs) and Engineering Managers: fetches closed customer-reported bugs from the firefighter project scope (EMP, EOFF, ATTR, ORG, DM, WAC), classifies each ticket as a confirmed, likely, or possible false positive, and prompts you to apply the false_positive label to any that are missing it.

What you need:

  • The Atlassian MCP server connected and authenticated
  • A Personio Jira account with read access to the firefighter projects and write access to labels

Quick Start:

"Show me customer bugs closed as false positives in DM this month"
"Which tickets in ATTR were closed without a fix last quarter?"
"Find customer-reported bugs in ORG that weren't actually bugs"

Example:

You want to identify false positives from last week across all firefighter projects. The skill will:

  1. Query Jira for closed customer-reported bugs (Zendesk-linked or jira_escalated) in EMP, EOFF, ATTR, ORG, DM, WAC.
  2. Check each ticket for merged PRs (customfield_10700) — any ticket with a merged PR is a real fix and excluded.
  3. Classify the rest: Duplicate, Not a Bug, Invalid, Cannot Reproduce → confirmed/likely FP; Won't Do → flagged for human review; No issue → possible FP.
  4. Render an HTML report with colour-coded badges and clickable Jira links, grouped by project.
  5. List tickets missing the false_positive label and ask whether to apply it.

Why would you want this?

  • Keep labels in sync — the false_positive label is the canonical marker in Jira; this skill finds tickets that should have it but don't.
  • Merged PR guard — tickets with merged PRs are real fixes, not FPs. The skill checks this automatically so you don't mislabel genuine work.
  • Ambiguity surfaced, not hidden — "Won't Do" tickets are flagged for review rather than auto-labelled, because they can be either FPs or intentional non-fixes.

test-runner-haiku (agent)

Runs Gradle tests and reports results concisely using the Haiku model for cost-effective, high-throughput test execution. Use this agent proactively whenever you need to run Gradle tests or read test output.

What you need:

  • A Gradle-based project with ./gradlew available in the repository root

Quick Start:

"Run all tests"
"Run tests for the attribute module"
"Check what failed in the last test run"

Capabilities:

  • Run all tests, single-module tests, or individual test classes/methods via ./gradlew
  • Read HTML reports and XML test results for failure detail
  • Extract and summarize failures with error type and assertion/exception details
  • Report pass/fail/skip counts
  • Respects per-module test conventions (e.g. AssertJ-only in attribute-service)

Limitations:

  • Does NOT attempt to fix code or suggest changes — only runs and reports
  • Does NOT interpret failure causes beyond the error message
  • Relies on standard Gradle conventions for report locations

eo-migrate-to-golden-path

Migrates test libraries, mocking frameworks, or build dependencies across a multi-module Kotlin/Gradle codebase. Works one module at a time with ktlint and compilation gates before each commit, supports parallel sub-agent batches for large repos, and includes reference files for three common migrations:

MigrationReference
Mockito → MockKCovers strict-by-default pitfalls, value class matchers, relaxed mock rules, Spring/PACT edge cases
WireMock → MockKClassifies tests as Category A (replace with client mocks) vs Category B (keep WireMock)
Kotest → AssertJHandles assertions-only files (Category A), Spec-style rewrites (Category B), and shared Assertions.kt (Category C)

What you need:

  • A Gradle-based Kotlin project with ./gradlew available
  • ktlintFormat and compileTestKotlin tasks in the modules being migrated

Quick Start:

"Migrate Mockito to MockK across all modules"
"Migrate WireMock to MockK in the employment-service"
"Replace Kotest assertions with AssertJ in the attribute-service module"
"Continue the Mockito migration — pick up from where we left off"

How it works:

  1. Loads the relevant reference file for the target migration
  2. Checks git log to skip already-committed modules (safe to resume mid-flight)
  3. Applies replacements, runs ktlintFormat + compileTestKotlin, and commits each module
  4. For large codebases, spawns sub-agents in batches of 4 to cap context growth
  5. Opens draft PRs (one per module when diff > 400 lines, otherwise combined)
  6. Removes the old dependency from the version catalog and BOM once all modules are done

Contributing a skill to team-eo-common

Anyone on the EO team can add a skill to this plugin. To keep it coherent as it grows:

  • Prefix skill names with eo- to avoid collisions with other plugins' skills.
  • The skill's description frontmatter must name the domain, service, or workflow it applies to (e.g. "... for CAPS operational reviews", "... in the EO correctness checker"). This is what lets Claude route prompts correctly.
  • Add trigger and output evals under skills/<skill-name>/evals/ — see the evals README for format and thresholds.
  • Declare any new dependencies (e.g. data-access) in .claude-plugin/plugin.json if the skill needs them.