If you’ve not already, I’d encourage you to check out the first two articles in this series. It’ll make more sense and hey, you might even enjoy it.
Recap: I’ve been documenting my experience of learning about both DX Components and vibe coding, from the perspective of somebody who hasn’t had an actual coding job since Lord of the Rings was riding high at the box office. Last time, I talked about the setup: Node, VS Code, Git, Github Copilot in agent mode, and the one thing that had really helped me - a guide.md file, seeded from the constellation-ui-gallery, that turned Copilot’s output from “generic React widget that happens to mention Pega” into something that actually looked like a real DX Component. I called it the single biggest quality multiplier I’d found, and I stand by that.
But, it turns out, I was just getting started
The dirty secret of guide.md
That brilliant guide.md lived in exactly one place: my workspace, on my laptop. Every time I started a new project, I recreated it. Every time a colleague wanted the same results, they started from zero. And every good component still depended on me remembering to feed Copilot the right context and to get the right phrasing for the prompt.
It worked, but it just didn’t scale – I couldn’t hand it out, it wasn’t maintainable in any real sense. And although I’d always got good results, the very nature of LLMs means that every guide.md produced through prompting was going to be different. Furthermore, a newcomer had no way to tell one of Copilot’s genuine DX patterns from a confident, plausible-looking hallucination. Fundamentally: guide.md made one developer reliably good. It did nothing for the person sitting next to me.
And so one day, talking with my good friend, colleague, and all-round Pega superstar Andi Mutlow, he suggested that what we really needed was a skill. A what, I asked? So, without too much rolling of eyes, he did the hard work of taking everything from parts 1 and 2 - plus everything we’d learned the hard way shipping real components - and packaged it into a formal skill.
What a skill actually is
If you’ve only ever “pasted context into a prompt,” a skill is the grown-up version of that. It’s a self-contained bundle - instructions, best practices, reference patterns, naming conventions, setup steps, and validation - that the AI agent pulls in automatically when it recognises you’re building a DX Component. Effectively it’s a pre-built set of instructions to achieve a particular result.
What we baked in
All the stuff that used to live in my head or my notes now lives in the skill:
• The constellation-ui-gallery conventions and the PCore/PConnect patterns, so components read and write values the Pega way rather than the React way.
• Project scaffolding and naming conventions, done consistently every time.
• The App Studio gotchas - including that property-panel rendering error I lost an hour to in part 2. It’s now prevented, not debugged.
• The “what not to ask for” list - the anti-patterns I learned by getting burned, so nobody has to relearn them.
Hands-on 1: the same thermometer, two ways
Remember part 2’s thermometer? Here’s how I used to start, from a clean workspace:
You are an expert front-end developer familiar with React and also a Pega Lead System Architect. You are setting up an environment to build Pega DX Components. Install a DX Component Builder environment against server “[…]”. Then pull the constellation-ui-gallery from GitHub, examine every example in detail, and write a guide.md capturing the best practices you need to build high-quality, design-system-compliant components…
…and only then did I describe the thermometer.
Here’s how it looks now:
Build a DX Component that renders an integer property as a thermometer, 0–100, with the indicator colour graduating smoothly from blue at the bottom to red at the top.
The key difference is that all the setup, all the introspection & learning, all the reasoning up-front has already been done. This gives two key advantages – firstly, it’s consistent. There’s no chance of the model hallucinating or just setting things up differently, because the instructions and context are pre-set. And secondly, it’s much cheaper in terms of token cost, because the LLM doesn’t need to work out what to do each time – it just reads the instructions from the skill. So the end result is a cleaner, cheaper, more consistent setup. And you end up with the same component for a fraction of the scaffolding cost - and, crucially, identical quality whether it’s me typing it or someone on their first day.
Hands-on 2: a brand-new component, prompt to published
Let’s do a fresh one - a star-rating input, which is more interesting than it sounds, because unlike the thermometer it has to write a value back into the case, not just display one. That’s exactly the kind of PCore/PConnect wiring the skill handles for you.
The first prompt:
Build a DX Component that lets a user rate something from 1 to 5 stars. Clicking a star sets the property value; hovering previews the rating. Take the current value as input and write the selected value back to the property.
Right first time - clickable, with the hover preview and the value writing back correctly.
Done. Then published to App Studio and dropped onto a view, where a system architect can configure it with no code at all. And this time, no property panel errors, no “this doesn’t work” – everything was right where it needed to be, first time, no issues. That’s why we use a skill.
And, just because, why not do a bit of on-the-fly refinement:
Two changes: let me configure the maximum number of stars (default 5), and show the numeric value next to the stars as “3 / 5”.
Total time, prompt to published: about 20 minutes. And the person building it doesn’t need to know what PConnect is.
And away we go
The magic of part 2 was never really the prompt. It was the context behind it. A skill just takes that context out of my head - and off my laptop - and makes it something a whole team can pick up and run with.
So much for the setup. It’s time for something more, shall we say challenging. So next time we’re going to look at how to move beyond simple text prompts and components that simply display some data to something…well, let’s not spoil things. But I promise you it will be worth it.
Until then - a few questions for the comments:
• What’s the first thing you’d package into a skill?
• Where do you draw the line between “let the AI do it” and “I need to understand this myself”?
• What component have you been putting off building because the setup felt like too much?