AI Agents & Workflows

The AI-Powered Developer

Orchestrator & Expert Agent Methodology

How we use 15 specialized agents to go from ADO story to shipped PR.

July 2026

.github/ ├── agents/ │ ├── requirements.agent.md │ ├── feature.agent.md │ ├── story.agent.md │ ├── code-backend.agent.md │ └── code-review.agent.md ├── skills/ │ ├── new-endpoint/SKILL.md │ ├── test-api-patterns/SKILL.md │ └── pr-review-csharp/SKILL.md ├── instructions/ │ ├── csharp.instructions.md │ └── typescript.instructions.md └── memorybank/ ├── ado-project-info.md └── stories/12345/plan.md
Overview

Agenda

5 min Why Agent-Based Development
The problem with manual handoffs and context loss
5 min The Agent Ecosystem
15 agents in 3 tiers — orchestrators, implementers, quality gates
10 min The Delivery Lifecycle
Feature path, story path, Dev/QE split, auto mode
10 min Context Management
4-tier architecture, drift detection, why it matters
5 min Quick Reference & Getting Started
Commands cheat sheet, tooling setup
25 min Live Workshop
Walk through a real story: analyze → refine → implement
The Problem

Why Agent-Based Development?

Context Loss

  • Switching between tools loses context
  • Requirements → code → test → PR — each a cold start
  • Decisions made in chat vanish with the session

Manual Handoffs

  • Dev finishes code, tells QE "it's ready"
  • QE re-reads the story, figures out what to test
  • No structured handoff — context reconstructed, not transferred

Inconsistent Quality

  • One generalist AI doing everything
  • No enforced quality gates between phases
  • Review is optional, not structural
Agents are specialists, not generalists. Each owns one phase and hands off with context preserved. Nothing written to ADO or Git without explicit approval.
Ecosystem

15 Agents in 3 Tiers

Tier 1 — Orchestrators & Analysis (deep reasoning)

🔀 @feature Opus
Multi-story features → PRD → Design → ADO Stories
📋 @story Opus
Single story → branch → code → tests → PR
📝 @requirements Opus
Story analysis, refinement, BDD scenarios, ADO updates
🏗️ @plan Opus
Architecture exploration, technical design (read-only)

Tier 2 — Implementation & Testing (speed + quality)

⚙️ @code-backend Sonnet
C# / .NET services, endpoints, unit tests
🎨 @code-frontend Sonnet
React / TypeScript components, hooks
🧪 @test-api Sonnet
Aspire + Kiota integration tests
🎭 @test-e2e Sonnet
Playwright E2E, persona auth

Tier 3 — Quality Gates & Review

🛡️ @author-req Sonnet
Reviews AC quality (auto mode)
🛡️ @author-code Sonnet
Reviews code changes (auto mode)
🛡️ @author-tests Sonnet
Reviews test coverage (auto mode)
🔍 @code-review Opus
Security, SOLID, patterns (read-only)
🚀 @pr-create GPT-5.4 mini
Structured PR creation
Orchestration

Two Orchestrators, Different Scopes

@feature — Multi-Story Features

For features that need upfront planning before code. Creates PRD, design doc, and story breakdown.

  • Each phase gated by /approve
  • Design produces API contracts shared between backend & frontend stories
  • Delivers ADO user stories — does not write code
  • Frontend stories include WireMock stubs as definition of done
/start feature
/approve prd
/approve design
/approve stories
/create stories

@story — Single ADO Story

For a well-scoped story ready to implement. One command starts the entire flow.

  • Auto-detects scope — backend, frontend, or full-stack
  • --dev (app code + draft PR) / --qe (tests + PR ready)
  • --auto adds author quality gates between phases
  • Story plan saved to disk — resumable across sessions
/start <id>
--dev / --qe
--auto
/resume
/status

Run @requirements first — refine the story before handing to @story. In --auto mode, @author-requirements catches unrefined stories and loops back automatically.

Lifecycle · Feature Path

Feature Path — PRD to ADO Stories

@feature /start
→
PRD
→
/approve prd
→
Design
→
/approve design
→
Stories
→
/approve stories
→
/create stories
@feature /start feature my-feature    # creates memory bank workspace
/approve prd                                    # gates next phase
/approve design                                 # API contracts defined
/approve stories                                # story breakdown ready
/create stories                                 # pushes to ADO
  • Creates .github/memorybank/myproject/my-feature/ with PRD, design, and tasks
  • Design phase produces API contracts — endpoints, request/response shapes, status codes
  • Each story gets a scope tag: [backend], [frontend], or [full-stack]
  • After /create stories, run @requirements on each story to refine AC before implementation
@feature delivers stories, not code. Each story is picked up by @story for implementation.
Lifecycle · Story Path

Story Path — Dev/QE Split

One story, one branch. Dev implements, QE tests. The handoff is structured.

Dev Flow (--dev)

@story /start --dev
→
@requirements
→
Intake ✓
→
@code-*
→
@code-review
→
Draft PR

QE Flow (--qe)

@story /resume --qe
→
Intake ✓
→
@test-api
→
@test-e2e
→
@code-review
→
PR Ready ✓

Handoff Intake Check

  • Sub-agents validate handoff context before starting work
  • Checks conversation → story plan file → asks human (last resort)
  • If @story did its job, sub-agents never need to ask the human

Scope Routing

Scope--dev agents--qe agents
Backend@code-backend@test-api
Frontend@code-frontend@test-e2e
Full-stackBothBoth

