Prompt Variant

A prompt variant is a deliberate twist on a single tested prompt spine. The spine contains the five-part anatomy: system role, scope, real examples, hard constraints, and fixed output format. Variants keep four of those five parts untouched and only adjust the surface configuration so the prompt behaves differently without forcing the team to maintain parallel copies. Size variants run short for speed or long for depth. State variants adjust strictness thresholds. Role variants flip the system block from critic to generator while the rest of the prompt stays identical. The variant matrix lives in the library like a Figma component set. Update the spine once and every variant inherits the improvement. The teams moving fastest in 2026 treat this matrix as infrastructure instead of yet another Slack thread of copied text.

This is not a brand new prompt written from scratch every time requirements shift. It is not a messy fork where examples and constraints drift in separate directions until nobody trusts anything. It is not version control. Versions track sequential improvements over time with evals and semver. Variants are parallel expressions of the same version. Teams that ignore this distinction end up with the classic 2025 failure pattern: seventeen files named hero_critique_v4_final_use_this_one.md scattered across Notion, Cursor rules, and private Claude projects. When Claude 3.7 dropped that summer the outputs went off the rails in four places and nobody could trace which copy was canonical. Variants prevent that waste.

The Linear design team shipped a concrete example in Q1 2026 that still gets copied. Their checkout-flow-critique spine named the model as a senior product designer who had shipped at Stripe and Ramp. Scope locked it to friction analysis only. They embedded three approved checkout flows from their own Q4 2025 shipped work plus three flows the team had rejected for creating decision fatigue. Constraints banned any suggestion requiring engineering changes outside the frontend and forbade the phrase imagine. Output locked to JSON with rubric scores, confidence, and suggested edits. From that spine they created the variant matrix. Size-short dropped to one example, skipped the full rubric, and returned in under 80 tokens for live critique inside Cursor during pairing. Size-long kept everything and added a 400-token brand alignment section for the overnight eval pipeline. State-lenient raised the acceptable friction threshold for early concepts. State-strict lowered it to ship-review levels and added an extra constraint around accessibility. Role-author flipped the system sentence so the model generated new checkout copy instead of critiquing existing copy. All six variants shared the same git-tracked spine file. When the team added a new rejected example in April the change hit every variant at once. The eval suite ran against the fixed test set of fifty real checkouts and only merged after scores improved or held steady.

Stripe ran a similar matrix for their brand-audit prompt the same year. The reviewer role variant scored homepage heroes against the voice rubric with zero tolerance for off-brand colloquialisms. The author role variant used the identical examples and constraints but generated new hero lines that matched the tone. The short variant lived as a Claude Skill triggered by highlight in the browser. The long variant fed structured data into their custom eval dashboard built on Anthropic Workbench. One spine, four surfaces, zero duplicated maintenance. The prompt librarian ran the matrix through CI on every model update and deprecated variants that stopped clearing the 92 threshold.

Use variants the moment a prompt has survived three model updates, earned real shipping mileage, and carries evals above 90 against your rubric. That is usually week six or seven. Deploy them when the same logic must serve the fast IDE loop, the deep eval pipeline, client presentations, and internal QA gates. Add a new column to the matrix when a new surface appears. Never create variants for prompts still in discovery. Those belong in the experimental folder until they prove repeatable value. Never build more than three dimensions or the matrix becomes its own cognitive debt. Two or three variants per dimension is the practical ceiling. Size, state, role. Nine total. Clean. The prompt librarian owns the matrix, rejects pull requests that break the spine, and keeps the variant map updated in the README.

Teams that skip variants waste hours every week rewriting prompts that should have been configuration tweaks. Teams that over-use them create library bloat that new hires cannot navigate. The sweet spot sits at the intersection of proven spine and clear matrix. Build the spine first. Test it brutally. Then spin the variants and watch one prompt replace what used to be eight separate maintenance headaches.

Prompt variants turn one reliable spine into a force multiplier that actually stays maintained.