Few-Shot Examples for Component Naming

1. 01

   Find gray cases

   Run with rules only. Catch failures and uncertainty.

2. 02

   Label by hand

   Input, correct output, one-line reason.

3. 03

   Wrap in XML

   After rules, before the task block.

4. 04

   Test on fresh batch

   Verify the fix held without regressions.

What this guide covers

I labeled 20 component names by hand. Claude got 19 out of 20 right on the next batch of 200. The 20 that took me an hour saved me a week.

This guide explains how to do that. It works for component naming, token naming, variant naming, and basically any pattern where you have a fuzzy rule that you cannot fully articulate but you know the right answer when you see it.

The premise

Claude is good at pattern matching. You do not need to write a perfect rulebook. You need to show enough examples that the pattern becomes obvious.

The trick: do not waste examples on easy cases. The first 80% is easy. The last 20% is gray. Examples are for the gray.

Step 1: find the gray cases

Run Claude on a sample batch with no examples, just rules. Then read the output. Look for:

• Cases where Claude guessed and got it wrong
• Cases where Claude guessed and got it right but for the wrong reason
• Cases where Claude said “I am not sure” (those are gold)

These are your candidates. Pick five to ten of them.

Step 2: label them by hand

For each case, write:

1. The input (the component, the design, the brief)
2. The correct output (your name, your token, your decision)
3. A short reason (one sentence on why this is correct)

The reason matters. Without it, Claude pattern-matches on surface features. With it, Claude pattern-matches on the underlying rule.

Example for a button-like component that is not actually a button:

Input: A small clickable element with an icon and short label, used in a toolbar to toggle a panel.
Output: ToolbarToggle
Reason: This is not a Button because it does not perform an action. It changes the state of a panel. Toolbar prefix because it lives in the toolbar surface. Toggle because it has on/off semantics.

Step 3: structure them in the system prompt

Wrap the examples in XML tags. Claude is fine-tuned on XML and respects the structure. Put them after your rules and before the immediate task block.

<naming_rules>
  Components are named with PascalCase.
  Compound components use a dot (Card.Header).
  Variants are not in the name. They are a prop.
  ...
</naming_rules>

<examples>
  <example>
    <input>A small clickable element with an icon and short label, used in a toolbar to toggle a panel.</input>
    <output>ToolbarToggle</output>
    <reason>Not a Button because it does not perform an action. It changes panel state. Toolbar prefix because of surface. Toggle because of on/off semantics.</reason>
  </example>

  <example>
    <input>A pill-shaped element showing a count, placed next to a navigation item.</input>
    <output>Badge</output>
    <reason>Communicates a quantity, not a status. Badge is the standard term for count indicators. Not Tag because Tag implies user-applied metadata.</reason>
  </example>

  <example>
    <input>A row in a table that can be expanded to show more detail.</input>
    <output>DataTable.Row.Expandable</output>
    <reason>Compound component. DataTable is the parent. Row is the child. Expandable is a sub-variant of Row that has its own behavior.</reason>
  </example>
</examples>

<task>
  Name this component. Use the rules and examples above.
  [component description here]
</task>

Step 4: test on a fresh batch

Run the prompt on 20 to 50 components Claude has never seen. Read the output.

• If Claude is now correct on the cases that were previously gray, your examples are doing the work.
• If Claude is still wrong, your examples are either too narrow (not covering the failure mode) or too vague (not encoding the rule). Add or revise.

This is the iterative loop. Most teams stop too early. The first round of examples gets you 90% accuracy. Two more rounds get you 99%.

When to stop

You can stop adding examples when:

• The remaining errors are genuinely ambiguous (a human reviewer would also be uncertain)
• The marginal improvement from one more example is below your threshold
• You have started writing examples that contradict each other (this means your rules are inconsistent, not your prompting)

If you reach the third state, stop and fix your design system, not your prompt.

Real applications

This works for:

• Component naming. New components get a name that fits the system.
• Token naming. New design tokens get semantic names that match your conventions.
• Variant decisions. Should this be a variant or a new component? Examples teach the boundary.
• Audit triage. Which issues are critical, which are nice-to-have? Examples teach severity.
• Accessibility flagging. What counts as a real accessibility issue versus stylistic preference? Examples teach the line.

Anything that involves a fuzzy rule and a human “you know it when you see it” judgment is a candidate.

Why this beats writing a rulebook

I have tried writing exhaustive rulebooks. They take days, they get out of date, and they fail on the cases the author did not anticipate. Examples are cheaper to produce and they encode tacit knowledge that no rulebook captures.

Twenty examples in an hour beats a forty-page naming guide in a week. The examples ship. The naming guide gathers dust.

Source

Few-shot prompting is one of the most consistently useful techniques across LLM applications. It was highlighted in Anthropic’s Prompting 101 session by Hannah and Christian from the Applied AI team. Their framing stuck with me: “examples are powerful in steering Claude. You can imagine concrete cases that have happened that are tricky for Claude to get right, but you with your human intuition and your human-labeled data are able to actually get to the right conclusion. Then you can bake that information into the system prompt.”

That is the whole game. Find the gray cases. Label them. Watch the model get better.