Test failures that reveal real bugs: test agents self-debug test code issues, but if a failure exposes an implementation defect, hand off to @requirements create a bug: <description> to log it in ADO with repro steps, expected vs actual, and priority.

Quality · Auto Mode

Auto Mode & Quality Gates

With --auto, author agents gate each phase automatically — no human review needed for passing work.

@requirements
→
@author-req ⭐
→
@code-*
→
@author-code ⭐
→
@test-*
→
@author-tests ⭐
→
@code-review

Rating ≥ 4

Work meets quality bar. Advances to next phase automatically.

Rating 2–3

Needs improvement. Refines the output (max 2 retries).

Rating 1

Fundamental issue. Escalates to human immediately.

Clarity Gate

If a story has vague AC, undefined scope, or missing auth requirements, @story warns before implementation and offers a handoff to @requirements.

Story Plan Persistence

Plan saved to .github/memorybank/stories/<id>/plan.md. Survives context compaction. Resume with @story /resume <id> — picks up where you left off.

Requirements

@requirements — Analyze & Refine

Analyze

@requirements 12345
  • Fetches ADO story — reads ado-project-info.md for context
  • Surfaces ambiguities, missing AC, vague language
  • Categorizes linked items — predecessors, related, parent/child
  • Produces clarifying questions
  • Does not update AC in ADO without confirmation (may add comments or Figma links)

Refine

@requirements refine story 12345
  • Numbered AC (AC-001, AC-002, …) in Given/When/Then
  • Test Awareness Matrix — 8 categories: unit, integration, E2E, a11y, i18n, auth, security, performance
  • Extracts Figma design context if frame link exists
  • Surfaces out-of-scope gaps as markdown templates
  • Asks for confirmation before updating ADO
Context

4-Tier Context Architecture

Without optimization, every chat loads ~4,600 lines of context — frontend rules for backend tasks, test patterns for simple questions. Each tier loads only when needed.

Instructions

Scoped by applyTo glob. Auto-loaded for matching files. Zero cost otherwise.

Example: C# naming rules load only when editing .cs files.

Skills

On-demand SKILL.md files. Agent loads only when the task domain matches.

Example: Test patterns load only when writing tests.

Scripts

PowerShell for deterministic operations. No tokens spent on prose.

Example: Drift detection, pattern scanning.

Memory Bank

Persistent context scoped to session, repo, or user. Agents read only what they need.

Example: ADO info, story plans, feature designs.

Token Reduction

ScenarioBeforeAfter↓
Generic chat~4,600~55088%
Backend (C#)~4,600~70085%
Frontend (React)~4,600~70085%

The Decision Rule

  • You'd be frustrated if the agent forgot it during unrelated work → Instruction
  • You'd never think about it until that specific task → Skill
  • Answer is deterministic with known params → Script
  • Needs to persist across sessions → Memory Bank
Drift Detection

Keeping Rules Accurate

Conventions evolve through PRs. Without validation, agents follow yesterday's rules — or worse, teach patterns from imaginary code.

Codebase changes
→
scan-patterns.ps1
→
Registry updated
→
Skill impact warning
→
Update skill

Pattern Scanning

scan-patterns.ps1 counts pattern usage. If "Migrating" drops to 0 → ready for "Deprecated". If "Active" count drops → organic drift.

Example Validation

validate-skill-examples.ps1 checks that types, folders, and packages in skills actually exist in the codebase.

Skill Cross-Reference

Registry links patterns → skills. When a pattern is deprecated, the registry surfaces which skills need updating.

What We Found

10
phantom refs caught
1
wrong security rule fixed

Code examples referenced imaginary types. A security skill mapped 401→404 incorrectly. Skills amplify mistakes — every agent propagates the error.

The Takeaway

Skills are a knowledge amplifier. Review skill content like production code.
Quick Reference

Getting Started

CommandWhat it does
@requirements <id>Analyze an ADO story
@requirements refine story <id>Refine AC + test matrix
@requirements create a bug: ...Log a bug in ADO
@feature /branch <id>Create a feature branch
@feature /start feature <name>Start multi-story feature
@story /start <id>Full story flow
@story /start <id> --devDev: code + draft PR
@story /resume <id> --qeQE: tests + PR ready
@story /start <id> --autoAdd author quality gates
@code-reviewReview current branch
@code-review PR <id>Review an ADO PR
@pr-createCreate a pull request

Tooling Setup

  • Azure DevOps MCP — npm package @azure-devops/mcp
  • Figma MCP — VS Code extension, auto-registers
  • Playwright MCP — npm package
  • Context7 — extension-provided

Key Conventions

  • Branch: feature/{storyId}-{short-desc}
  • Return 404 not 403 for auth failures
  • Never log PII or tokens
  • All decisions → .github/memorybank/
Workshop · 25 min

Live Workshop

Walk through a real ADO story end-to-end — from raw description to refined AC and implementation kickoff.

Step 1 — Analyze (5 min)

@requirements 12345
  • Watch it fetch the story from ADO
  • See ambiguities and gaps surfaced
  • Compare: ADO before (no AC) vs agent output

Step 2 — Refine (5 min)

@requirements refine story 12345
  • See numbered AC generated
  • BDD scenarios in Given/When/Then
  • Test Awareness Matrix across 8 categories

Step 3 — Implement (10 min)

@story /start 12345 --dev --auto
  • Watch scope auto-detection
  • Observe the handoff pattern
  • See the author gate in action

Goal: See the full flow from story intake to implementation kickoff — context preserved at every handoff.

Remaining time → Q&A · What to adjust for the team · Next steps for adoption

← → Space · F fullscreen