Jira: EGU-3216 · Team Nova
Status: In Progress
As a developer, having a consistent, AI-assisted way to move through the software development lifecycle, from picking up a Jira story to raising a pull request, reduces manual effort and keeps delivery consistent across projects. This initiative delivers a set of Claude Skills covering story kickoff, technical planning, implementation, code review, validation, and pull request preparation, plus an observability layer so skill usage is actually visible rather than self-reported.
The skill set is shared across two codebases — EGU Partner Portal (EGZP) and EGU Self Service Portal (SSP) — and kept in sync between them.
The skill set was built iteratively rather than delivered as one drop:
The following 15 skills live under .claude/skills/ in both the Partner Portal and Self Service Portal repositories, kept in sync between the two.
.env or .env.local, calls the Jira REST API to fetch the story's summary, description, acceptance criteria and comments, and scans them for any Figma links. It then detects the developer's alias from git config user.email, creates the correctly-named feature branch (users/<alias>/egu-<number>) from the confirmed base branch, and saves everything it fetched to a local story file (docs/stories/EGU-<number>.md) that every later skill reads from. If the working tree already has uncommitted changes, it offers a worktree or a stash rather than forcing a branch switch.kickoff into a complete, file-by-file implementation plan saved to docs/plans/: exact files to create or modify (with line ranges for existing files), full code for every step — never a "TODO" or "add appropriate error handling" placeholder — broken into 2–5 minute bite-sized steps written for an engineer with zero context on this codebase. For UI stories it looks for a Figma link first and pulls exact colours, spacing and design tokens through the Figma MCP rather than working from a description, and enforces the MudBlazor-only rule from CLAUDE.md (any raw HTML needs an explicit, justified exception block naming what was tried and why it failed). Finishes with a self-review pass — spec coverage, placeholder scan, type consistency — before handing off to either subagent-driven-development or executing-plans.executing-plans — Loads a saved plan, reviews it critically for gaps or concerns before starting, then works through every task's steps in order within the current session, running the specified verification command at each step. "Commit" checkpoints inside a task are optional — it proposes the EGU-XXXX: message but never blocks progress if the developer says no. Always runs using-git-worktrees first, and hands off to finishing-a-development-branch once every task is done.
subagent-driven-development — The higher-throughput alternative to executing-plans: dispatches a fresh, context-isolated subagent per task using dedicated implementer/spec-reviewer/code-quality-reviewer prompt templates, running a two-stage review loop after each task (spec compliance first, then code quality — re-reviewing until both pass) before moving on. Runs continuously without pausing between tasks unless genuinely blocked and asks once up front whether to commit after every task or defer all commits to the end.
dispatching-parallel-agents — For situations with several unrelated problems at once (e.g. three different test files failing for three different reasons), this dispatches one agent per independent problem domain concurrently instead of investigating them one at a time. Each agent gets a narrow, self-contained scope, explicit constraints (e.g. "tests only, don't touch production code"), and a specific expected output; results are checked for conflicts before being integrated.
protected_branches from .claude/config.yml, detects whether the current checkout is already isolated on a safe branch, and if not, either uses a native worktree tool or falls back to git worktree add under a gitignored .worktrees/ directory. Always finishes with dotnet restore and a baseline test run, so implementation never starts on an unverified workspace.gh pr view), checks out the PR's head branch if needed, then pulls every layer of feedback — the top-level review body, per-reviewer review summaries, and inline diff comments with their comment IDs — via gh pr view and gh api. Every item is verified against the actual codebase before anything is implemented (grepping for real usage, checking for a documented reason behind the current implementation) rather than applied on trust, implemented one at a time with tests, and — this is the part that answers "does it help with PR responses" — once fixed, replies are posted back into the same inline review thread (never as a flat top-level PR comment), referencing the exact commit SHA the fix landed in and tagged with a mandatory (🤖 Claude Code) marker, before re-requesting review. It also explicitly bans performative replies ("You're absolutely right!", "Great catch!") in favour of just stating the fix.EGU-XXXX: description, with an optional reasoning-only body when the "why" isn't obvious from the diff), and always waits for explicit confirmation — "no"/"skip"/"later" is a fully valid answer and is never re-prompted — before running git commit. Every commit it makes carries a mandatory Co-Authored-By trailer.git merge --no-ff --no-commit (never rebase, so the sync is safe to repeat without ever force-pushing), reading valid base branches from .claude/config.yml. Conflicts are listed file-by-file and only auto-resolved when genuinely unambiguous (pure formatting or clearly additive on both sides) — anything where both sides changed the same logic differently is kicked back to the developer rather than guessed at.gh pr create — using the repo's .github/PULL_REQUEST_TEMPLATE.md if one exists. Confirms both the title and the full body with the developer before creating anything, and every PR body ends with a mandatory Claude Code signature footer. Never merges locally.feature-flow — The umbrella skill: chains kickoff → writing-plans → (executing-plans or subagent-driven-development) → finishing-a-development-branch → commit → raise-pr into one guided flow for a story, but pauses for explicit confirmation at every phase boundary rather than running unattended end-to-end. If tests fail or a Definition-of-Done gap turns up at the verification phase, it stops rather than pushing through to commit.
Claude Code emits OpenTelemetry (OTLP) telemetry. Since the team's self-hosted Langfuse instance runs v2 (no native OTLP support), a lightweight proxy (otel-langfuse-proxy, an Azure Container App) bridges the two protocols. It also handles multi-tenant routing — each project's traces land in its own Langfuse project based on a project.id set in that repo's .claude/settings.json, so multiple repositories can share one proxy deployment without their data mixing. Skill and subagent names are read natively from OTEL span attributes, giving accurate trace naming and an automatic skill_invoked score per trace.
The full architecture, setup steps for onboarding a new project, and a record of issues investigated and fixed (including a pricing_tier_id schema issue that was blocking model-cost configuration) are maintained as a living document in the SSP repository:
docs/Claude-Code-Langfuse-Integration.md (EGU Self Service Portal repo).claude/skills/ in both the Partner Portal and Self Service Portal repositoriesdocs/Claude-Code-Langfuse-Integration.md