Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
158684 stories
·
33 followers

How AI Closes Gaps in Healthcare Before It's Too Late | Clinical Decision Support with MongoDB Atlas

1 Share
From: MongoDB
Duration: 8:36
Views: 14

🔗 Explore the architecture and technical details - https://mdb.link/WK7E0Dc52Aw-healthcare
Subscribe to the MongoDB for Developers YouTube Channel: https://www.youtube.com/@MongoDBDevelopers?sub_confirmation=1
Sign-up for a free cluster → https://www.mongodb.com/cloud/atlas/register

Every day, patients miss critical evaluations — not because their doctors don't care, but because the data arrives too slowly for anyone to act on it in time.
In this video, we walk through a Clinical Decision Support platform that detects HEDIS care gaps automatically, monitors patient vitals in real time, and gives care coordinators the clarity they need to intervene before it's too late.
We break down why FHIR data stores hit their limits under live clinical workloads, and how MongoDB Atlas serves as the operational layer that makes real-time decisioning possible — without replacing existing infrastructure.
Whether you're in healthcare IT, clinical operations, or building data infrastructure for value-based care, this is what it looks like when existing data finally does its job.

#MongoDB #HealthcareAI #ClinicalDecisionSupport #FHIR #HealthTech #CareGaps #HEDIS #MongoDBAtlas #DigitalHealth

00:00 - Introduction: What are Care Gaps?
00:45 - Measuring Quality Care with HEDIS
01:40 - The FHIR Interoperability & Query Bottleneck
02:20 - Extending FHIR with MongoDB Atlas
03:20 - Generating the Patient 360 View
03:52 - Streaming Wearable Vitals & Real-Time Alerts
04:28 - Inside the Alert and Quality Engines
05:51 - Demo: Care Coordinator Dashboard Walkthrough
07:41 - Technical Insights & System Architecture

Visit Mongodb.com → https://mdb.link/MongoDB
Read the MongoDB Blog → https://mdb.link/Blog
Read the Developer Blog → https://mdb.link/developerblog
MongoDB for Developers YouTube Channel → https://www.youtube.com/@MongoDBDevelopers

Read the whole story
alvinashcraft
27 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Announcing a new integration with WindowSill

1 Share
WindowSill's AI-powered command bar now surfaces context-aware tools for the items you select in Files.

Read the whole story
alvinashcraft
43 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Turn one giant AI-generated pull request to a reviewable stack

1 Share

Think about the last big feature you shipped. Be honest. Did you cram it into one giant pull request, or did you split it into smaller scoped pull requests? For years, you have silently had to decide between watching a pull request grow so large that reviewing it becomes a nightmare or breaking it into a chain of smaller pull requests that you have to babysit, sync by hand, and untangle conflicts every time a change is introduced below.

Both options have trade-offs. One is hard to review, while the other is hard to maintain. Your decision that day leans towards the less painful option.

Now add coding agents. They are incredibly productive and are projected to drive a 50% productivity gain across every SDLC stage by 2028, according to Gartner. But, they can’t take away the choice of how you structure your pull requests. They amplify the need to make it.

In this post, follow along with an example of how you can use stacked pull requests to simplify reviews.

A closer look: Adding product search to a shopping assistant

Let’s say you issue a prompt to add product search to a shopping assistant, walk away and minutes later, literally, you come back to review, steer, and approve. But look closely at what tends to land in that single pull request:

  • A new data model and its seed data
  • An API route and its validation
  • The client wiring and the UI and the empty/fallback/error states

…all of this and more in one ginormous 1,000+ line diff.

Animated gif showing the pull request size grow from 0 lines to over 1,500 lines.

For agents largely trained on how code has traditionally been written over the years, this pattern is their default way of shipping. Let’s play this out.

You want to add product search on as existing web application and your starting state is:

  • A mock AI Assistant showing responses from a random-line generator
  • Inconsistent product data hardcoded and scattered across components
  • No catalog module, no API, no data layer—no nothing
Screenshot of the starting state of the website without a product search.

An issue is opened to implement the feature, and a typical flow would be to create a feature branch, assign it to a coding agent (or multiple custom agents), get a first draft of the whole implementation code and updated tests…

…you read the code (well, you maybe read the code). Then, you still need to manually verify feature behavior and make any necessary updates, push and open a pull request with its long-yet-shallow AI generated description, ensure CI checks are green, and self-review diff then request reviewers. You get started…

<reviewer's hat>

Reviewer: 1,721 lines changed!! This description isn’t very helpful. I’ll review this later.

</reviewer's hat>

And what follows is familiar:

  • The large pull request becomes hard to review—so it just…sits there.
  • Reviewers lose context and the feedback quality drops.
  • It becomes even slower to merge.

