Team (team-*)v1.0.3

team-eo-attr-logs-investigation

Investigate data inconsistencies between the employees table and attribute_logs table in the Personio Laravel monorepo

by Ayoub MazaView on GitHub ↗
attributesattribute-logsconsistency-checkeremployeesinvestigationeoemployee-organizationdatadogdata-access

Attribute Logs Investigation Plugin

Guide Claude through diagnosing inconsistencies between the employees table and the attribute_logs table in the Personio Laravel monorepo.

Owned by the Employee Organization (EO) team.

Installation

claude plugin install team-eo-attr-logs-investigation@personio-claude-code-marketplace

The data-access plugin is declared as a dependency and will be installed automatically.

Prerequisites

  • pup CLI installed and authenticated (pup auth status). Used to query Datadog logs and traces.
  • data-access CLI installed and authenticated. Used to query the monolith DB and the IDS (payroll-input-data-service).
  • A clone of the Personio monolith at ~/dev/personio (the skill reads source files from there when tracing code paths).
  • A Jira ticket number — required for any execute-read-query call.

What does this plugin do?

/inv-attribute-logs-inconsistency Skill

Walks Claude through a structured, multi-phase investigation of an inconsistency reported by the Personio consistency checker. Three inconsistency types are supported:

TypeMeaning
DIFFERENT_VALUESBoth the employee value and the log value exist, but differ
MISSING_PERSON_VALUEA log entry exists, but no current value on the employee
MISSING_ATTRIBUTE_LOGThe employee has a value, but no log entry exists

Two invocation modes:

# Mode 1 — specific employee + attribute
/inv-attribute-logs-inconsistency 15432595 weekly_working_hours ATTR-999

# Mode 2 — all inconsistencies for a date
/inv-attribute-logs-inconsistency 2026-04-16

What the skill does:

  1. Phase 0 — Consistency Checker. Queries the daily consistency-check job in Datadog to pull the checker's current diagnosis of the mismatch (including all root-cause flags and signals).
  2. Phase 1 — Confirm. Pulls the actual attribute_logs rows and the live employee record from the monolith DB and compares them directly.
  3. Phase 2 — Timing. Determines when the inconsistency was introduced so subsequent searches target the right time window.
  4. Phase 3 — Trigger. Searches Datadog for the user action, job, or approval that wrote the bad value.
  5. Phase 4 — hire_date side effect check. Queries the Integration Data Store (IDS) for attribute-log events to detect hire_date recalculation cascades.
  6. Phase 5 — Root cause match. Compares findings against 30+ known root causes documented in references/root-causes.md and the per-ticket references/tickets/ files.
  7. Phase 6 — Document. Summarises the timeline, trigger, and code path so the next person who hits the same pattern can recognise it immediately.
  8. Phase 7 — Report. Writes a self-contained HTML report with clickable Datadog links for every query run, ready to attach to a Jira ticket.

Known Root Causes

The plugin ships with detailed documentation of 30+ known inconsistency patterns (all ATTR-* tickets plus related DTV-, PET-, ORG-, EMP-, and EOFF- tickets). If the investigation matches a known pattern, Claude links to the existing Jira ticket; if not, the report includes a ready-to-paste Jira root-cause ticket template.

Authorization

  • Requires a Jira ticket for every data-access read query (quota applies).
  • Never runs execute-write-query or any write action without explicit user approval.
  • Never uses execute-cross-tenant-read-query (redacts PII — useless for investigations).