Versions Compared

Old Version 1

changes.mady.by.user Pragnya Nagure

Saved on

compared with

New Version Current

changes.mady.by.user Pragnya Nagure

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Jira:EGU-3216 · Team Nova

Status: In Progress

Overview

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.

Approach

The skill set was built iteratively rather than delivered as one drop:

  • Build — an initial working set of skills was implemented and exercised against real development work.
  • Validate — each skill was verified against representative development scenarios, refined based on what didn't work or felt unclear, and kept in sync across both repositories as changes landed.
  • Onboard — the finished set was demonstrated to the team, followed by hands-on environment setup and skill execution by the developers.
  • Observe — skill invocation was wired into Langfuse so usage is visible per developer and per project instead of relying on self-reporting.

What's Available Today

The following 15 skills live under .claude/skills/ in both the Partner Portal and Self Service Portal repositories, kept in sync between the two.

Image Added

Story kickoff & planning

  • kickoff — The entry point for any new piece of work. Loads the Jira PAT from .env or .env.local, calls the Jira REST API to fetch the story's summary, description, acceptance criteria, comments and attachments, 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.

    Image Added
  • writing-plans — Turns the story file from kickoff into a complete, file-by-file implementation plan saved to docs/plans/. It specifies the exact files to create or modify, including line ranges for existing files, and provides the full code for every step without placeholders such as TODO or "add appropriate error handling." The work is broken into 2–5 minute, bite-sized steps that can be followed by an engineer with no prior knowledge of the codebase. For UI stories, it checks for a Figma link first and uses the Figma MCP to pull the exact colours, spacing, and design tokens instead of relying on a description. It also enforces the MudBlazor-only rule defined in CLAUDE.md. If raw HTML is required, an explicit exception must be included explaining what was tried and why it didn't work. The workflow finishes with a self-review covering spec coverage, placeholder checks, and type consistency before handing off to either subagent-driven-development or executing-plans.

Implementation

  • executing-plans — Loads a saved plan, reviews it for gaps or concerns before starting, then works through each task in order within the current session, running the specified verification command at every step. "Commit" checkpoints within a task are optional — it suggests the EGU-XXXX: commit message but never blocks progress if the developer chooses not to commit. Always runs using-git-worktrees first, then hands off to finishing-a-development-branch once all tasks are complete.

  • subagent-driven-development — The higher-throughput alternative to executing-plans: dispatches a fresh, context-isolated subagent for each task using dedicated implementer, spec-reviewer, and code-quality-reviewer prompt templates. After each task, it runs a two-stage review loop — spec compliance first, then code quality — and repeats the review until both pass before moving on. It runs continuously without pausing between tasks unless genuinely blocked, and asks once up front whether to commit after each task or defer all commits until the end.

    Image Added

  • 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.

  • using-git-worktrees — Runs before any implementation work starts. Reads 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. It always finishes with dotnet restore and a baseline test run, so implementation never starts on an unverified workspace.

    Image Added

Review & verification

  • verification-before-completion — Not a skill with its own steps, but a standing rule enforced across all the others: no claim that tests pass, a build succeeds, or a bug is fixed is valid unless the exact verification command was just run and its output quoted in that same response — a prior run, an assumption, or a subagent's self-reported success doesn't count as evidence. Applied specifically before finishing a development branch, committing, or raising a PR, so completion claims at those checkpoints are always backed by fresh output, not confidence.
  • requesting-code-review — Dispatches a code-reviewer subagent with only precisely curated context — the task description, the requirements it should meet, and the exact base/head commit SHAs — never the requesting session's own conversation history, so the reviewer evaluates the diff cold. It is mandatory after each task in subagent-driven development, after finishing a feature, and before merging.
  • receiving-code-review — Governs the full loop of handling PR feedback, not just how to phrase a reply. Phase 0 identifies the PR (or auto-detects it from the current branch), checks out its head branch if needed, and pulls every layer of feedback — the top-level review body, per-reviewer summaries, and inline diff comments with their comment IDs — via gh pr view and gh api. Each item is verified against the actual codebase (checking real usage, looking for documented reasons behind the current implementation) before anything is implemented, then addressed one at a time with tests. Once fixed, replies go back into the same inline review thread — never a flat top-level comment — referencing the exact commit SHA the fix landed in and tagged with a mandatory (🤖 Claude Code) marker, before re-requesting review. Replies state the fix directly rather than adding commentary.

    Image Added

  • finishing-a-development-branch — The pre-handoff checklist: runs the test suite, reports any uncommitted changes file-by-file, and checks the branch's implementation against the acceptance criteria saved in the story file, reports whether each criterion passes or fails. Deliberately stops there — it never commits and never opens a PR, leaving that decision to the developer.

Delivery

  • commit — Extracts the EGU ticket number from the current branch name, shows exactly which files are staged and which are unstaged (never stages broadly on its own), drafts a commit message (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.
  • sync-branch — Merges a base branch into the current feature branch using 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.
  • raise-pr — Verifies tests pass and the working tree is clean, detects the base branch from the upstream tracking ref, rebases onto it, and only then opens the PR via 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.

End-to-end orchestration

  • 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.

    Image Added


Observability — Usage Tracking with Langfuse

Claude Code emits OpenTelemetry (OTLP) telemetry. Because the team's self-hosted Langfuse instance runs v2 (which has 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.Image Added

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 both repositories, with the SSP repository containing the latest version:

References