team-money

Skills and tools for the Money team at Personio.

Installation

claude plugin install team-money@personio-claude-code-marketplace

What does this plugin do?

A home for Claude Code skills contributed by the Money team. Each skill names the repo, service, or product area it applies to — open any SKILL.md or read the per-skill sections below to see the scope.

money-new-gofer

Walks you through creating a new sealed GraphQL operation and the matching generated hooks, types, mocks, and handlers in the compensation-management area of personio-web.

What you need:

• Both personio-web and data-registry repos cloned locally
• Backend API deployed in dev
• The ./fml CLI available in personio-web

Quick Start:

"Walk me through adding a new sealed query for the salary tab"

Example:

You want a new query that returns an employee's salary history. The skill will:

1. Direct you to prototype the operation in GraphiQL (Dev).
2. Tell you the exact data-registry path: src/graphql/queries/compensation-management/<OperationName>.query.
3. Run ./fml generate -sop <absolute-path> from personio-web to generate the hook, types, mocks, and handlers.
4. Remind you that two PRs are needed — one in data-registry, one in personio-web — and that sealed operations are immutable once deployed.

Why would you want this?

• Skip the documentation hunt — every step, path, and constraint pre-loaded in one place.
• Avoid the legacy trap — the skill steers you away from data/graphql/ (old manual codegen).
• Fewer review round-trips — the two-PR flow and immutability constraint are surfaced upfront.

money-routing

Client-side routing and navigation for compensation-management routes in personio-web. Covers navigation hooks, search params, and the whiteListedRoutes.ts gotcha when adding new orchestrator routes.

What you need:

• Running from the personio-web repo
• Access to libs/orchestrator-common/src/hooks/whiteListedRoutes.ts when adding new routes

Quick Start:

"I'm adding a new orchestrator route under /compensation/reports — what do I need to know?"

Example:

You add a new route and everything works when you visit it directly, but SPA navigation from another page triggers a full reload. The skill immediately points to whiteListedRoutes.ts as the fix, and tells you which navigation hook package serves your route (compensation-management/hooks/routing/ for /salary/employee-salary/*, etc.).

Why would you want this?

• Stop forgetting whiteListedRoutes.ts — the single most common Money-team routing bug, pre-flagged every time.
• Hook-package map at a glance — no more guessing whether navigation logic belongs in hooks/navigation/, hooks/routing/, or hooks/settings-compensation-types-navigation/.
• Orchestrator authoring rules linked — .cursor/rules/orchestrator.mdc is surfaced so you don't miss FederatedLoader/PersonioPage conventions.

money-unit-test-context

Pre-loads compensation-management-specific unit testing context: translation namespaces constant, gofer handler/mock paths (generated + custom), and canonical example files to copy patterns from.

What you need:

• Running from the personio-web repo
• Familiarity with MSW, renderWithWrapper, and Testing Library

Quick Start:

"Write a unit test for my new compensation-management form that calls a gofer mutation"

Example:

You need a test for a form + mutation. The skill tells you:

• Read .cursor/rules/testing.mdc and .cursor/rules/testing-with-apis.mdc first.
• Use COMPENSATION_MANAGEMENT_TRANSLATION_NAMESPACES (don't list namespaces by hand).
• Copy the pattern from features/extra-pay-form/src/__tests__/ExtraPayForm.test.tsx.
• Override a handler with server.use(...) from @personio-web/compensation-management-gofer/test-utils when testing error flows.

Why would you want this?

• Zero pattern-discovery — canonical examples for form+mutation, complex rendering, and hook tests are named upfront.
• No translation-setup flakiness — the shared namespaces constant prevents missing-key test failures.
• Handlers and mocks mapped — generated vs custom, gofer vs legacy data/graphql/ — all the right paths.

money-pre-pr-review

Pre-PR self-review for Money team changes. Runs a four-principle behavioural check on your staged/committed diff (scope, simplicity, surgical changes, goal-driven) and flags what a human reviewer would nitpick — before you push.

Shipped here to validate team value. May graduate to a general-tier plugin once we've confirmed the content is broadly useful outside Money.

What you need:

• A branch with staged or committed changes, diverged from origin/main
• git CLI access

Quick Start:

"Review my diff before I open the PR"

Example:

You've finished a ticket and are about to push. The skill runs git diff origin/main...HEAD, then reports one block per principle:

### Scope
- ✅ Clean — all changes in features/extra-pay-form/ tie to SAL-1234
- ⚠️  utils/date-helpers.ts:42 — quote-style change unrelated to ticket

### Simplicity
- ⚠️  features/extra-pay-form/ExtraPayForm.tsx:88 — FormFieldFactory has one caller; inline would be simpler

### Surgical changes
- ✅ Clean

### Goal-driven
- ⚠️  useSalaryBand.ts:24 bug fix has no regression test

It ends by asking whether to revert or simplify any of the findings — it never auto-fixes. Some warnings are intentional trade-offs you want to keep.

Why would you want this?

• Catches what reviewers nitpick — drive-by refactors, speculative abstractions, missing regression tests.
• Based on Karpathy's four principles — proven framework for spotting LLM-coding pitfalls.
• You stay in control — findings are reported, never silently reverted.

money-add-translations

End-to-end workflow for adding missing translations in compensation-management (and the legacy employee-salary-tab mFE) in personio-web. Scans for hardcoded strings and translation markers, replaces them with the correct t() / useTranslation hooks, generates a Phrase-ready upload JSON, and then guides you through Phrase import and translation job creation step by step.

What you need:

• Running from the personio-web repo with a clean git working tree (the skill hard-stops on uncommitted changes)
• Atlassian MCP authenticated (claude.ai Atlassian) — used to fetch the live Phrase workflow steps from Confluence. A built-in fallback is provided if the MCP is unavailable.

Quick Start:

"Add translations for SAL-1234"
"Set up i18n for the new base-pay form"
"I already have a JSON uploaded — just walk me through the Phrase job"
"money-add-translations --help"

Example:

You're implementing a new base-pay editing form (SAL-1234) and have added several hardcoded English strings with // SAL-1234 markers. The skill will:

1. Run git status --porcelain — refuses if uncommitted changes are present.
2. Delegate a read-only scan to an Explore subagent, classifying every match: ticket-tagged strings (auto-included), generic markers, bare TODOs near UI strings, untagged hardcoded literals, and existing t() calls with missing keys.
3. Present the scan summary and ask you to confirm which flagged entries to include.
4. Propose translation keys following existing namespace conventions — shows you a tree-slice preview of where each key lands, deduplicates identical strings, and asks before assigning shared keys.
5. Show a unified diff preview and apply edits: imports useTranslation / useMFETranslation, replaces literals with t() calls or <Translate> for HTML strings, cleans up markers, checks package.json deps.
6. Run lint and type-check; rolls back all edits automatically if either fails.
7. Generate /tmp/money-add-translations-SAL-1234.json, open it in Finder, and walk you through uploading it to Phrase (Section A from the Confluence workflow page).
8. Guide you through creating and starting the translation job (Section B/C).

Why would you want this?

• No documentation hunting — the full seven-phase workflow, namespace rules, hook patterns for both comp-management and legacy mFE, and Phrase import steps are loaded in one place.
• Legacy mFE detection is automatic — files under apps/employee-salary-tab/frontend/ switch to useMFETranslation / getMFETranslation / local Translate without any flags.
• Key reuse prevents fragmentation — before creating a new key the skill checks translations.json for an exact match. If the match is in a directly usable namespace (compensation, compensation-management, employee-salary-tab) the key is reused as-is and never re-uploaded. If the match is in a read-only or foreign namespace (e.g. design-system, benefits-deductions), the skill surfaces a Phrase-duplicate suggestion so existing translations carry over to the new key automatically.
• Safe by default — dirty-tree hard stop, lint/type-check gate with automatic rollback, and an explicit "safe to commit?" checkpoint before Phase 5 ensure you can't accidentally push broken code.

Contributing a skill to team-money

Anyone on the Money team can add a skill to this plugin. To keep it coherent as it grows across repos and disciplines:

• Prefix skill names with money- to avoid global collisions with other plugins' skills.
• The skill's description frontmatter must name the repo, service, or product area it applies to (e.g. "... in the personio-web repo", "... in compensation-service"). This is what lets Claude route prompts correctly when skills cover different contexts.
• Add trigger and output evals under skills/<skill-name>/evals/ — see the evals README for format and thresholds.
• Don't restrict to a single discipline — BE, FE, data, design-system, and QA skills are all welcome as long as they serve the Money team.