team-cet

CET team's Claude Code toolkit for frontend development in personio-web.

Installation

# Install the plugin
claude plugin install team-cet@personio-claude-code-marketplace

What does this plugin do?

Skills for the Customer Enablement Team's day-to-day frontend workflow in personio-web — from picking up a JIRA ticket through opening a draft PR. Frontend dev workflows use a cet-fe-* prefix; future development sub-scopes follow the same pattern (cet-be-*, cet-ops-*). Cross-cutting on-call/handover skills like firefighter-handover use bare descriptive names since they are not tied to a single development discipline.

cet-fe-dev skill

End-to-end JIRA-to-PR workflow for CET tickets. Fetches issue details from Jira, proposes a plan for your approval, implements the changes in one of CET's owned modules under product-areas/global-experience, adds tests, runs lint/type/test checks, and opens a draft PR with a conventional commit message.

What you need:

• Checked out copy of personio-web
• Atlassian MCP server configured (required — the skill stops if it can't reach Jira)
• GitHub CLI (gh) installed and authenticated: brew install gh && gh auth login
• A JIRA ticket ID with the CET- prefix

Quick Start:

# Ask Claude to work on a CET ticket — the skill triggers on CET-prefixed tickets
"Work on CET-2841"
"Implement CET-1234 and open a draft PR"

Claude will guide you through confirming the ticket, clarifying scope, approving the plan, and opening the PR.

Example:

$ "Implement CET-2841"

# Claude fetches the ticket via Atlassian MCP
# Displays: Summary, Description, Acceptance Criteria, Component, Labels, Priority, Status
# Identifies target module from the Component field
#   (e.g., views/support, features/contact-us, features/give-customer-feedback-dialog)
# Asks clarifying questions: scope, backend changes, external integrations, patterns
# Presents a plan: files to modify, files to create, test strategy
# You approve
# Offers to create a branch (CET-2841/<kebab-description>) or worktree
# Implements, adds tests, runs lint + type + test
# Opens a draft PR in personio-web

Why would you want this?

• You want CET tickets resolved end-to-end without stitching together six different prompts
• You want the JIRA Component field to drive module targeting automatically
• You want plans you can approve before any code is written
• You want branch names, commit messages, and PR descriptions to follow team conventions by default

cet-fe-worktree skill

Creates a git worktree for a CET ticket under ../<repo>__worktrees/<branch> so you can work on multiple tickets in parallel without stashing.

What you need:

• A git repository (typically personio-web)
• A CET-prefixed ticket id
• Optional: a short description for the branch suffix

Quick Start:

"Create a worktree for CET-1234"
"Set up a parallel workdir for CET-500 — adding contact form validation"

Example:

$ "Create a worktree for CET-1234 adding support for file uploads"

# Claude derives branch: CET-1234/support-file-uploads
# Confirms target directory: ../personio-web__worktrees/CET-1234/support-file-uploads
# If ../personio-web__worktrees/ doesn't exist, asks before creating
# Runs: git worktree add -b CET-1234/support-file-uploads \
#         ../personio-web__worktrees/CET-1234/support-file-uploads origin/main

Why would you want this?

• You're context-switching between multiple CET tickets and don't want to stash/unstash
• You want worktree paths and branch names to follow the same conventions across the team
• You want the cet-fe-dev skill to hand off to worktree setup automatically when you're on main

cet-pr-to-jira-ticket skill

Creates a CET Jira ticket from an existing draft PR, adds it to the current sprint, and links the PR back to the ticket by updating the title and body.

What you need:

• A draft PR already open in GitHub
• Atlassian MCP server configured (required — the skill stops if it can't reach Jira)
• GitHub CLI (gh) installed and authenticated: brew install gh && gh auth login

Quick Start:

# Ask Claude to create a Jira ticket for your open PR
"Create a ticket for this PR"
"Track this PR in Jira"
"Add this PR to the sprint"

Example:

$ "I forgot to create a Jira ticket before opening the PR. Can you create one?"

# Claude reads the open PR via gh pr view (title, body, URL)
# Infers issue type from the title prefix ([Fix] → Bug, [Tech Debt], [Spike], otherwise Task)
# Fetches the current sprint ID from Jira
# Creates a CET ticket with the PR's Why/What content as the description
# Updates the PR title to prepend [CET-XXXX]
# Appends a ## Ticket section with the Jira URL to the PR body
# Displays the Jira ticket URL and updated PR URL

Why would you want this?

• You open a PR before creating the Jira ticket and need to backfill it without manual copy-paste
• You want the ticket automatically added to the active sprint — no board drag-and-drop needed
• You want the PR title and body updated with the ticket number so the team can navigate between them

firefighter-handover skill

Automates the CET firefighter rotation handover: collects @ff_cet Slack pings, FF Jira tickets, and alert volume from #not_alerts_cet, deduplicates them into a classified incident list, guides you through review and enrichment, then creates the Confluence journal page and optionally updates the Error Cheatsheet.

What you need:

• Atlassian MCP server configured (required for Confluence page creation; falls back to manual mode if unavailable)
• Slack MCP server configured (required for automated data collection; falls back to Jira-only or full manual mode)
• pup CLI installed and authenticated (optional — enables automatic Datadog log enrichment for each detected Sentry/alert pattern)

Quick Start:

# Trigger at the end of your FF rotation week
"Do the firefighter handover for this week"
"I finished my FF rotation, let's create the journal entry"
"Create my CET firefighter journal entry for last week"

Example:

$ "I'm the FF this week, help me create the handover doc"

# Claude asks: current week, previous week, or custom date range?
# Fetches your Jira accountId via atlassianUserInfo
# Collects in parallel:
#   - @ff_cet pings from #not_alerts_cet via Slack MCP
#   - Assigned FF Jira bug/escalation tickets via Jira MCP
#   - Datadog + Sentry alert volume from #not_alerts_cet
# Deduplicates and classifies into: RESOLVED_FIX, CARRY_OVER, NOISY_ALERT,
#   RESOLVED_ESCALATED, INFORMATIONAL
# Presents the incident summary for your review — you approve or correct
# Enriches RESOLVED_FIX incidents with root cause + fix links for the cheatsheet
# Asks for carry-over notes for the next FF
# Generates the Highlights / Lowlights / Notes / Carry Overs document
# You approve the draft
# Creates the Confluence page under the FF Journal: [CET-FF] DD/MM/YYYY-DD/MM/YYYY
# Optionally appends RESOLVED_FIX entries to the Error Cheatsheet

Why would you want this?

• You want the handover document created in minutes instead of manually reconstructing the week from Slack and Jira
• You want incident deduplication so Slack pings and Jira tickets about the same issue appear as one record
• You want cheatsheet candidates auto-detected — no more forgetting to document a fixed Sentry error
• You want carry-over context captured so the next FF starts with a clear picture of open issues
• You want Sentry/Datadog error patterns pre-investigated with real log context — when pup is installed, it auto-queries Datadog logs for each alert cluster so the root-cause suggestion in the cheatsheet comes pre-filled