{"slug": "building-a-reusable-ai-workflow-for-azure-devops-work-items", "title": "Building a Reusable AI Workflow for Azure DevOps Work Items", "summary": "A developer built Start Story, a reusable AI workflow that automates Azure DevOps work items from acceptance criteria to pull request creation while keeping developers in control. The system separates deterministic scripts, AI reasoning in Markdown, and product knowledge in profiles to ensure safety and reusability across different repositories.", "body_md": "AI is great at reasoning. It is terrible at remembering how your company likes to do Git.\n\nEvery week I implement dozens of Azure DevOps work items.\n\nThe process is always the same.\n\nNone of those steps are individually difficult.\n\nThey're just repetitive.\n\nNaturally I thought:\n\n\"Why can't an AI agent do all of this?\"\n\nIt turns out writing code is only about **20% of the workflow**.\n\nThe remaining 80% is engineering discipline.\n\nAn AI agent can absolutely generate code.\n\nBut it doesn't automatically know:\n\nThose aren't intelligence problems.\n\nThey're workflow problems.\n\nThat's why I built **Start Story**.\n\nRather than creating another \"AI coding assistant\", I wanted to build something different:\n\nA reusable workflow that safely takes an Azure DevOps work item all the way to a Pull Request while keeping a developer firmly in control.\n\nI had three design goals.\n\nI didn't want AI replacing developers.\n\nI wanted it replacing ceremony.\n\nIf an agent can save me fifteen minutes on every ticket by handling Git operations and Azure DevOps plumbing, that's a meaningful productivity gain.\n\nThe first version worked.\n\nUnfortunately it only worked for **my** repositories.\n\nRepository names were hardcoded.\n\nValidation rules lived inside PowerShell.\n\nSearch guidance referenced my controllers.\n\nIt wasn't a reusable tool.\n\nIt was a diary entry that happened to execute.\n\nI wanted something I could point at an entirely different product and have it work with minimal configuration.\n\nAutomation should reduce mistakes.\n\nNot create new ones.\n\nThat meant every operation had to be deterministic.\n\nNo guessing.\n\nNo \"probably\".\n\nNo auto-merging.\n\nNo silently continuing after errors.\n\nHuman approval always remains the final step.\n\nThe finished workflow looks like this.\n\n```\nAzure DevOps Work Item\n        │\n        ▼\nRead Story\n        │\n        ▼\nUnderstand Acceptance Criteria\n        │\n        ▼\nDetect Repository\n        │\n        ▼\nCreate or Reuse Branch\n        │\n        ▼\nAgent Implements Change\n        │\n        ▼\nValidate Repository\n        │\n        ▼\nDeveloper Review\n        │\n        ▼\nCommit\n        │\n        ▼\nPush\n        │\n        ▼\nCreate Pull Request\n```\n\nNotice what isn't there.\n\nMerge.\n\nThe workflow deliberately stops after creating the Pull Request.\n\nReview is still performed by a human.\n\nThat decision alone removed a huge amount of risk.\n\nOriginally I thought this project was mostly about prompts.\n\nIt wasn't.\n\nThe biggest challenge was deciding **what belongs where**.\n\nEverything had become mixed together.\n\nPowerShell knew repository names.\n\nMarkdown knew folder structures.\n\nConfiguration files contained workflow logic.\n\nEvery change required editing multiple places.\n\nEventually I realised I wasn't building one system.\n\nI was building three.\n\nThe architecture eventually became surprisingly simple.\n\n| Layer | Responsibility |\n|---|---|\n| Scripts | Deterministic operations |\n| Markdown | AI reasoning |\n| Profiles | Product knowledge |\n\nEach layer has exactly one responsibility.\n\nThat sounds obvious.\n\nIt wasn't obvious while building it.\n\nScripts perform work that should always behave identically.\n\nExamples include:\n\nA script should never need to \"think\".\n\nIt simply executes.\n\nThat makes scripts predictable and easy to test.\n\nThey become the safety rails around the AI.\n\nMarkdown contains instructions for the coding agent.\n\nExamples include:\n\nUnlike scripts, markdown is expected to evolve.\n\nAs I discover better workflows, the instructions improve.\n\nThe scripts rarely change.\n\nThe prompts improve continuously.\n\nThat separation turned out to be incredibly valuable.\n\nEvery product has tribal knowledge.\n\nThings like:\n\nOriginally those details lived inside prompts.\n\nThat meant every repository required editing the workflow.\n\nNow they live inside repository profiles.\n\nChanging products no longer requires changing the workflow.\n\nOnly the profile changes.\n\nEventually I settled on one design rule.\n\nIf it's deterministic, put it in a script.\n\nIf it requires judgement, put it in markdown.\n\nIf it's specific to one product, put it in a repository profile.\n\nThat single decision simplified almost every part of the project.", "url": "https://wpnews.pro/news/building-a-reusable-ai-workflow-for-azure-devops-work-items", "canonical_source": "https://dev.to/lokeshagarwal/from-azure-devops-ticket-to-pull-request-an-agent-skill-that-stops-short-of-merge-5eem", "published_at": "2026-07-28 00:09:09+00:00", "updated_at": "2026-07-28 00:32:02.809356+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-products"], "entities": ["Start Story", "Azure DevOps"], "alternates": {"html": "https://wpnews.pro/news/building-a-reusable-ai-workflow-for-azure-devops-work-items", "markdown": "https://wpnews.pro/news/building-a-reusable-ai-workflow-for-azure-devops-work-items.md", "text": "https://wpnews.pro/news/building-a-reusable-ai-workflow-for-azure-devops-work-items.txt", "jsonld": "https://wpnews.pro/news/building-a-reusable-ai-workflow-for-azure-devops-work-items.jsonld"}}