Artifacts: mini-apps without coding

Build me an internal quote-pricing calculator as an artifact.
Salespeople will use it, often on a phone in front of a client.

Inputs:
- product type: [A / B / C]
- quantity: whole number 1 to 10,000
- delivery time: standard / express
- shipping distance in km: 0 to 500
- client type: new / returning

Rules:
- base price per unit: A = [1,200] Kč, B = [1,850] Kč, C = [2,400] Kč
- volume discount: [5]% from [50] units, [10]% from [200] units,
  [15]% from [500] units
- express: [20]% surcharge on the goods price; express can't be
  selected on orders over [500] units
- shipping: [25] Kč per km, free above [300] km
- returning client: [3]% discount, but the total discount may never
  exceed [20]%

Output:
- line-item breakdown (goods, discounts, shipping) and total price
  excluding and including [21]% VAT
- a text summary of the quote ready to paste into an email
- a red warning if the per-unit price would fall below [900] Kč

Test case: product B, 250 units, express, 120 km, returning client
= [fill in the correct result you calculated by hand].
Show me first how your calculator handles this case.

I want to build a tool that [one-sentence description of what it's for].
I haven't worked out the details yet.

Don't build anything yet. First ask me the 6 things you need to know
to build a usable first version — one question at a time, wait for my
answer, then ask the next. Ask about specific numbers and rules,
not general impressions.

Once you have the answers, summarize the brief as bullet points and
ask me if that's correct. Only build the artifact after I confirm it.

I'm attaching [a price list / policy / methodology] and want to build
an artifact from it that calculates according to it.

Work like this:
1. List every rule from the documents that affects the calculation —
   as a numbered list, with a reference to which part of the document
   each one comes from.
2. Separately, list anything that's ambiguous or contradicts itself,
   and ask me how it actually works in practice.
3. Once I confirm that, build the calculator according to item 1.

Don't guess anything. Where a value is missing from the document,
say so instead of estimating it.

I tried the calculator and have these notes. Change only this,
leave everything else exactly as is:

1. The “quantity” field shouldn't accept negative numbers or letters.
2. Round the price to whole units, but only at the very end — don't
   round intermediate calculations.
3. Below the total price, add a line for “price per unit after
   discounts.”
4. Make the email summary copyable with one button.
5. The fields are too small on mobile — make them full-width.

After making the changes, tell me exactly what you changed, and
recalculate the test case from my original brief so I can see the
result hasn't changed.

Leave the calculations exactly as they are and change only the
look and usability:

- make the result the largest element on the page, visible without
  scrolling right after the fields are filled in
- group the fields into blocks: what the order contains / where it
  ships / who the client is
- add a short explanation next to the “product type” field of what
  each type means
- use simple, calm colors; red only for warnings
- make it easy to read on a phone and on a large monitor
- add the tool's name and one sentence about what it does at the top

Don't add any new features or fields.

Leave the tool unchanged and list, in plain language, the rules it
calculates by. For each rule:
- what it does (one sentence, no jargon)
- in what order it applies relative to the others
- where that value came from — was it in my brief, or did you fill
  it in yourself?

Separately list:
- every value I never gave you that you chose on your own
- every place where my brief was ambiguous and you picked one
  interpretation

Don't fix anything, just describe it.

Generate a table of 12 test cases for this calculator:

- 4 ordinary cases, the kind that come up most often in practice
- 4 edge cases: zero units, maximum units, exactly at a discount
  threshold ([50] units, [200] units), zero distance
- 4 nonsensical cases: a negative number, text instead of a number,
  an empty field, a combination that the rules shouldn't allow
  (express on an order over [500] units)

Columns: inputs | what the tool should do | what it actually did.
Leave the third column blank — I'll fill it in myself while testing.

Add a discreet line in the tool's footer with:
- the tool's name and version
- the date the rates are effective as of: [date]
- the name of the person discrepancies should be reported to: [name]

And add a collapsible “How this calculates” section, written in
plain language, describing which rules are in use — so a
salesperson can read it, not just a developer.

Leave the calculations unchanged.

The project has an updated price list effective [date].
Take my existing tool [name] and update the rates in it to match
the new price list.

- change only the numbers; the logic and appearance stay the same
- list every change in the form: what it was → what it is now
- update the effective date in the footer
- show me the old and new results side by side for the test
  case [description]

Build an artifact called “deal checker” for salespeople.

The user enters: the deal's price, direct costs, an estimate of our
team's hours, payment terms in days, and risk (low/medium/high).

The tool calculates and shows:
- margin in Kč and percent
- hourly profitability (margin divided by hours) compared against
  our target of [X] Kč/hour
- a simple traffic light: green = take it, yellow = discuss with a
  manager, red = don't take it, with thresholds of [fill in]
- for yellow and red, list exactly what's wrong and by how much the
  price would need to rise or the hours would need to drop for it
  to turn green

The traffic light is a recommendation, not a decision — say that
visibly right in the tool.

Build an artifact: an onboarding quiz for new colleagues.
The source material is the attached [policy / handbook] — write
questions strictly from it, don't add anything from general
knowledge.

- 12 questions, each with 4 options and exactly one correct answer
- phrase questions as situations (“what would you do if…”), not
  as verbatim wording from the policy
- right after each answer, show whether it was correct and explain
  why, with a reference to the relevant part of the document
- at the end, show a score, a list of topics the person got wrong,
  and a recommendation of which sections to reread
- let the quiz be restarted with the questions in a different order

The result isn't sent anywhere and isn't stored anywhere — say that
in the quiz's introduction so the new hire knows it.

Build a practice artifact for [grade level] students on the topic
of [topic].

- generates problems of the type [description, e.g. one-variable
  equations with a whole-number solution], always new, never the
  same ones repeated
- three difficulty levels, switchable
- after each answer, shows whether it's correct, and for a wrong
  answer, shows the step-by-step solution — not just the result
- a counter of how many the student has gotten right in a row
- a “next problem” button and a “show me the worked solution” button

Age-appropriate language, no unnecessary jargon.
No grading and no sending results anywhere.

Build a clickable prototype of [screen description, e.g. a booking
form for a hair salon] as an artifact.

- works by clicking: lets someone walk the whole flow from start to
  finish and see what happens at each step
- use fictional but realistic data
- no connections to anything, nothing gets sent anywhere
- a short note on each screen explaining what will happen behind
  the scenes in the real version

The goal is to agree with the client on the flow and scope, not the
final look. Write me 8 questions to ask the client during the demo.

This artifact is used by [number] people and has outgrown what an
artifact can carry: we need [data storage / login / integration
with system X].

Write a spec for a developer based on this tool:
1. What the tool does today — feature by feature, including every
   calculation rule and the order they apply in
2. What needs to be added for it to work for more people
3. What data will be stored and which of it is personal data
4. Roles and permissions: who's allowed to do what
5. Open questions that we need to decide, not the developer
6. What from today's tool we specifically don't need, and why

Write it factually, no marketing. Don't propose the technology —
that's the developer's call.