← Case studies

Case Study

AI-Assisted Delivery Workflow

How a team-maintained repository of rules, commands, and context documents turned AI tooling from a personal productivity hack into a shared engineering standard — cutting prototype-to-preview turnaround from a week to one or two days.

Background

AI coding assistants work best when they understand your project. Out of the box they don't know your component library, your service boundaries, your token conventions, or your review expectations. Engineers were solving this individually — pasting context into every new session, re-explaining conventions, getting inconsistent output — and none of that shared knowledge was persisting anywhere.

The opportunity was to treat AI configuration the same way we treat code: version it, review it, share it, and improve it collaboratively.

Phase 1 — Team-Scoped Command Repository

The first step was a shared cursor commands repository used by the feature team. Commands were organised into three tiers, each building on the last, and mirrored across every service layer (UI, API, BFF, data, styles):

TIER PURPOSE LAYERS 1 Context Docs Load project knowledge before acting Architecture, conventions, file locations UI · API · BFF · DB · CSS 2 Integration Patterns How this layer connects to others Auth, error handling, data contracts UI · API · BFF · DB · CSS 3 Implementation Full task execution with guardrails Generates reviewable changes against standards UI · API · BFF · DB · CSS

A command would instruct the AI to load relevant context first, then apply the right integration pattern for the layer, then produce an implementation that fit the existing codebase structure. The layered loading meant the AI wasn't working from a blank slate on any task.

An example context command for the UI layer:

# Context: UI Layer

You are working in an Angular frontend. Before implementing, load
the following context in order:

1. Read the component library docs at `lib/<component>/README.md`
2. Check existing usage patterns in `src/app/shared/`
3. Follow the design token rules in `.cursor/rules/ds-tokens.mdc`

Then confirm the affected files before making any changes.

Phase 2 — Rules as Persistent Standards

Commands handle tasks. Rules handle ongoing conventions — things the AI should always know regardless of what it's being asked to do. I contributed rules covering areas I worked directly in: design system token usage, component patterns, and UX conventions like modal layout and copy standards.

Rules are scoped by file glob so they activate only when relevant. A token rule fires when editing CSS; an Angular standards rule fires when editing TypeScript. The result is context that's always present but never noisy.

---
description: Design system color token usage
globs: **/*.{ts,html,css,scss}
alwaysApply: false
---

# Color Token Usage

Always reference semantic tokens, never primitive values.

```css
/* ✅ */
color: var(--color-text-primary);

/* ❌ */
color: #1a1a2e;
```

Semantic tokens adapt to theme; primitives break dark mode and brand updates.

Phase 3 — Architecture Repository as Cross-Team Standard

As the practice matured, technical leadership consolidated guidance into a shared architecture repository used across engineering, design, and product. This broadened the scope considerably:

ENGINEERING Angular standards Git policy BFF permissions Test conventions DESIGN SYSTEM Color tokens Component library Chip patterns Modal layout UX / PRODUCT Discovery workflow Copy standards Ideation patterns Prototype scope PROTOTYPES Product explorations Cross-team visibility HTML/CSS previews Living alongside rules

Product now commits prototype explorations directly alongside engineering rules, giving the whole team — and AI agents — a single place to understand both what we're building and how we build it. The repository becomes a living specification that's always current.

My Contribution

My work spanned the transition between both phases. In the team repository I wrote command sets for the areas I worked in, established the layered loading pattern, and contributed to onboarding others onto the workflow. As documentation moved to Confluence, I wrote pages specifically structured to be AI-readable — not just human documentation, but content that agents could parse as context. Those pages informed rules that made it into the architecture repository.

The practice also changed how I approach design-to-code work. Rather than hand-coding Angular scaffolding from a prototype, I build context-loaded commands that let the AI do the structural work while I focus on correctness, accessibility, and the decisions that actually require judgment.

Outcome

Prototype-to-reviewable-PR turnaround dropped to 1–2 days on recent deliveries, against an estimated week for equivalent hand-coded scaffolding. More consistently: engineers on the team produce output that fits existing architecture without needing per-session onboarding, and new contributors have a documented starting point rather than tribal knowledge passed through Slack.