Prompts Are Engineering Artifacts.
Treat Them Like It.
Most prompts get written, copy-pasted, and forgotten. No tests. No version history. No way to compare two approaches. Promptvexity replaces that workflow with a structured one borrowed from how software actually gets built.
Prompt engineering is mostly vibes.
You write a prompt. It works in your head. You ship it. It fails in production. You tweak a word. Maybe it works better. You can't tell.
There is no commit history. No diff between v1 and v2. No way to know if you actually improved the prompt or just got lucky on a different sample. Two engineers solving the same problem produce wildly different prompts and there is no shared yardstick to compare them.
Problem. Prompt. Score. Improve.
A four-step cycle that makes prompts measurable. Each stage produces an artifact the next stage can reason about.
Frame the outcome
Industry context, primary goal, example input, expected output, known failure modes, success criteria. Constraints are explicit, not implied.
Engineer the input
System prompt, user template with variables, model choice, parameters, usage context, tradeoffs. A prompt is a contract, not a sentence.
Run it, keep the receipt
Prompts are executed against real models and every call is kept: the exact input, the output that came back, and what it cost. No single number standing in for whether something works.
Iterate with lineage
Fork the prompt. Note what changed. Compare versions head-to-head on the same problem. The history is the artifact.
A number you cannot check is not evidence.
Every prompt carried a Quality Score out of 100. It stopped being calculated on 10 August 2026 after we checked it: the fifth unanimous upvote moved one prompt from 63 down to 56. What is left is smaller, and every part of it says plainly what it does and does not establish.
The same standard decided which problems exist at all. Read the falsification record, including the candidates that were dropped because no model failed them.
Recorded runs
Prompts were run against real models and whatever came back is stored verbatim, including the 67 responses that came back empty and the 80 the model cut off at its token ceiling. The exact input sits next to the output, so you can send the same request from your own client and compare. It is a record of what happened, not a judgement of whether it was good.
Community signal
Upvotes, downvotes, and Worked or Failed reports from people who say they used the prompt. The leaderboard ranks on a Wilson score lower bound of the votes, so an upvote can never move a prompt down it. The ranking is recomputed on a schedule, not on every vote.
Declared tests
A table for declared test cases and assertions exists in the schema. It holds zero rows. Until it is filled, nothing here has been checked against a stated expectation.
Every fork tells a story.
When you fork a prompt, the new version keeps a pointer to the parent. The fork summary explains what changed and why. The depth metric tracks how many iterations away from the root the prompt is.
A great prompt is rarely the first attempt. The lineage view shows the path: which version added an output format, which one tightened a constraint, which one finally beat the baseline.
Authorship compounds.
Reputation is built from the quality of your prompts and the validation they earn. Tiers act as a credibility signal so readers know whose work has been battle-tested.
View the tier systemPick a problem. Write a prompt. See the number.
The methodology is only useful if you run it. Start with a real problem from the catalog and submit your first scored prompt.