What this prompt does
This prompt asks the AI to build a complete C# incremental source generator for a [generator_purpose] targeting a specific [dotnet_version]. Rather than producing a single snippet, it walks the whole pipeline: analyzer project setup, defining a [trigger_attribute] with [attribute_options], the syntax provider that finds decorated classes and pulls out [extracted_info], emitting the [output_type], and diagnostics for [error_scenarios]. The structure mirrors how an incremental generator actually executes — syntax provider, transform, output — so the generated explanation tracks the real Roslyn pipeline instead of a toy example.
The variables shape how concrete the answer gets. [generator_purpose] and [output_type] decide what the generator emits, while [cache_invalidation] forces the model to address the part people get wrong: making the incremental cache only rerun when the relevant inputs change. Because the prompt explicitly requests #nullable enable, partial-class-friendly output, and proper namespaces, the generated code is closer to something you can drop into a real project. The eight numbered steps also keep the model honest: it cannot hand-wave the testing or debugging phases because each one is requested explicitly, and the result reads like a checklist you can follow end to end.
When to use it
- Boilerplate (DTOs, mapping code, DI wiring) is becoming a maintenance tax across a codebase
- You want compile-time generation instead of runtime reflection for performance
- Building strongly-typed wrappers from interfaces like
IOptions - Adding a
[trigger_attribute]so teammates can opt classes into generation - You need a worked example that includes the diagnostics and caching most tutorials skip
- You want a testable generator with unit tests verifying the emitted output
Example output
You get a structured walkthrough: an analyzer project file, the [trigger_attribute] definition, a syntax provider class, the generation logic emitting your [output_type], diagnostic descriptors for [error_scenarios], a unit test using Microsoft.CodeAnalysis.CSharp.Testing, and debugging instructions for attaching a debugger. Expect multiple code blocks tied together by explanation rather than one monolithic file.
Pro tips
- Be specific in
[generator_purpose]and[output_type]— "generate DI extension methods from[GenerateOptions]" yields tighter code than a vague goal - Pin
[dotnet_version]to your actual Roslyn version; generator APIs shifted across versions and a mismatch produces code that won't compile - Treat
[cache_invalidation]as the most important field — name exactly what should retrigger generation, or the generator reruns on every keystroke - List real
[error_scenarios](attribute on a non-partial class, unsupported property types) so the diagnostics are useful instead of decorative - If the first pass skips the caching or debugging step, ask for it explicitly — those are the steps that matter most in production
- Keep
[attribute_options]minimal at first; you can iterate to add validation flags once the core pipeline compiles - Be precise about
[extracted_info]; if you only need property names but ask for full type symbols, the syntax provider does more work than necessary and the cache key gets noisier - Generate into partial classes so users can extend the output by hand without their additions being overwritten on the next build
