There is a big difference between asking AI to generate code and teaching it how a specific engineering workflow should behave.
That difference became clear while I was working on a repeatable way to create custom widgets for a Sitefinity ASP.NET Core Renderer project. At first, the problem sounded simple: generate a widget. But in a real codebase, that does not only mean creating a ViewComponent and a Razor view. A good widget needs structure. It needs a clear separation between persisted configuration, business logic, view data, and rendering. It needs predictable folders, interfaces, models, view models, entities, comments, and naming conventions.
I did not just need code generation. I needed the AI to understand a pattern.
That led me to create a Claude skill focused on generating Sitefinity Renderer widgets using a consistent architecture. The final result was not a single prompt. It became a small, reusable package of instructions, references, templates, and validation rules that Claude could load when the task required it.
The value was not only that the skill worked. It was the process of turning documentation and preferences into something closer to an engineering workflow.
Starting with the workflow, not the prompt
The first mistake with AI-assisted development is often starting with a long prompt.
A long prompt can work once. It can be useful for exploration, quick scaffolding, or a one-time implementation. But when a task is repeated, a prompt starts to become fragile. You have to remember the same instructions again, explain the same conventions again, and correct the same mistakes repeatedly.
For this case, I wanted something more durable. The goal was to create a skill that could help generate a Sitefinity Renderer widget with a specific structure:
- A ViewComponent responsible for invoking the widget
- An Entity responsible for persisted widget properties
- A Model responsible for the business logic
- An Interface for the model
- One or more ViewModels for the data consumed by the Razor view
- A Default.cshtml view inside the expected component folder
- XML comments on generated classes, methods, and properties
I also needed a clear rule that the ViewComponent should delegate work to the model instead of carrying business logic directly.
That gave the skill a real purpose. It shifted the objective from "help me generate a widget" to "generate a widget the way this project expects widgets to be built." When the workflow is clear, AI becomes less of a guessing engine and more of an execution partner.
Using documentation as the foundation
The skill was not built from memory alone. I used three distinct inputs to ground it.
The first input was the Claude skill guide. That gave me the structure of the skill itself: the required SKILL.md file, the optional references folder, reusable assets, scripts, and the idea of progressive disclosure. Instead of putting every detail into the main instruction file, the skill could keep the core behavior visible and move deeper rules into references that Claude could consult when needed.
The second input was the official Sitefinity documentation. That gave the skill the correct mental model for ASP.NET Core Renderer widgets. In Sitefinity Renderer projects, widgets map naturally to ASP.NET Core ViewComponents. The widget can have an Entity for persisted configuration, a Model for logic, and a ViewModel for view data. That aligned well with the structure I wanted to enforce.
The third input was public GitHub repositories from Sitefinity. Documentation explains the concepts, but repositories show real implementation patterns. Samples and built-in widgets are useful because they reveal naming, folder structure, and practical conventions that are easy to miss when reading docs alone.
This combination mattered. AI works better when the input is a context package rather than just a raw request. The guide explained how to build the skill, the Sitefinity docs explained the architecture, and the repositories helped ground the output in real examples. My own project rules filled the gap between generic documentation and the standards I actually wanted in the codebase.
The first version worked, but it exposed a hidden assumption
The first version of the skill was already useful. It generated the components I needed and followed the general architecture. That was a good sign, but it also exposed a problem.
Claude understood the idea of entities, models, view models, components, and interfaces. It did not, however, always create them as separate physical files. In some cases, it compressed multiple types into fewer files. Technically, the code could still make sense, but architecturally it was not what I wanted.
The lesson learned: Some rules are not obvious to AI, even when they feel obvious to a developer.
For me, "create a model, a view model, an entity, an interface, and a component" implied separate files. But unless that rule was explicit, the model could optimize for compactness instead of maintainability.
This is where the skill improved from a helpful generator into something more reliable. The next version introduced strict file separation rules. One public type per file. No combining Entity, Model, ViewModel, Interface, or ViewComponent into the same .cs file. Generate a file manifest before writing code. Create additional types in their own files when needed.
That small change made a big difference. The AI did not need more intelligence; it needed clearer constraints.
Turning preferences into enforceable rules
One of the best parts of building a skill is that it forces you to define what "good" means.
Before this process, some of my expectations lived as habits. I knew I preferred logic in the model. I knew I wanted clean ViewComponents. I knew the entity should represent persisted widget settings. I knew each type should live in its own file. I knew generated code should include XML comments.
But those expectations were implicit. The skill made them explicit.
That is valuable because explicit rules can be reused, tested, and improved. Once the skill had a reference file for file separation rules, a template for the expected manifest, and a validation script to check the generated structure, the workflow became much more dependable.
This is where AI-assisted development becomes more interesting than simple code generation. The value is not only in producing files faster. The value is in encoding architectural decisions into a repeatable process.
A good skill can carry project knowledge forward. It can remind the AI what should happen before code is written. It can define what files should exist, describe where logic belongs, and include examples, failure cases, and review steps. That reduces the amount of correction needed after generation. It also reduces the chance of accepting code that works technically but does not fit the project.
Planning and design are part of the output
What stood out about this process is that the skill became a planning tool, not just a generation tool.
Before writing code, the skill can ask for or infer the widget purpose, identify needed properties, map the Entity, define the ViewModel, decide what logic belongs in the Model, and produce a file manifest. That gives the implementation a shape before any class is created.
This mirrors how I prefer to work manually. I do not want to start with random files and clean them later. I want the structure to make sense from the beginning. The skill helps Claude follow that rhythm.
For a Sitefinity widget, that means the generated code should answer a few questions before implementation starts:
- What properties does the editor need to configure?
- What data does the view actually need?
- What logic should be kept away from the Razor file?
- What dependencies should be injected into the model?
- What should the ViewComponent do, and just as important, what should it not do?
Once those decisions are clear, the code becomes easier to generate and easier to review.
Extending the skill over time
The first version of a skill does not have to be perfect. In fact, it probably should not try to be. The better approach is to use it on a real task, observe where it fails, and then convert that failure into a rule.
That is exactly what happened here. The first version proved that the general idea worked. The second version fixed the file separation issue. A future version could add a post-generation review step, stronger validation around dependency injection registration, or examples for more advanced widgets that query Sitefinity content using services.
This makes the skill feel less like a static document and more like a small engineering asset. Every time the AI misses an expectation, there is an opportunity to improve the skill. Every repeated correction can become a rule. Every pattern that works well can become an example. Every common mistake can become a checklist item.
That is a much better loop than rewriting the same prompt again and again.
What this changed for me
The biggest improvement was not speed, although the workflow became faster. The biggest improvement was consistency.
With the skill enabled, the AI had a clearer understanding of the expected architecture. It generated widgets in a way that was closer to how I would structure them manually. The output required less correction, and the review became more focused on business behavior rather than basic organization.
That is the kind of AI assistance I find most useful. Not magic. Not autopilot. Not replacing engineering judgment. Just a practical way to capture decisions and reuse them.
The process also reinforced a broader lesson: AI works better when it has constraints. Good constraints do not limit creativity in a harmful way. They remove ambiguity. They tell the model which decisions are already made so it can focus on the parts that still need thinking.
Most real projects do not suffer because no one can generate code. They suffer because code is generated without enough context, without enough structure, and without enough respect for the existing architecture. A skill helps close that gap.
Final thought
Creating this Claude skill reminded me that the future of AI-assisted development is not only about better models. It is also about better instructions, better workflows, and better ways to package technical knowledge.
A well-designed skill turns experience into reusable guidance. It lets documentation, examples, project conventions, and personal engineering judgment work together. Once that happens, AI stops feeling like a blank chat box and starts feeling more like a tool that understands how the work should be done.