01. Prompt Design Principles
Why Prompt Design Is Different in MangaAssist
MangaAssist is a hybrid system.
It does not treat every user message as an open-ended reasoning problem. Prompt engineering starts by deciding whether the model should be used at all.
First Principle: Route Before You Prompt
| Request Type | Best Path | Why |
|---|---|---|
| Greeting, thanks, simple confirmation | Template | Zero model cost and stable output |
| Order status, live price, stock, account-bound facts | API + template | Truth comes from backend systems |
| FAQ, return policy, shipping policy | RAG + light generation | Needs natural language but must stay grounded |
| Recommendation explanation | Retrieval or ranking upstream + FM explanation | The model explains ranked results rather than inventing them |
| Complex ambiguous shopping help | Full FM path with constraints | Open-ended reasoning is useful here |
Prompt engineering starts after this routing decision.
Second Principle: Use the FM for Expression, Not Ownership of Truth
The model should own:
- tone
- summarization
- explanation
- follow-up suggestions
- natural language composition
The model should not own:
- current price
- delivery date
- return eligibility state
- product existence
- promotion validity
If a business-critical fact can be read from a system of record, the prompt should treat that fact as input, not as a generation target.
Third Principle: Prompt Layers Must Be Separable
Use a layered prompt structure so failures are easier to debug.
Layer 1: System Rules
- define role
- define hard constraints
- define refusal behavior
- define output contract
Layer 2: Workflow Context
- intent
- store section
- locale
- page context
- authenticated vs guest
Layer 3: Grounding Data
- retrieved chunks
- catalog JSON
- recommendation results
- live service outputs
Layer 4: Conversation State
- recent turns
- summarized long-term context
- saved preferences
Layer 5: User Request
- current message only
This separation matters because it lets the team isolate whether a bad answer came from poor instructions, bad retrieval, stale data, or noisy history.
Shared Prompt Skeleton
SYSTEM
You are MangaAssist for Amazon's JP Manga store.
Follow these rules:
1. Use only the provided product, policy, and workflow data.
2. Never invent prices, availability, or order details.
3. If required data is missing, say what is unavailable and offer the next best action.
4. Keep answers concise unless the task is recommendation-heavy.
5. Never mention competitors.
6. If the user asks for a human or the task is outside scope, offer escalation.
WORKFLOW CONTEXT
- intent
- locale
- page context
- auth state
GROUNDING DATA
- product data
- retrieved policy or editorial chunks
- recommendation results
- live service outputs
CONVERSATION STATE
- recent turns
- compact summary if history is long
USER MESSAGE
- current message
OUTPUT CONTRACT
- response_text
- products[] if applicable
- actions[] if applicable
- follow_up_suggestions[]
Scenario Matrix
| Scenario | Prompt Goal | Main Risk | Main Constraint |
|---|---|---|---|
| Recommendation | Explain why ranked titles fit the user | Hallucinated fit claims | Only explain upstream-selected items |
| Product Q and A | Answer from structured metadata | Missing or stale attributes | Prefer catalog truth over free-form description |
| FAQ and policy | Ground answer in retrieved policy text | Conflicting chunks | Prefer freshest valid source |
| Order support | Stay accurate with account-bound facts | Wrong order state | Use API output, not FM memory |
| Return flow | Provide next action clearly | Incorrect eligibility statement | State uncertainty if live eligibility absent |
| Promotion | Mention valid offers only | Stale offer language | Treat promos as structured input |
| Escalation | De-escalate and transition cleanly | Over-talking instead of handing off | Keep summary short and actionable |
| Chitchat | Stay lightweight | Unnecessary model cost | Prefer templates |
Prompt Design Rules That Matter Most
- Prefer explicit negative constraints over vague safety language.
- Prefer structured business inputs over prose whenever possible.
- Prefer per-intent prompts over one universal mega-prompt.
- Prefer short, testable instructions over long policy dumps.
- Prefer upstream ranking and filtering over asking the FM to select from noisy sets.
- Prefer deterministic output contracts when the UI expects structured actions.
- Prefer prompt changes that reduce error surface, not just changes that make demos sound better.
Anti-Patterns
One Prompt for Every Intent
This creates instruction bloat, token waste, and conflicting behaviors.
Letting the Model Infer Missing Business Data
If the prompt says "helpfully answer even if some values are missing," the model will often fill gaps with plausible but invalid facts.
Using Conversation History Without Compression Strategy
Raw history can dominate the prompt, drown out retrieved grounding, and increase latency.
Asking for Creativity in High-Risk Flows
Recommendation copy can be slightly expressive. Price, policy, and support flows should not be.
Operating Heuristic
Use the smallest prompt and the smallest FM path that can still achieve the user goal with acceptable trust and UX quality.