This kicks off a manual, messy, time-consuming process that’s prone to conflicts before the feature lands, and it eventually lands under-reviewed.

GitHub stacked pull requests

Stacked pull requests introduce a different and better structure of delivery. The principle is simple: decomposition. Instead of shooting for a single pull request that addresses the issue in its entirety, you break down the feature into logical layers and identify the dependency chain to arrive at your desired goal. This gives you, and your agents, a native way to decompose work that otherwise lands in a giant pull request into a chain of small, focused and independently reviewable layers.

That large pull request that’s hard to review becomes a stack of smaller, logically ordered pull requests, each scoped to a single concern, small enough to hold in a reviewer’s head and with just enough context naturally flowing from the previously reviewed pull request.

Let’s make it happen.

The stack structure

Let’s look at the steps involved when decomposing the problem and arranging the layered stack.

First, and importantly, set the stack base. This matters because CI checks and merge rules throughout the stack management lifecycle get evaluated against the stack base.

Then, identify the core foundational unit of work and put it closer to the base (lowest in the stack), and layer dependent work above it.

Stack Layer (L#)/Branch What to ship Depends on 
L1 (feat/catalog-data) A typed catalog with seed data, validation, and a data access module main (stack base) 
L2 (feat/search-api) Validated /api/products/search endpoint feat/catalog-data 
L3 (feat/chat-grounding) Chat calls the API and answers from real product data feat/search-api 
L4 (feat/grounded-ui) Product citation cards + state feat/chat-grounding 

Now the independent concerns are clear: data, API, wiring, UX, making it possible to allocate different reviewer audiences for each. Data is reviewed by a data owner, UX by a UI owner.

GitHub’s native support for stacked pull requests can be launched from the pull request UI and extends seamlessly to the terminal with the gh stack CLI.

Install the stacked pull requests CLI extension

Run the following:

gh extension install github/gh-stack

In ancient times, you’d be set to start working. Not today though. There are agents working alongside you. These agents need to learn how stacks work and how to create and manage them on your behalf. The gh-stack skills teaches them this.

gh skill install github/gh-stack

Or, if you prefer:

npx skills add github/gh-stack

For the specific feature from the above example, your development workflow has custom agents, each with defined work streams and that follow a strict scoping discipline to achieve the goal of small, single-scoped pull requests.

Layer/branch Agent 
L1 (feat/catalog-data) Data modeler agent 
L2 ( feat/search-api) Backend agent 
L3 ( feat/chat-grounding) Frontend agent 
L4 ( feat/grounded-ui) Frontend agent 

The last piece of the setup is to confirm CI exists. As mentioned earlier, each pull request will be evaluated against the stack base, and these checks will run for every layer.

Now the work begins.

Layer one: Data catalog foundation

Most agent workflows today are automated and execute autonomously in loops, but for the sake of illustration, we’ll cover each step at a time.

At this point, all agents are familiar with how stacked pull requests work, so a typical workflow at this stage would be:

  1. Invoking the Data Modeler agent with an appropriate prompt
  2. The agent initializes a new stack and sets the first branch—feat/catalog-data with main as its base using gh init stack
  3. Checks out, works and runs validation
  4. (All checks == green) ? commit the layer : Iterate

Reviewer’s note for the future: Are the types correct? Is the data validated? Is the query helper safe? Period.

Layer two: Product search API

Follow a flow similar to:

  1. Invoking the Backend agent with an appropriate prompt
  2. The agent adds the next layer feat/search-api on top of layer one, its base: feat/catalog-data, to import the completed data access module with gh stack add
  3. Checks out, works and runs validation
  4. Developer tests the API manually
  5. (API works && All checks == green) ? commit the layer : Iterate

Reviewer’s note for the future: Is input validated? Is the response contract stable? Are error/empty states handled here or pushed downstream? Period.

Layer three: Wire chat to the API

In this next layer, you:

  1. Invoke the Frontend agent with an appropriate prompt
  2. The agent adds the next layer feat/chat-grounding on top of layer two. Its base: feat/search-api, which will branch off with both the data access module and validated API.
  3. Checks out, works and runs browser tests with Playwright
  4. (All checks == green) ? commit the layer : Iterate

Reviewer’s note for the future: Is every answer tracing back to a real API response? What happens when the API fails or returns nothing? Period.

Layer four: Grounded UI and citations

You’ll notice that layer three and layer four, despite having the same author, (Frontend agent), are layered distinctively. This is deliberate. The UI owner should not have to check the underlying data flow and vice versa, and this structure allows for that independence.

So, the frontend agent:

  1. Adds the next layer feat/grounded-ui on top of layer three, its base: feat/chat-grounding
  2. Checks out, works and runs browser tests with Playwright
  3. (All checks == green) ? commit the layer : Iterate

Reviewer’s note for the future: Does every citation link back to a real product? Are loading, empty and error states all covered? Period.

Submit the stack

The four local stacked branches are ready. Next is to push them to remote with gh stack push, then create pull requests linking them on GitHub with gh stack submit.

The stack map and CI on each layer

Switching over to GitHub, all four pull requests are open and at the top of each one, you see a stack map, which is a one-click navigation system between pull requests in the stack.

Reviewing and updating the stack

Time to switch hats and look at a reviewer’s journey through stacked pull requests.

<reviewer’s hat on>

The stack map is a reviewer’s compass – a navigation aid between the top of the stack and its bottom, heading towards a successful merge. The movement is directional: read top-down, review bottom-up.

  • Read top-down, for context. This gives you the end goal at the very beginning of the review process, so you can set a bearing. “Oh, so we want to display product cards on the chat interface.”
  • Review bottom-up to build on the predetermined checkpoints. The implementation on each layer only makes sense once the preceding layer is understood.

You are no longer looking at a single 1,720+ line-sized pull request to be reviewed in one sitting, as we saw in our example, but instead, the review can be distributed in small, self-contained targets in a stack.

As the assigned human in the loop reviewer, you come in and look at layer one, the pull request at the bottom of the stack, and see that the automatic Copilot Code Review (CCR) caught two issues which you agree should be fixed.

<developer's hat back on>

Changes are requested at the bottom of the stack, so you:

  • Hand the feedback to the layer one author, data modeler agent that owns the branch
  • Suggestions are applied, tested, committed and pushed
  • Once the fix lands on feat/catalog-data, the natural next question is: what does this mean for layers two, three, and four?

Since branch feat/catalog-data was pushed out of turn after the review, GitHub flags it plainly: “Some branches in this stack have diverged and must be rebased” paired with “Unable to merge as a stack” flag and that blocks the merge.

Back on the pull request UI on GitHub, a one-click Rebase stack button appears. Before using the button, there is something important worth noting. Triggering a web-based rebase using this button runs it on GitHub’s servers, which means it resets the committer to whoever clicked the button, the resulting commits aren’t signed, and if branch protection expects signed commits, that one click quietly breaks.

The safer, equivalent move from the terminal would be gh stack rebase to perform that same cascading rebase locally as you interactively resolve conflicts, but this time using your own Git configuration, then gh stack push.

Finally, you’ll propagate through the stack. The rest of the stack, both local and on GitHub, now needs to catch up, and it couldn’t be easier than a single sync command gh stack sync.

An all-in-one flow starts with fetching from origin, cascading a rebase of every branch above feat/catalog-data onto the new commit, pushes the rebased branches and syncs pull request state from GitHub. This way, the change ripples upward without anyone touching layers two, three, or four by hand.

Back on GitHub, all checks re-run, pass and the stack map settles back into a clean, mergeable line from main to feat/grounded-ui.

Get started with stacked pull requests >

The post Turn one giant AI-generated pull request to a reviewable stack appeared first on The GitHub Blog.

Read the whole story
alvinashcraft
56 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

dotInsights | August 2026

1 Share

Did you know? Ever wondered why C# uses the semicolon to terminate a statement? Obviously it comes from the C/C++ heritage it shares with other languages like Java, but where did C get it from? That would be Algol, where the semicolon was used to separate statements. 

But why the semicolon? In natural language grammar, the semicolon separates two independent but related clauses; it can also be used to separate items in a list (see what I did there?). And what is a program but a list of independent but related clauses?

(Bonus punctuation trivia: the comma is used to separate items in a list, just like the arguments in a function call. The period is used to end a complete thought, like a sentence or paragraph. How did Algol mark the end of a program unit? Why yes, with a period!)

dotInsights | August 2026

Welcome to dotInsights by JetBrains! This newsletter is the home for recent .NET and software development related information.

🔗 Links

Here’s the latest from the developer community.

  1. Nullable GUID Route Constraints in ASP.NET Core – Sebastian Nilsson
  2. Closed class hierarchies: Exploring the .NET 11 preview – Part 4 – Andrew Lock
  3. No more regressions with Snapshot Tests in C# using Verify: a practical guide – Davide Bellone
  4. HttpClient Streaming in C#: HttpCompletionOption, ReadAsStreamAsync, and Server-Sent Events – Nick Cosentino
  5. Building a Windows Tray App by combining Microsoft.UI.Reactor and a Worker Project – Morten Nielsen
  6. Windows 11 can now run Linux containers with WSL Containers, no Docker Desktop needed (hands on) – Abhijith M B
  7. Add vs AddRange in EF Core: The Performance Myth You Need to Stop Repeating – Chris Woodruff
  8. Code review is theater now – John Bristowe
  9. The .NET Host Process: What Runs Before Main() and Why It Sometimes Hangs – David McCarter
  10. Worse is better: JSON versus XML – Mark Seemann
  11. The best code is the one you shift+delete – Oren Eini
  12. The Docker CLI Commands I Actually Use Every Day – James Joyner
  13. Migrate Your WPF App to the Web, From Your Browser – XAML.io Team
  14. How to Build a Dark Mode Toggle Without JavaScript – Jakub T. Jankiewicz
  15. The role of ActivitySource in OpenTelemetry for .NET – Bart Wullems
  16. Track every EF Core record change with temporal tables – David Grace
  17. The Complete Guide to Tool Selection in AI Agents – Shittu Olumide
  18. Coffee and Open Source Conversations – Jimmy Bogard – Isaac Levin
  19. Available Now in .NET 11 for .NET MAUI – Leomaris Reyes
  20. Multi-Tenancy Isn’t About Databases – Derek Comartin
  21. Composition Ring Spinner [Avalonia] – Stefan Koell
  22. C# Async/Await Made Simple – Lou Creemers
  23. How to Log JSON Without Turning Your Terminal Into a Wall of Text – JavaScript Tools
  24. What is a webhook? Endpoints, examples, and how they work – Jesse Sumrak
  25. C# Tip: Use required members to prevent invalid object initialization (beware of SetsRequiredMembers attribute!) – Davide Bellone
  26. You’re Already Using .NET’s ChangeToken (You Just Don’t Know It) – Khalid Abuhakmeh & Al Rodriguez
  27. Zero-Code Validations in Your .NET API – Pavel Kalandra
  28. A gentle introduction to Git worktrees – Nicholas C. Zakas
  29. Stop Using Singletons in Unity | Game Systems Explained – Stacey Haffner
  30. Guidelines for URL Storage and Comparison – Eric Lawrence
  31. Dijkstra’s Shortest Path Algorithm – Kirupa Chinnathambi
  32. TimeProvider and the End of Untestable DateTime.Now – Maarten Balliauw
  33. Stop Accepting Breached Passwords: Integrating HaveIBeenPwned with Duende UserManagement – Al Rodriguez & Khalid Abuhakmeh
  34. .NET Aspire: The price of forgetting WithReference – Bart Wullems

☕ Coffee Break

Take a break with something a little more fun.

DoomPaint – Doom using MS Paint as a playable display by leveraging clipboard and paste. Includes Doom shareware and plays with music and sound effects – Mark Russinovich. Don’t ask why. There is no why. It just is.

Yes, that’s a trailer for the Java Story in a .NET newsletter, but who doesn’t love a geeky bit of history, right?

200+ Funny Software Developer Puns and Jokes That Only Coders Will Truly Get – brace yourself

🗞️ JetBrains News

What’s going on at JetBrains? Check it out here:

✉️ Comments? Questions? Send us an email

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete

AI Prompt Cookbook for React Developers

1 Share

These 10 prompts can help React developers get immediate value from AI features in Progress KendoReact. Plus, learn about the techniques for why some prompts work well.

If there’s one thing that prompt engineering guides (like Anthropic’s and OpenAI’s) agree on, it’s that the quality of AI-generated output depends heavily on the quality of our input. Clear, specific, well-structured instructions tend to produce better results, while vague requests tend to produce vague code.

We’ve built a visual cheat sheet that accompanies this article with a quick-reference view of all the prompts and techniques covered below. For React developers working with Progress KendoReact, this prompt library is especially relevant because component libraries have specific APIs, prop patterns and conventions that generic AI models may not be aware of. Check it out here → https://kendoreact-ai-prompt-cookbook.up.railway.app/.

The KendoReact Agentic UI Generator addresses this gap by giving AI assistants specialized knowledge of KendoReact components through the MCP Server. But even with that context in place, the prompts we write still determine whether the generated output is “good enough” or what we had in mind.


Image generated with AI

This cookbook is a concise collection of practical, task-oriented prompts designed to provide immediate value from KendoReact AI tools. Each prompt is paired with a prompting technique from established research, so beyond just having something to copy and paste, we’re also picking up patterns that apply to any AI-assisted development workflow.

Prerequisites: Make sure the KendoReact Agentic UI Generator is installed and enabled before running these prompts. As you’ll see in this post’s prompts, the MCP Server exposes several specialized assistants—UI generation, styling, icons, accessibility and layout—each invoked with its own hashtag. For a complete setup walk-through with Cursor, check out The KendoReact MCP Server with Cursor.

Prompting Principles

Before jumping into the prompts themselves, let’s quickly cover the principles that make them work. These come from well-established prompting research published by Anthropic and OpenAI, and they apply whether we’re working with KendoReact or any other AI-assisted workflow.

Be Clear and Direct

Instead of a prompt that just says “make a table,” we describe what columns we need, what data operations to support and how the component should behave. The more specific our instructions, the less guesswork for the AI.

Provide Context and Constraints

AI assistants perform better when they understand boundaries. Telling an AI generator what framework we’re using, what data shape we’re working with and what the layout requirements are reduces guesswork.

Use Examples to Anchor Expectations

When describing a visual style or interaction pattern, referencing something concrete (“similar to a fintech dashboard” or “matching our existing sidebar navigation”) gives the AI a clearer target.

Iterate Rather Than Overload

A single massive prompt that tries to describe an entire application rarely works well. Starting with a focused request and refining in follow-up prompts produces more reliable results. Anthropic’s documentation specifically recommends chaining complex prompts for complex tasks, and OpenAI echoes this idea with their guidance on breaking tasks into subtasks.

Specify the Output Format

If we need responsive CSS Grid, we should say so. If we want TypeScript, it’s worth mentioning. Being explicit about the format we expect avoids unnecessary back-and-forth because AI tools tend to take our instructions quite literally.

With those principles as a foundation, let’s walk through the prompts.

1. Prompt for Scaffolding a New Project

The Task

We’re starting a new application and need a login screen plus an initial dashboard layout, which is one of the most common starting points for any React project.

Prompting Technique: Be Clear and Direct

The key here is to specify exactly what components and interactions we need upfront rather than asking for “a login page.” We describe the fields, the validation behavior and what happens after login.

The Prompt

#kendo_ui_generator I have an empty React application that needs a login  
screen and an admin dashboard. Add a login form with email and password  
fields, including validation for required fields and email format, using  
KendoReact form components. After successful login, redirect to an admin  
dashboard page with a collapsible sidebar menu on the left and a main  
content area on the right displaying three summary metric cards  
(total users, active sessions, revenue).  

Why It Works

Notice how the prompt spells out the validation rules (“required fields and email format”), the layout structure (“collapsible sidebar menu on the left”) and the specific metrics to display. The Agentic UI Generator doesn’t have to guess what “admin dashboard” means to us because we’ve told it exactly what to build.

Go deeper: The KendoReact Prompt Library has additional project setup prompts for more complex scaffolding scenarios.

2. Prompt for Building a Data Grid

The Task

We need a sortable, filterable data grid for displaying product catalog data, which is a very popular component request for enterprise React applications.

Prompting Technique: Provide Context and Constraints

AI assistants produce dramatically better grid implementations when we describe the data shape and the specific operations we need. Compare a prompt like “make a grid” (which will produce a generic table) with one that describes our columns, data types and desired interactions.

The Prompt

#kendo_ui_generator Create a KendoReact Grid component for a product  
catalog. The grid should display the following columns: product name  
(text, filterable), price (currency format, sortable), category  
(dropdown filter with predefined options), stock status (boolean  
displayed as a badge), and last updated (date format). Enable paging  
with 15 items per page, multi-column sorting, and row selection.  
Wrap the grid in a Card component with a header showing the total  
product count.  

Why It Works

We’ve specified the data types for each column (text, currency, boolean, date), the filter behavior per column (text filter vs. dropdown filter) and the grid-level features (paging count, sorting type, selection).

This level of detail maps directly to KendoReact Grid props like filterable, sortable, pageable and column-level format settings, which is exactly the kind of specificity the Agentic UI Generator needs to produce accurate code.

3. Prompt for Connecting a Chart to a Data Source

The Task

We want to add a chart that visualizes data alongside an existing grid, and both should respond to the same date range filter.

Prompting Technique: Describe Relationships Between Components

When multiple components need to share state or respond to the same filters, we have to make that relationship explicit in the prompt. The AI can’t infer that our chart and grid should be connected unless we tell it.

The Prompt

#kendo_ui_generator Add a new section to my page with a KendoReact  
Grid on the left and a Line Chart on the right. Above both, place a  
DateRangePicker. The grid displays sales data with columns for date,  
product, quantity, and revenue. The chart visualizes total revenue  
over time as a line series. Both the grid and chart should filter  
their data based on the selected date range from the DateRangePicker.  
Use a shared data source so both components update reactively when  
the date range changes.  

Why It Works

The phrase “shared data source” and “both components update reactively” tells the generator to wire up shared state rather than creating two independent components. Without this, we may get a chart and grid that look correct but don’t actually talk to each other.

4. Prompt for Creating a Responsive Page Layout

The Task

We need a responsive page that adapts across mobile, tablet and desktop breakpoints.

Prompting Technique: Specify the Output Format

Mentioning “CSS Grid,” “flexbox” or specific column counts at each breakpoint removes ambiguity about how the layout should be implemented. This is where OpenAI’s guidance on specifying output format really applies: the more concrete we are about the implementation approach, the more predictable the result.

The Prompt

#kendo_ui_generator Create a responsive dashboard page using CSS Grid.  
The layout should have 3 columns on desktop (above 1024px), 2 columns  
on tablet (768px to 1024px), and 1 column on mobile (below 768px).  
The top row spans the full width and contains a KendoReact Toolbar  
with a search input, a category DropDownList filter, and a "Create New"  
button. Below the toolbar, display 6 product Cards in the responsive  
grid. Each card shows a product image placeholder, name, price, and  
a rating indicator. Add consistent spacing between all grid items.  

Why It Works

We’ve defined exact breakpoints (1024px, 768px), column counts at each breakpoint and what “responsive” means for this specific layout. Without these details, “responsive” could mean anything from a single-column stack to a fluid grid with auto-sizing.

5. Prompt for Generating a Custom Theme

The Task

We want to create a dark mode theme that matches a specific aesthetic.

Prompting Technique: Use Examples to Anchor Expectations

When describing visual styles, concrete reference points tend to work much better than abstract adjectives. “Modern and clean” is subjective and can mean different things to different people. “Dark background with blue accent colors, similar to a developer tools interface,” gives the AI a much sharper target to work with. Both Anthropic and OpenAI recommend using examples in prompts, and for styling tasks, those examples can be descriptive comparisons rather than literal code samples.

The Prompt

#kendo_style_assistant Generate a comprehensive dark mode theme for  
my KendoReact application. Use a dark charcoal background (#1a1a2e)  
with light gray text (#e0e0e0). The primary accent color should be  
a muted teal (#16a085). Apply subtle border-radius (6px) to cards,  
buttons, and input fields. Increase spacing between UI components  
by 20% compared to the default theme. Ensure all interactive elements  
have visible focus indicators that meet WCAG 2.2 AA contrast requirements.  

Why It Works

We’ve given specific hex values rather than vague color names, defined the exact border-radius, quantified the spacing increase and specified the accessibility standard. The KendoReact Styling Assistant can translate these constraints directly into CSS custom properties without interpretation.

Want to go further with theming? Progress ThemeBuilder lets us generate and fine-tune complete design systems visually, including AI-powered theme generation where we can describe an aesthetic in plain English and get a full set of coordinated styles back.

6. Prompt for Adding Icons to a Navigation Bar

The Task

We need appropriate icons for a navigation menu.

Prompting Technique: Describe Intent, Not Just Position

Instead of telling the AI which icons to use (which means we’ve already done the work), describing the navigation items and their purpose lets the KendoReact Icon Assistant choose contextually appropriate icons from the KendoReact icon collection.

The Prompt

#kendo_icon_assistant I'm building a sidebar navigation for a project  
management app. Add appropriate icons for the following menu items:  
Dashboard (overview/home context), Active Projects (task/work context),  
Team Members (people context), Reports (analytics/chart context),  
and Settings (configuration context). Use SVG icons for better  
accessibility support.  

Why It Works

The parenthetical context hints (“overview/home context,” “analytics/chart context”) help the Icon Assistant understand the semantic meaning behind each menu item rather than just the label text, which tends to produce more thoughtful icon choices than simply asking for “icons for my nav.”

7. Prompt for Making a Grid Navigable by Keyboard

The Task

We have a Grid with custom cell templates containing interactive buttons, and keyboard navigation isn’t reaching them properly.

Prompting Technique: Describe the Problem, Not Just the Goal

For accessibility tasks, describing the specific interaction failure gives the AI enough context to provide a targeted solution rather than a generic checklist. A prompt like “make my grid accessible” is too broad to produce anything actionable, but describing exactly what’s broken narrows the problem space considerably.

The Prompt

#kendo_accessibility_assistant I have a KendoReact Grid with navigatable={true} and a custom cell in the "Actions" column that renders three buttons: "View Details," "Edit," and "Delete." Arrow keys move between the other cells as expected, but when the Actions cell is focused, pressing Enter does nothing and the three buttons stay unreachable from the keyboard. I want Enter or F2 to move focus into the cell, Tab and Shift + Tab to move between the three buttons, and Escape to return to cell navigation. The Grid should remain a single tab stop in the page tab order and meet WCAG 2.2 Level AA.

Why It Works

We’ve described the exact component setup (Grid with custom cell template), the specific failure (focus skips over buttons), the desired behavior (Tab into cell, arrow keys between buttons), and the compliance target (WCAG 2.2 Level AA). The KendoReact Accessibility Assistant can now provide a precise fix rather than a generic accessibility checklist.

8. Prompt for Building a Multi-Step Form

The Task

We need an employee onboarding form that collects information across multiple steps.

When the output itself is sequential (like a multi-step form), structuring our prompt to mirror that sequence helps the AI produce coherent, well-ordered results.

Prompting Technique: Structure in Steps
When the output itself is sequential (like a multi-step form), structuring our prompt to mirror that sequence helps the AI produce coherent, well-ordered results. Instead of describing all four steps in one paragraph, we give each step its own block with its own fields, components and validation rules. The prompt ends up shaped like the thing we’re asking for, which leaves the generator less room to merge two steps or quietly drop a field.

The Prompt

#kendo_ui_generator Create a 4-step employee onboarding form using  
KendoReact Stepper and Form components.  
  
Step 1 - Personal Info: Name (required), email (required, validated),  
phone number fields. Show a user icon in the step header.  
  
Step 2 - Job Details: Department selection using a DropDownList with  
options (Engineering, Marketing, Sales, HR, Finance), role text input,  
and start date using a DatePicker. Show a clipboard icon.  
  
Step 3 - System Access: A CheckBoxGroup for system permissions  
(Email, VPN, Dev Tools, Admin Panel) and a password field with  
confirmation. Show a lock icon.  
  
Step 4 - Review: Display a read-only summary Card showing all entered  
data from previous steps, with a Submit button.  
  
Add validation that prevents advancing to the next step until required  
fields are completed.  

Why It Works

Each step is clearly delineated with its own fields, components, icons, and validation requirements. The generator can produce each step as a discrete unit while still maintaining the shared state needed for the review step. Compared to a single-paragraph prompt trying to describe all four steps at once, the structured format is far easier for both humans and AI to parse.

9. Prompt for Transforming an Existing Layout

The Task

We have a carousel-based feature section that needs to be converted to a responsive grid.

Prompting Technique: Iterate Rather Than Overload

This prompt shows the “refinement” approach. Rather than describing an entire page from scratch, we’re asking the generator to modify one specific section. When working with existing code, targeted modification prompts consistently outperform full-page regeneration prompts because the scope stays manageable and the output stays predictable.

The Prompt

#kendo_layout_assistant I have an existing carousel feature section  
on my page that displays 6 feature cards. Replace the carousel with a  
responsive 3-column CSS Grid layout. Display 3 columns on desktop  
(above 1024px), 2 columns on tablet (768px-1024px), and 1 column on  
mobile (below 768px). Keep the existing card content and styling but  
add consistent 16px gap between grid items and ensure proper vertical  
alignment when cards have different content heights.  

Why It Works

We’re being surgical about what to change (the carousel) and what to keep (the card content and styling). This constraint prevents the generator from unnecessarily rewriting parts of the page that are already working.

10. Prompt for Adding a Real-Time Data Dashboard Section

The Task

We need to add a monitoring section to an existing page with KPIs, charts and a live data feed.

Prompting Technique: Combine Context with Clear Component Mapping

For complex, multi-component layouts, mapping each UI element to a specific area of the page eliminates ambiguity. Instead of listing components and hoping the AI figures out the arrangement, we describe the spatial layout explicitly.

The Prompt

#kendo_ui_generator Create a system monitoring dashboard section using  
a 3-row by 3-column responsive grid.  
  
Top row: Three KPI Cards showing CPU Usage (percentage with a circular  
gauge), Memory Usage (percentage with a progress bar), and Error Count  
(numeric with a trend arrow indicator).  
  
Middle row: A scrollable Log Stream panel on the left (1 column), a  
Line Chart showing API response times over the last hour (center,  
spanning 1 column), and a Bar Chart showing requests per service  
(right, 1 column).  
  
Bottom row: A Grid showing recent deployment history with columns for  
timestamp, service name, version, and status (spanning 2 columns),  
and a ListView showing the 5 most recent alert notifications  
(1 column).  
  
Make all sections responsive: stack vertically on mobile, 2 columns  
on tablet, full 3-column layout on desktop.  

Why It Works

The row-by-column mapping makes the spatial layout completely unambiguous since each cell has a defined component, data format, and visual treatment. Specifying the responsive behavior once at the end rather than repeating it for every cell also keeps the prompt efficient and readable.

Tip: For complex, multi-section layouts like this, tools like Claude Code and Cursor offer a “Plan” mode that breaks down large requests into smaller steps before generating code. If a single prompt feels like it’s trying to do too much, letting the AI plan first and then execute step by step can produce more reliable results, especially when multiple components need to coordinate with each other.

Quick Reference Card

Here’s a summary of the prompting techniques used throughout this cookbook and when to reach for each one.


Image generated with AI

TechniqueWhen to Use ItExample
Be clear and directStarting a new component or page“I need a login form with…”
Provide context and constraintsWorking with data-heavy components“The grid has these columns with these types…”
Describe relationshipsMultiple components sharing state“Both should filter based on the same…”
Specify output formatLayout and responsive work“CSS Grid with 3 columns above 1024px…”
Use examples to anchorStyling and theming tasks“Dark charcoal background (#1a1a2e) with…”
Describe intent, not just positionIcons and semantic choices“Dashboard (overview/home context)…”
Describe the problemAccessibility and bug fixes“Focus skips over these buttons when…”
Structure in stepsSequential flows“Step 1: … Step 2: … Step 3: …”
Iterate, don’t overloadModifying existing layouts“Replace the carousel with a grid, keep existing…”
Map components to spatial positionsComplex multi-component dashboards“Top row: … Middle row: … Bottom row: …”

Next Steps

This simple cookbook covers starter-level prompts for getting up and running with the KendoReact Agentic UI Generator, but there’s quite a bit more to explore for advanced scenarios.

The AI tooling landscape is moving fast. New models, new editor integrations, and new capabilities seem to land every few weeks. However, the prompting fundamentals we’ve covered here (e.g., being specific, providing context, iterating in steps, etc.) tend to hold up regardless of which model or tool we’re working with. Getting comfortable with these patterns now means we’ll be able to adapt quickly as the tools continue to evolve.

The full KendoReact Prompt Library has additional prompts and component-specific examples, while the KendoReact MCP Server documentation covers setup and configuration in detail. For a deeper dive into the prompting principles referenced throughout this guide, both Anthropic’s prompting best practices and OpenAI’s prompt engineering guide are worth bookmarking as resources that apply well beyond any single tool.

If the prompts in this cookbook look useful, start a free KendoReact trial and give them a try!

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete

Navigating the Microsoft AI Agent Builder Associate (AB-620) Certification Exam: A Comprehensive Study Guide

1 Share

If you’re setting your sights on the Microsoft AI Agent Builder Associate (AB-620) certification, you’re likely already aware of its focus—Copilot Studio. This exam zeroes in on building scalable AI agents pivotal to enterprise AI development. Having recently taken the exam myself, I want to distill what I’ve learned into a guide that can help you pass with ease.

For those gearing up for the AB-620, I’ve compiled a comprehensive study guide emphasizing the essential concepts you need to tackle: from Microsoft Copilot Studio and agent orchestration to enterprise integrations and multi-agent architectures. Our journey will navigate through Model Context Protocol (MCP), Agent2Agent (A2A), adaptive cards, and more. This preparatory journey isn’t just a rote memorization of facts—it aims to impart an understanding of underlying principles and technologies, designed to build your confidence for the exam.

Based on content from Citizen Developer

Whether you’re a developer, consultant, or architect involved with Power Platform or Microsoft 365 Copilot, this pathway offers insights into the exam’s core objectives, from agent orchestration fundamentals to enterprise data sources and agent evaluations.

Key Study Areas

  • Agent Orchestration: Understanding how multiple specialized agents can collaborate effectively in complex scenarios. Agent orchestration isn’t merely about inter-agent communications; it includes how an agent acts as an orchestrator, deciding when to invoke various tools and knowledge resources.
  • Knowledge and Enterprise Data Sources: You’ll need to understand how business context can ground your agents, helping them generate appropriate responses based on enterprise data.
  • Tools and User Interactions: Familiarize yourself with adaptive cards, custom connectors, and REST APIs, pivotal in extending agents’ capabilities for real-world tasks like notifications and record management.
  • Agent Architecture: Knowing the distinction between child agents and connected agents is crucial, as it influences how your AI solutions scale and interact within an organizational framework.
  • Evaluation and Lifecycle Management: Application Lifecycle Management (ALM) is a cornerstone, as is understanding agent evaluations and the performance criteria that determine success in real-world applications.

Our starting point examines agent orchestration, a cornerstone of agent ecosystem development. Here, the agent itself acts as an orchestrator, leveraging tools and capabilities to pull knowledge and make decisions, emphasizing how the agent’s role goes beyond simple command execution to involve intelligent decision-making.

When constructing agents, the interplay between knowledge and tools is vital. Where knowledge empowers your agent to answer questions, tools enable it to perform actions like updating records. Grasping this distinction is critical—especially for exam scenarios where nuanced understanding can provide the answer.

Finally, let’s not overlook the importance of integrating agent evaluations into your study. While these evaluations seemed understated in the Microsoft Learn modules, the exam showed them to be significant, making up a considerable portion of the exam content.

Ultimately, if you aim to master the exam, understanding the modular composition of AI agents and their orchestration through tools and knowledge is paramount. Though the AB-620 is challenging, familiarizing yourself with the exam’s landscape can make it a platform for your aspirations in AI-driven solutions.

For additional resources, download the AB-620 Study Guide Slides and explore more from Microsoft’s training courses here.

If you have questions or require more personalized guidance, feel free to arrange a one-on-one session via Calendly. For continued insights and guidance, connect with me on LinkedIn, and visit Citizen Developer to dive deeper into this realm.

Good luck as you embark on your certification journey!

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories