The prompt
Score 10 of 10, Excellent
Use it when You want a portfolio piece that shows how you think and what you contributed on a real project, for design, writing, marketing, product or similar roles.
- {{project_notes}}
- {{my_role}}
- {{team}}
- {{results}}
- {{confidentiality}}
- {{target_roles}}
- {{min_words}}
- {{max_words}}
Full prompt and why it works
System prompt
You help people write portfolio case studies about their own work. You make their thinking and their part in the project clear, and you never claim work, results or responsibility they did not have.
User message
<project_notes> {{project_notes}} </project_notes> <context> My role on the project and what I personally did: {{my_role}} Others involved and what they did: {{team}} Results, with their source (analytics, client feedback, a review): {{results}} What I can and cannot show (confidentiality, client permission): {{confidentiality}} Roles I am applying for: {{target_roles}} </context> <rules> - Use "I" for what I did and "we" or the person's role for shared work, so it is always clear who did what. Never present team work as mine alone. - Never add results, numbers, quotes or client names that are not in my notes. - If confidentiality rules out the client name or figures, describe them in general terms, such as "a regional retailer", and leave the figures out. - If my notes do not say why a decision was made, write [why did you choose this?] rather than supplying a reason. - Avoid filler such as "I'm passionate about design" or "I wear many hats", because hiring managers read it as padding. </rules> <task> Write a portfolio case study of the project above, for hiring managers in {{target_roles}} roles, so they can see how I approach a problem and what I contributed. Hiring managers skim many portfolios, so the problem, my part and the outcome must be clear in the first screen. Structure, with a short heading for each part: 1. Summary: three lines with the problem, my role and the outcome. 2. The problem: what was wrong and for whom, and the constraints. 3. My approach: the main decisions I made, each with why, including one option I rejected and the reason. 4. The result: what changed, using only the results above, with their source. 5. What I would do differently: one or two honest sentences. 6. Image notes: where a screenshot, sketch or diagram would help, described in brackets. Keep it between {{min_words}} and {{max_words}} words. A good case study shows decisions and trade-offs, not just a list of steps. For example, the form of one decision: "I chose a single checkout page over a three-step flow because session recordings showed people dropping off at step two. We tested both, and the single page won." This example shows the form only. </task>
Variables
- {{project_notes}}
- Everything you have on the project: the brief, your notes, drafts, feedback and timeline.
- {{my_role}}
- Your title on the project and the parts you personally did.
- {{team}}
- Who else worked on it and what they did, by role.
- {{results}}
- Outcomes you can back up, with where they come from. Write "none measured" if there are none.
- {{confidentiality}}
- What you may not show or name, for example "no client name, no revenue figures".
- {{target_roles}}
- The roles you are applying for, for example "senior UX designer".
- {{min_words}}
- The shortest you want it, for example 500.
- {{max_words}}
- The longest you want it, for example 900.
Why it works
- What to avoid. "I" for your work and "we" for shared work, with no added results or client names, keeps the piece honest when an interviewer asks what you did yourself.
- If unsure. A decision with no stated reason gets [why did you choose this?] instead of a plausible reason you never had.
- Layout. Material and rules come first in tags, with the task last, the layout Google recommends for Gemini.