Prompt engineering with MapleStream

The same file and the same AI — only the prompt changes. Compare the weak prompt with the engineered one, and see how the results differ. (Outputs below are the actual results from the MapleStream sample files.)

What makes a prompt “engineered.” A good prompt supplies five things a vague one leaves to chance:
1 · Role 2 · Clear task 3 · What to extract 4 · Output format 5 · A guardrail

Task 1 — Customer reviews (text mining)

File: sample-customer-reviews.csv  (review_id, month, rating 1–5, review_text)

Without context engineering
Prompt
Are these reviews good or bad?
Model output
“The reviews are mixed — some customers are happy, some are unhappy. Overall it looks roughly balanced, maybe leaning a bit negative.”

No numbers, no themes, no idea which feature to fix. Nothing the product team can route or act on.

Structure
Low
Actionability
Low
Team can use it
Low
With context engineering
Prompt
You are a customer-insight analyst for MapleStream,
a subscription app for home cooks. I've uploaded a file
of reviews (review_id, month, rating 1-5, review_text).

Task: analyze OVERALL sentiment and the specific
aspects customers mention.

1. Share of reviews positive / neutral / negative.
2. Main aspects (recipes, app, shipping, price,
   service, quality): how often, mostly + or -, and
   one short quote (under 15 words).
3. Top 3 complaints and top 2 praises.
4. One recommended action.

Use only the file. Do not invent quotes or numbers.
Plain English, under one page.
Model output
Sentiment: 44% positive · 8% neutral · 47% negative — leaning negative.
AspectDirectionExample
ShippingMostly −“Delivery took almost three weeks.”
The appNegative“The app is confusing and crashes.”
PriceNegative“Overpriced for what you get.”
ServiceMixed“Support solved my problem right away.”
QualityMixed“Broke after two weeks of normal use.”
Top complaints: slow shipping, a buggy app, refund/billing problems.
Top praises: helpful support, solid product quality.
Recommendation: fix delivery times and app stability first.
Structure
High
Actionability
High
Team can use it
High
What changed: the engineered prompt names the aspect behind each complaint (shipping, app, price), so you know which team to send it to. Same reviews — the structure is what makes it useful.

Want machine-readable output instead? Ask for a table, one row per review:

Prompt (structured variant)
You are a sentiment classifier for MapleStream. For each review in the file, classify OVERALL sentiment
as Positive, Negative, or Mixed, and extract the aspects mentioned with a sentiment for each.
Return a table: review_id, overall_sentiment, aspects (a list of aspect: sentiment). Use only the file's data.
Model output (first rows)
review_idoverallaspects
R001Negativeshipping: negative
R006Positiveservice: positive
R034Positiveshipping: positive, app: positive, service: positive
R035Negativeprice: negative, app: negative

Task 2 — Monthly metrics (correlation)

File: sample-monthly-metrics.csv  (month, marketing_spend, new_customers, revenue, churn_rate_pct, customer_satisfaction)

Without context engineering
Prompt
Look at this data and tell me what drives revenue.
Model output
“Marketing spend is the biggest driver of revenue — they move together very closely (correlation 0.92). Spending more on marketing should increase revenue.”

Confident and wrong: it reads a correlation as cause. Both simply trend upward over two years.

Correctness
Low
Honesty of caveats
Low
Safe to act on
Low
With context engineering
Prompt
You are a data analyst for MapleStream. I've uploaded
24 months of metrics (month, marketing_spend,
new_customers, revenue, churn_rate_pct,
customer_satisfaction).

Task: examine which metrics move together.
Do NOT assume anything causes anything.

1. Correlation for each pair of numeric metrics.
2. The 5 strongest: name both, value to 2 decimals,
   positive or negative.
3. For each, say if it looks real or likely just a
   shared time trend (these numbers trend over 2 years).
4. State that correlation is not causation; flag any
   pair where a causal reading is unjustified.
5. One relationship worth testing, and how to test it.

Use only the file. Round to 2 decimals.
Model output
PairrReading
marketing_spend & revenue+0.92Likely a shared time trend
marketing_spend & new_customers+0.84Plausibly real
new_customers & revenue+0.81Part real, part trend
satisfaction & churn_rate_pct−0.40Plausibly real
satisfaction & revenue+0.14Essentially unrelated
Caution: correlation is not causation. Because these are monthly numbers trending upward, many pairs rise together — the 0.92 is mostly that shared trend.
Worth testing: marketing → new customers. Run a controlled test that varies spend and watch sign-ups.
Correctness
High
Honesty of caveats
High
Safe to act on
High
What changed: one line — Do NOT assume causation, plus “real vs shared trend” — turns a confident, misleading answer into an honest one. Same data, same model. The prompt is the whole difference.

How to use this: read the weak prompt and its result, then the engineered prompt and its result. Then open the file in Claude and try the good prompts yourself — the outputs you get should match what you see here. Results generated from the MapleStream sample files (24 months of metrics; 36 reviews). The bar ratings are a simple quality read, not exact scores.