Problem statement

You own an AI-assisted weekly incident summary for executives. Leadership wants consistent tone, bounded length, and predictable structure—but engineering wants flexibility when incidents are messy.

Outcomes

You can draft prompts using role + constraints + format, few-shot examples, and decomposition (split complex asks into steps).

Deliverables

1. Three prompt variants for the same incident narrative (see data/incident_sample.md).
2. Written comparison: which variant you’d pilot first and one tradeoff (verbosity, control, maintenance).

Links

• Master plan: Phase 1
• Patterns checklist: Phase 1 concepts

Required

• [ ] Provider docs: system vs user messages, multi-turn chat state.
• [ ] Provider docs: function calling / tool use at a conceptual level (you will apply it more in Week 03).

Recommended

• [ ] Skim LangChain or LlamaIndex intro only for vocabulary (“chains,” “retrieval”)—no need to build apps yet.

Time box

~2 hours readings + notes.

Use data/incident_sample.md as the single source incident for all tasks.

Task A — Role + constraints + format

Write one system prompt and one user prompt that produce:

• Executive audience, neutral tone.
• ≤ 120 words total output.
• Sections: Summary, Customer impact, Next steps.

Save as prompts_v1.md.

Task B — Few-shot

Add two input/output examples (synthetic is fine) showing “good” summaries for smaller incidents. Keep examples short. Save as prompts_v2_fewshot.md.

Task C — Decomposition

Before summarizing, ask the model (or write yourself) a 3-step decomposition:

1. Extract facts vs hypotheses.
2. Rank severity.
3. Then summarize.

Implement this either as three chained prompts or one prompt with explicit steps. Save as prompts_v3_decompose.md.

Task D — Compare outputs

Run A, B, C against incident_sample.md (use any chat UI or API). Paste outputs side-by-side in comparison.md (≤ 400 words) with:

• Which output you’d ship first.
• One failure mode you still see (missed P0, vague impact, etc.).

---

Submit: my-submissions/week-02/ with all markdown files.

45 minutes, closed notes. Then compare with Phase 1 checklist.

1. Short answers

1. Why is the system prompt often treated like a “product contract”?
2. What does few-shot buy you that zero-shot does not?
3. When is decomposition worth the extra latency?

2. Prompt sketch

Write a system prompt only (≤ 120 words) for: “Convert messy customer feedback into a JSON object with keys theme, severity, quote.” Include at least two constraints on tone or safety.

3. Failure mode

Give one example of how a vague format constraint could break downstream automation.

---

Self-grade: Clear definitions; prompt is checkable; failure mode is realistic.

Concepts & curated links: read the Learn chapter Prompting first (topic path, not calendar-only). This file is the weekly practice bank — extra drills and a checklist on top of Readings → Practice → Exam.

---

1. Practice bank

#	Problem	Data / materials	Expected outcome
P1	Write system + user prompts for executive incident summary (≤120 words output, fixed sections).	data/incident_sample.md (this week’s folder)	Two prompts in prompts_v1.md
P2	Add two few-shot examples (synthetic incidents OK).	Same incident file	prompts_v2_fewshot.md + model output pasted
P3	Decompose the task into 3 explicit steps in the prompt (chain).	Same	prompts_v3_decompose.md + comparison notes
P4	Run all three variants; note which you’d ship first and one failure mode.	Chat UI or API	comparison.md (≤400 words)

Expanded

• P1–P3: Formal assignment detail lives in PRACTICE.md — use this table as the outcome checklist.

---

2. Week checklist

• [ ] Completed T1–T4 readings/videos
• [ ] P1–P4 artifacts saved
• [ ] PRACTICE.md + EXAM.md