Prompt Engineering Capstone Exercise — Prompt Engineering for Business

What you'll learn

Apply skills from across this course in a single realistic professional scenario
Produce a concrete, role-relevant deliverable using AI tools
Self-assess your output against professional quality criteria

Building a prompt library from scratch under a real deadline is different from building prompts in a learning environment. The stakes are concrete: if the prompts are weak, the team will try them, get poor results, and stop using the library. If the library lacks a maintenance process, it will be useful for two months and abandoned after that. This capstone tests your ability to deliver a complete, production-ready prompt system, not just a collection of individual prompts.

You are a team lead at a 15-person marketing agency. Your manager has asked you to deliver a working prompt library of eight core prompts, a one-page team usage guide, and a maintenance process document before the all-hands meeting on Friday. The full seven-component format from Lesson 10 applies to every prompt entry.

Capstone Exercise

Build the Agency's First Production Prompt Library

Context

You lead a 15-person marketing agency team that handles content strategy, copywriting, and campaign reporting for ten B2B clients. The agency has been using Claude and ChatGPT informally for six months: some team members are highly effective, others rarely use AI because they find results inconsistent. Your manager wants a shared prompt library that raises the quality floor across the team, and has asked you to present it at Friday's all-hands. The team's core recurring tasks include writing content briefs, drafting blog posts, responding to client emails, writing social captions, summarising meetings, researching competitors, outlining proposals, and compiling campaign reports.

Your Task

Build the complete prompt library system by completing the following: (1) Write eight production-quality prompts covering the agency's eight core use cases listed in the context, one prompt per use case; (2) Structure each prompt using the seven-component format from the course: name, use case description, recommended tool, prompt text with variables in brackets, example output, adaptation notes, and known limitations; (3) Draft a one-page team usage guide that explains how to find and use the library, how to fill in variable sections, and what to do when a prompt produces a poor result; (4) Write a quarterly maintenance process covering who reviews the library, how prompts get updated when workflows change, and how new prompts get added. For two of the eight prompts, include a brief note explaining a specific iteration you made after testing the initial version and what improved.

Your notes (optional)

Deliverable

Eight prompt library entries in the seven-component format, a one-page team usage guide, and a maintenance process document. Two of the eight entries include an iteration note. The complete system is ready to present at a team all-hands and to be used by a team member who was not involved in building it.

Quick check

The capstone argues that each part of the seven-component prompt format solves a specific adoption problem. Which problem does the known limitations section solve?

Select one answer.

Key takeaways

A production-ready prompt library is a system, not a collection: it requires consistent formatting, an adoption guide, and a maintenance process, because prompts without documentation and prompts without maintenance both eventually stop working for the team.
The seven-component format is not bureaucracy: each component solves a specific adoption problem. The example output sets the quality benchmark. The known limitations prevent abandonment after a single poor result. The adaptation notes prevent the most common customisation mistakes.
The iteration note discipline, practised in this capstone, is the habit that turns a static library into an improving one: documenting what changed and why means the next person to work on that prompt starts from understanding rather than guessing.
The team usage guide is often underweighted in prompt library projects, but it is where adoption is won or lost: a library that requires asking a colleague how to use it will not be used when that colleague is unavailable.