Angel Espinoza

Sample Prompts

Prompts to start from, not copy exactly.

Fill in the brackets. Everything else is the part that tends to stay the same.

These are not the actual prompts from any specific build. They are the shape of the prompts that work, generalized so you can start from them. Swap the bracketed parts for your own task and your own domain.

Starting a new tool

I need a [Civil 3D plugin] that [labels a picked point with its MGRS coordinate]. [C#, one command, one clean undo].

Name the single thing it does, not the eventual five things.

Before you write anything, tell me what you would need to know about [how MUTCD sign geometry actually works] to get this right, and I will answer.

Useful when you are not sure the starting context is right yet. It catches a wrong assumption before any code exists.

Start with just [the hub and project browsing screen, no standards checking yet]. Nothing else yet.

Complex tools still start narrow.

Adding a feature to something that already works

Add [a slope heatmap overlay on the terrain]. It should [color the surface by grade as soon as I pick a point]. Reuse [the raycasting and pick-point logic that already works], and do not touch it.

Naming what should stay untouched keeps a working feature from becoming collateral damage in the next one.

This needs to fit the pattern already used in [the panel that shows properties for whatever is selected], not a new one.

Keeps a growing tool internally consistent instead of accumulating several different ways of doing the same thing.

Fixing something that is wrong

[The point count in one classification bucket] is [higher after a rerun than the raw scan], not [lower like the filter should produce]. Walk through where [that classification value] actually gets set and fix it there, not by patching the output afterward.

Fixing the cause instead of the symptom is the difference between looks-right and is-right.

That is not the actual bug. [Explain why, in your own words.] Look again.

You do not have to be able to write the fix. You have to be able to say what is wrong with it, in your own vocabulary. See "I am not a programmer" on the Why AI page.

Verifying before you trust it

Test this against [the full sign and pole set, not just a sample], including [the asset closest to the polygon budget]. Confirm the count for every asset before I trust it.

Not once, at the end, but continuously, the way you would check a junior engineer's work before your name went near it.

Show me exactly what changed, file by file, before I approve it.

One clean, reviewable change beats a large one you have to take on faith.

Be Better! ...start with the thing you do forty times.