You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

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.

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 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.
  • writing-plans - Turns the story file from 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.

Implementation

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

  • 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. Always finishes with dotnet restore and a baseline test run, so implementation never starts on an unverified workspace.

Review & verification

  • verification-before-completion — A hard gate rather than a workflow step: it blocks any claim that tests pass, a build succeeds, or a bug is fixed unless the exact verification command was just run in that message and its output is quoted. It explicitly names and forbids the usual rationalisations that lead to false completion claims — "should work now," "the agent reported success," "the linter passed" standing in for an actual build check.
  • 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. 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 response. Its Phase 0 identifies the PR (or auto-detects it from the current branch via 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.
  • finishing-a-development-branch — The pre-handback 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, reporting pass/fail per criterion. 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 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.




Observability — Usage Tracking with Langfuse

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:

References



  • No labels